Programming languages these days do their best from keeping you from doing something stupid. We have compile time checking, "managed" code, and garbage collection. We've been led to believe that if you just write the code, in any fashion that meets the requirements of the project, that any missteps you may take in code will be corrected.
That's the case with garbage collection. We've been sold this idea that variables can be created wherever, whenever, and however you want, the runtime environment will clean up after you.
However the following blog post titles (all from the same great author) tell a different story:
Last Friday I spent the day going through a windows dump file tracing down a poorly performing application's problem for a client. With a dump file I have a snapshot of everything going on at that moment in that process (aspnet_wp.exe). It's an interesting challenge. Given that snapshot, it's an interesting to see what you can find out. However, I would assert that not enough developers know how to use it, or even of it's existence.
A quick poll of 12 developers I know showed that only one had ever used WinDBG and he qualified his "yes" vote with "yes, although not very well". Extrapolating that figure would show that 92% of developers cannot debug their application without Visual Studio support.
Do the post titles above inspire confidence in the .NET Framework? If there was a "strange" problem occurring in your application, are confident you could fix it or identify a list of possible problems? Could you do it while the application is running in production?
If your WinDBG skills are lacking, I encourage you to take a little dip into WinDBG and get your feet wet by following the guide from Johan Straarup
Happy debugging!
This blog contains the thoughts and discoveries of Tim Barcz, a technologist with a interests in computer programming technologies.