While writing up some code, I noticed that an exception was being generated but not caught by some code that I had written for a Winforms application. As it turns out, the exception details were dumped to the output window in Visual Studio .NET but the level of detail seemed to point to an error in a third party control. Puzzled, and not sure where to really start, I remembered that you could instruct VS.NET to break into your code at the point where an exception was thrown, even if you chose not to handle it and the debugger would otherwise not break on it.
To instruct VS.NET to break on unhandled exceptions, or at the point the exception is thrown, select Debug / Exceptions:
This will bring up the Exceptions window where you can specify which specific exceptions you want to break on, or to break on any type of exception. Since I knew that the type of exception being thrown was of System.ArgumentException, I decided instruct VS.NET to break when that type of exception is thrown:
After I had made this change and rerun my code, I easily spotted the problem and was able to correct it. If I did not know how to do this, I could have spent a lot of extra time stepping through the code or putting in extra Trace statements to find the point where the exception was being generated.
Configuring the IDE to break on exceptions can be useful to jump to the line of code immediately, rather than having to manually set a breakpoint in your code, and can signficantly reduce the amount of time you spend debugging.
Recently, I came across an interesting and cryptic runtime error message for my Windows Forms application after I did an xcopy deployment. The error dialog was from the “Common Language Runtime Debugging Services“ and informed me that, for some unknown (and unspecified) reason my application generated an unhandled runtime error and could not continue.
The error dialog did not specify any detailed reason for the failure, and simply refused to execute my program any further. This error puzzled me and, even though I had some good diagnostic code embedded throughout the application, no diagnostics were being generated. It led me to believe that the problem was not within the program itself, but possibly a error generated during the process of loading one of my referenced assemblies.
To find out more, I setup a test deployment environment using VMWare that mirrored my target deployment environment. One of the main advantages of using VMWare is that you can set up multiple “virtual machines” to test your software deployment under various operating systems and software configurations. Even more nifty is the ability to specify a baseline image as non-persistent -- meaning that any changes you make during a session are discarded after you power down the virtual machine. That makes it great to test and tweak to your hearts content, without worrying about restoring your environment to a pre-test state.
After deploying my application to the virtual machine, I ran it and it failed again with the not so friendly CLR debugging services error dialog. Puzzled, I searched Google Groups for some enlightenment and came across a post by Frank Racis who suggested launching the application from the command prompt and redirecting the stderr output to the console, which generated a text file for me with the stack trace of the entire exception message. Thanks to this tip I quickly discovered that the CLR was unable to load one of my referenced dlls because it failed the strong name validation. (For more information about redirecting your input, output, and error streams see “Using command redirection operators” in Windows Help).
It's too bad that the CLR error dialog could not give me any more information than what it did without having to resort to redirecting the output to the console. Even worse is that there doesn't seem to be any way that I can avoid this problem in the future (or at least customize the dialog to fail gracefully and report the error in a more helpful way). Hopefully this tip will save you similar frustration in the future if this problem ever pops up in one of your applications.