Sunday, July 30, 2017

windbg SOS CLR

This post is a reminder to myself, and I hope it will help others. About once a year I find a .NET program will run fine in development but crash and vanish when deployed to production with the generic message "this program has stopped working".

It's usually caused by some subtle environmental difference between the testing and live environments, such as a missing file or a bad configuration setting. Following are the steps I can never remember to help in this situation:

1. Get a copy of "Debugging Tools for Windows (x64)" (which was needed in my case) -- This is easier than it sounds, as there are many downloads available for a wide variety of platforms. I can't remember exactly how I found the right one for me, so proceed carefully.

2. Run windbg.exe and enter these commands:

.load SOS
sxe clr

3. Either launch the program to be debugged or attach to the process of a program that's already running. Start doing things in the program.

4. If the program throws an Exception the debugger will pause and you can issue this command to hopefully see a CLR stack trace to know where the problem is in managed code:

!clrstack

I won't waste space on the technical details here as this is just a reminder post. There are lots of online articles that explain what these windbg commands actually do. And there a lot more interesting commands and tricks to peek into the internals of what managed code is doing. Look for tutorials or cheat-sheets on this subject.

No comments:

Post a Comment