"Unrecoverable Build Error" When Building Very Large vs Deployment Project

So after being able to successfully build that large deployment project I was talking about by using the 3GB switch, a day or two later I began getting an "Unrecoverable build error" message accompanied with a "Send Error Report" dialog.  It didn’t kill the IDE process, but did stop the installer build.  I verified that I was able to build other deployment and non-deployment projects without any problems.

So after searching around, I tried a few solutions people said helped them solve the problem.  Some of the simple and straight forward ones I tried were simply restarting the IDE and doing a clean on the solution; I even resorted to a machine reboot.  I next tried all of the applicable solutions from this Microsoft article:  http://support.microsoft.com/kb/329214 (or this one says the same thing basically:  http://msdn2.microsoft.com/en-us/library/ms228633(VS.80).aspx).  I also found another guy that said to try doing a regsvr32 on ole32.dll.  By the way, here is the typical location of mergemod.dllC:\Program Files\Common Files\Microsoft Shared\MSI Tools\ and here is the typical location of ole32.dllC:\WINDOWS\System32\.

None of it seemed to help my situation.  So I tried uninstalling Visual Studio, and then uninstalling all versions of the .NET Framework with the help of this handy tool:  http://blogs.msdn.com/astebner/archive/2006/05/30/611355.aspx.Then I went ahead and reinstalled everything and gave it a nice machine reboot.  Even this charade proved unsuccessful.

The good news in all of this was that I am still currently the only developer that cannot build this deployment project.  So it is definitely something with my machine that is the problem and not with the actual deployment project itself (we were concerned for a little while about the "multiple folders with the same name" issue mentioned in the Microsoft articles).

So when I get time, I may try to do an OS reinstall and be extra careful of what and when stuff gets installed.  Luckily I have got my personal files on a separate partition, so only the system partition will have to be blown away.  If this proves successful, which it should, I will make an additional note to this post.  Good luck if you ever get this same problem.

FOLLOWUP (01/18/08):  So it turns out that my computer actually crashed a few days later.  When I formatted my hard drive and did a fresh install of Windows, everything seemed to be fine again so I didn’t question the hardware anymore.  Then I turned on the 3GB Windows switch for Windows and everything went haywire.  I removed 2 of my 4 GB of RAM and then everything was fine.  I tried all kinds of combinations with different memory sticks in different memory slots with different totals of RAM.  It seemed I could only run in 3GB Windows mode with 2 GB of RAM; however, in normal Windows mode, I could successfully run with all 4 GB of RAM.  So I opted for the 4 GB and will continue to allow someone else to build the monster deployment project, which he has been able to do every time without any issues using the 3GB Windows switch.

FOLLOWUP (06/17/08):  For the last 6 months, I have tried two or three times to get another machine to build these installers using the 3GB Windows boot switch and modifying the DevEnv.exe executable to be "Large Address Aware"; all of my attempts have been unsuccessful.  Currently, we only have one guy’s laptop that can handle the build and is running stable with the 3GB switch (and we have no clue why it works).  He has been using a local account on his machine for like 9 months and he just recently switched to a domain account.  The interesting thing is that we could no longer build the installers anymore.  But when we went back to using a regular local account (not on the domain), his laptop was able to build the installers again.  With that knowledge, I just now tried building the installers on my machine using a local account; unfortunately, it was unsuccessful.  However, I also don’t have the 3GB switch turned on.  Perhaps the combination of the two is why his laptop is able to build the installers.  I may finish this test of my hypothesis soon, but not right now.

FOLLOWUP (06/18/08)I got it working!!!  The problem was being logged in with a domain user account for some reason.  I am really not sure why; there must be something different about using a domain user account (perhaps during the login process or some restriction set on our domain user accounts or policies).  I did test it without the changes involving the 3GB switch, but they are necessary as well.  In fact in my setup, I also didn’t put the box on the domain at all, just to be sure.  The box runs very stable as far as I can tell with these modifications to Windows and the Visual Studio executable.