Debugging .NET applications

Recently I attended C2C conference in Warsaw. I signed up for the .NET track. The session I was really looking forward to was “Hardcore Production Debugging” by Ingo Rammer. I hoped to learn something that I could use right away in my every day work. Remote debugging may be very painful and it is not easy to find the best approach. I was keen to learn about new easy-to-use tools that would make my life much easier. Unfortunately, the word “Hardcore” in session’s title was there for a reason…

The biggest part of the session was dedicated to WinDBG tool. Its interface is very poor and user-unfriendly. However, Ingo demonstrated that once you learn how to use it, it can be very helpful in finding the reason for application failures.

At first Ingo simulated situation where the developer has access to production machine (with no Visual Studio installed) where they can run WinDBG. Once he started this tool he attached it to the process of sample application that was throwing unhandled exceptions. With a few commands he was able to find out the exception message and the reason for failure. With the same tool Ingo was able to find out the reason for unexpected application exit by attaching breakpoint at the end of app’s process.

Ingo showed us also that remote debugging can be achieved with the WinDBG installed on developers machine and its console version – CDB – on client’s machine. After you configure the port for CDB you can access it from outside using WinDBG (option “Connect to remote session”).

Next, Ingo explained what to do when WinDBG and CDB are also not available on the production machine. He proved that we can find the same error as in the first part by studying the memory dump created for that application. To get the memory dump we can ask the client to create it manually using a simple program (Adplus) or OS built-in functionality (only on Vista) immediately after the error occurs. Then, all we need to do is load the dump into WinDBG (option “Open crush dump”) on the developer’s machine and examine it using the same commands as in the first case.

Finally, Ingo presented simple program GFlags for Windows registry keys modifications that would allow launching CMD/WinDBG immediately after specified process is started and attaching the debugger to this process. This can be handy when an error does not occur regularly and it’s not easy to reproduce. He warned us that you have to be very careful when using that tool and change system’s default settings only if you’re absolutely sure what you’re doing. Registry modifications can cause a lot of damage to your OS if the are not done correctly.

To sum up - the pase of presentation was high so it was not possible to learn all the commands that Ingo was using. The goal of this session was to show to the audience what is possible if we use the presented tools and that it doesn't require much work once you learn how to use them.

The session itself came out to be the highlight of the conference. Mixture of Ingo’s knowledge and charm proved to be the formula for perfect presentation. I just wish Ingo had some more time so we could study the examples more carefully.

Some WinDBG commands used by Ingo:

.hh         Debugger Help
sxe clr     Break on all CLR Exceptions
sxi clr     Ignore CLR Exceptions
sxn clr     Notify on CLR Exception
 
.loadby sos mscorwks   
            Loads SOS Debugging Extension; 
            Enables use of following options:

  !help            
  !printexception (!pe)
  !clrstack
  
  ~            list threads
  !threads     list managed code threads

Some Useful links:
All presented debugg tools for Windows
Ingo's page at Thinktecture
Tess Fernandez blog “If broken it is, fix it you should”

Ingo also recommended book "Debugging .NET" by John Robins.