As a developer, I’m trying to setup a development environment on our brand new VMWare ESX server. Things are not working out: somewhere during the SharePoint Product & Technologies Configuration Wizard, the application just disappears, and in the event log I find the following error:
.NET Runtime version 2.0.50727.3082 – Fatal Execution Engine Error (7A0979C6) (80131506)
Now I know all this sounds suspiciously like a ServerFault.com style problem (and a very generic error message, lots of similar hits on google), and of course we are addressing the issue in such a way (installing/uninstalling service packs/hotfixes, different os versions, testing individual elements of the install, different settings for the vm, etc), but out of personal interest I’d like to gain a bit more understanding about the issue then “install hotfix XXYY and hope it goes away”. I was wondering: How do I approach this error from a coders perspective?
- Can I somehow make a debugger stop when this issue occurs, or manually point it to the reported address (in what module)?
- Should I try and install use Visual Studio for this, or use lowlevel tools like windbg?
- What are these error codes exactly? The latter looks like a com error. Is the other one an address?
- Can I somehow turn on more detailed error reporting? A faulting .dll would be nice.
You can tell I am not at all experienced in debugging at this level in a .net environment, but I am very much willing to learn. Any pointers are most welcome!
p.s. When I try to run the command-line configuration tool psconfig to do a non-UI configuration, most if not all commands trigger a StackOverflowException. Again, where do I go from there?
Short answer: read the blog of Tess Ferrandez. This contains lots of invaluable guidance to debugging .NET applications and guides you through how to do it.
Longer answer…
Within Visual Studio
If you have Visual Studio installed you could try breaking on any unhandled .NET exception. To enable this, go to the menu and choose Debug, Exceptions and tick Common Language Runtime Exceptions. Then go to Tools, Options, Debugging and untick Enable Just My Code. Finally, attach to the process of the Configuration Wizard (you obviously need it running first) and the Visual Studio debugger will break at the point the exception occurs.
Assuming the debugger breaks (if it doesn’t you have attached to the wrong process) then you should have access to the call stack and can make some educated guesses from the method names about what is going wrong. However there is a possibility this is obfuscated which won’t be helpful. You will also be able to see the current MSIL instruction the debugger has stopped on. This is where it starts getting a bit beyond me but there are good references out there to help you understand what’s happening in the code.
Without Visual Studio
If you don’t have Visual Studio or for some reason can’t get the debugger to break, then it is possible to create a dump of the crashing process. There are two methods I know of. One is described by the Windows Server Performance Team using good ol’ Dr Watson. The other is a new tool has just been released by Mark Russinovich called ProcInfo that can automatically create a dump of a process that crashes through unhandled exceptions. There are probably other methods.
Once you have the dump you can use this KB article to help you get set up to debug it.
Finally
Return to the ‘short answer’ above: read Tess’ blog to progress further! This is a big topic and she has the best resources I’ve eveer found. Also there is a good post by Vincent Rothwell which might help but it’s really targeted towards debugging your own code.
As an aside – you shouldn’t be getting the exceptions you are. It indicates a pretty serious problem. I would look at corruption, serious hardware faults, and consider a rebuild.