As most developer type bods, debugging problems on deployed software can be an arduous task at best. Sure, tracing and asserts are great tools to be utilised and the JIT Debugger is cracking allowing the debugger to view the call stack as well as a plain text explanation of the unhandled exception. Well, using Framework 1.* that was the case.
However, after deploying a Framework 2.0 application to a Windows XP Home (SP2) machine with all the usual critical patches installed, etc. a nasty little error poked up its impish head. However, rather than showing the usual application crashed type dialogs - it gave the rather cryptic...
<Message>
An unhandled win32 exception occurred in >application exe< [1808]. Just-In-Time debugging this exception failed with the following error: No installed debugger has Just-In-Time debugging enabled. In Visual Studio, Just-In-Time debugging can be enabled from Tools/Options/Debugging/Just-In-Time.
Check the documentation index for 'Just-in-time debugging, error' for more information.
</Message>
OK - I thought - I'll install the Framework 2.0 SDK that I assumed would install the appropriate debugger and hey presto. But it didn't.
Searching around I found information that the following key should be added to the app.config file.
<system.windows.forms jitDebugging="true"/>
But that didn't work either.
After an awful lot of searching around, checking the existence of specific registry keys and inserting new ones but again to no avail. Luckily after posting on a newsgroup I was 'seeded' with the answer.
“Install another debugger such as the 'WinDbg' available for free from Microsoft.”
Now to be fair, after wasting the best part of a week attempting to suss this out (albeit I worked out where the error had occurred) I was willing to listen to anything and quite frankly sacrifice any number of domestic animals you care to mention. So to the chase, you can download WinDbg from MS just (http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx).
- Once downloaded, install the application.
- Once installed, navigate to <Program Files>\Debugging Tools for Windows\ and execute the 'WinDbg' executable with the switch '-I', e.g. from the run command "C:\Program Files\Debugging Tools for Windows\WinDbg -I".
This will install and use the WinDbg application as your default debugger. Now when running an application and it throws an unhandled exception - the new debugger will appear. However, if your life is too short to fumble through the stack and register traces you can load the managed 'sos.dll' file that provides a host of helper functions to specifically debug managed applications. To do this, in the command line window type...
!<DIR>sos.help
Where the <DIR> is the path to the appropriate 'sos.dll' file. For example, to utilise the 'sos.dll' file for Framework 2.0 type "!C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos.help".
Note 1: the debugger application comes with its own 'sos.dll' for Framework 1.1 that is located under the sub-directory of the 'WinDbg' application called 'clr10'.
Note 2: to save having to type the path of the 'sos.dll' file it can be copied to another directory.
After pressing enter, the CLI Window will print all the available commands that this helper library provides. For example, to get a readable version of the exception type...
!pe
...to print the exception that has occurred.
Now to be fair - I haven't a clue why this scenario occurred. Why the SDK JITdebugger didn't invoke? (And I tried this on 3 different machines and reinstalled the OS on each machine at least twice?) Was there some kind of restriction on Windows XP Home or maybe even an MS Update that is preventing some exploit but also causes this issue - who knows?
Anyhoo, if this was useful then drop a line or if you have some killer alternative that doesn't involve gambling in Eastern Europe, enhancing my already perfect physique or purchasing mediation cheaply then drop a comment.
M