This will be the first of a few posts on managed debugging… just too much to discuss in one post.
Ever had one of those moments (maye not a single moment, but in general an experience) where you learn something and think to yourself “wow, this is a big eye opener… this is something I need to investigate?”
My latest one was this past August. I was in the second of two sessions by Tim Walton (MSFT PSS) at the Jacksonville Code Camp]. Tim’s sessions were primarily about some more advanced debugging… when I say advanced I mean more than just using VS.NET simple breakpoints & stepping through code like we all do. In his second session, he discussed & demonstrated why & how memory dump files are so powerful once you know how to use them. It was one of times when you think “you know, I can’t take notes fast enough and absorb the content that I’d like to so just put the notebook down and absorb as much as I can and research later.” Tim told one PSS story about how he used a memory dump and symbols to track down a problem; that story sold me to see the story about the ecommerce company): this is something I had to figure out myself.
There were a few things I was able to walk away with, albeit sans notes:
- Memory dumps were a snapshot of everything in memory at the time the dump is taken.
- When combined with symbols, you can get just about everything you need.. you can map things in memory with real method & variable names.
- Windbg is what you use to view the memory dumps.
Last week, with the help of PSS, a co-worker and I were able to resolve a SharePoint case we’d had open for a while. It was during this case where we took a few dumps of SharePoint Portal Server and ASP.NET that re-energized my desire to figure out how (1) to trigger and load a memory dump into a debugger and (2) how to use the debugger, with symbols, to become a better debugger and thus, a better developer.
In doing some research, I’ve come to realize some good and bad things. First the bad… for a while, it was real hard to find anyone online discussing this topic… either on blogs, articles, or in newsgroups. This was quite disappointing. However (now for the good), recently I stumbled across a few CLR bloggers, most notably Mike Stall’s blog. Mike is responsible (or at least the unofficial spokesman) for the Mdbg (see: Mdbg linkfest) which is a managed debugger written in C# (the source is available in the Mdbg download). Some additional bloggers that are great reads are Yin Jin, Maoni, Joel Pobar, Tess, and Chris Brumme. Mike also recommended this book when trading a few emails with him: Debugging Applications for Microsoft .NET and Microsoft Windows by John Robbins.
One thing I have discoverd is how hard it is to get info on a walkthrough of doing the following:
- Create a memory dump (either manually or configuring your application to trigger a memory dump when a specific or unhandled exception occurs)
- Load this dump in a debugger (Windbg or Mdbg)
- Load symbol files
- Show how you can work within the debugger to actually use it and determine what broke, the call stack at that time, as well as the values in memory.
In the last few days, Mike did post a sample application that obtained a snapshot of a managed callback. While interesting, it doesn’t give you the info I’m looking for.
Ideally, it would be nice to have a utility class that would create memory dumps and ship them to a specific address, similar to the more recent Microsoft applications and their “Would you like to send an error report” dialog upon a crash. Other questions remain though: how will this help me as a MCMS developer? How can this help me as a SharePoint Web Part developer?
If you’re asking “ok, where are you going with this?”, well like I said at the start: this is the first of a few posts. This post was to set the stage for future discussions as my search isn’t finished as this has turned into being a bit of a personal pet project I’ve adopted.
Resources mentioned in this post: