Microsoft Project File 2010 crashes when trying to load mpp file RRS feed

  • General discussion

  • Hi All,

    I am having a master project which includes 4 subproject . when i am trying to load one of the subproject mpp is getting crashed for other subproject and master project it is working fine 

    i am the only owner of all the sub-project and master project so i think no permission issues at all.

    Thursday, November 3, 2011 7:14 AM

All replies

  • Kirtenshtiw,

    It sounds like a case of file corruption to me. Were all the subproject files created in the same version (i.e. Project 2007 or Project 2010) or were they created in one version and then saved to another version (i.e. Project 2010 files saved as Project 2007). Crossing versions of Project is one of the known factors for file corruption. However, there are many things that can cause file corruption,  particularly in a master/subproject structure.

    I would break all links between the master and subprojects using the unlink feature found on the advanced tab of the task information window for each of the subproject's summary line insertion points in the master. Be sure to save both master and subproject after all links are broken, that eliminates link "fragments" that can remain by improper delinking. Next, delete the master, you will rebuild it later. If you have custom views, filters, etc. in the existing master you can save those to your global or transfer them to a new blank file which will become your new master. Take the subproject file that causes the master to crash and use one or more of the methods detailed in FAQ 43 - handling project file corruption and/or bloat, found on the MVP website at, Finally, rebuild your master.

    Hope this helps.


    Thursday, November 3, 2011 3:55 PM
  • John,

    Thanks for your reply, i have all the subproject is in same version (2010). Crossing version is not a problem i think, mean while i am trying your solution .

    I want to know the basic reason for the curruption for master and subproject and if any permanant solution for this type of problem so that these can not occur again.

    Wednesday, November 9, 2011 5:06 AM
  • You can assign effort into investigating root cause of the corruption, but this can be quite time consuming and doesn't always yield a result, so many people choose just to accept it as a non-specific corruption, implement one of the fixes in the FAQs John refers, and move on with our lives!

    However, if you do want to go down the route of determining the exact cause, I've identified a couple of these in the past, and have detailed below the ways in which I've found these. This isn't an exhaustive list of ways to identify corruptions, just some techniques I've used in the past.

    Single Corrupt Task
    I've had two projects which have displayed similar behaviour to what you describe where we've narrowed the cause down to a single task causing the crashes. Although you can't open the schedule directly, can you edit it from the master?

    If so, create a copy of the set, then via the copy master, delete all the tasks in the sub-project, and try to open it directly. If it does open, this would indicate you've got a corrupt task of some sort.

    You can then narrow it down to work out what task it is preventing the file opening by creating two further copies of the original, delete half the tasks in one copy, and delete the second half in the other copy, then try and open it directly. If one of these works, you now know that there is a corrupt task in the section that was deleted in the file which does open.

    Repeat this split and test to narrow down the suspect tasks until you know which task it is. Twice I've used this technique to identify a single task in a schedule which was seen as corrupt.

    In one case, we narrowed it down further to just the predecessor of teh task, which appeared valid outwardly (i.e. was a comma seperated list of valid task numbers), but when we deleted the value, the plan suddenly started working again. We then just re-entered the predecessors manually, and it continued to work. (We identified this by deleting all the predecessors in the plan first, which again allowed it to start working)

    In the other case, we didn't narrow it down to a specific field, but we just deleted the task and then added a new task with the same details and it started working.

    Rogue Macro
    I know macros can't go rogue, but I did have one case, which was actually the other way around (i.e. file would open in the sub but not the master) where the sub contained a macro that was preventing the master being opened. Deleting the macro in the sub allowed it to be opened from the master. It was a legacy, undocumented macro that no-body knew what it was supposed to be doing.

    In your case, you could determine if this is the cause by opening up the the File > Open menu, and holding down shift when clicking the Open button. This will prevent auto_open macros running (thanks to Rod Gill for this tip).

    Query Requirement
    Becuase of the issues I've faced with the sub/master structure in the past, and the added complexity and risk of corruption it brings, I would now only recommend that people use this structure when there is a requirement for concurrent editing of the schedules by multiple users, and then work around any sub-project specific reporting requirements.

    You say you're the only owner of the schedules - does this mean you're the only person who'll be editing the plans? If so, I'd be tempted to do away with the sub-schedules altogether and consolidate them into a single file, although maybe you have a specific reporting requirement that prevents you from doing so.

    Wednesday, November 9, 2011 11:37 AM