Debugging Tip: Troubleshooting deployment runtime errors
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.