Microsoft Visual Studio now sports the ability to debug dumps of managed applications without delving into the notorious world of windbg and sos.dll. This article explains the new simplified dump debugging experience with Microsoft Visual Studio 2010.
Since the advent of computing, production mode application failures have caused many developers to grimace in pain because of the lack of ability to debug on a production server which could amount to huge monetary impact on business operations). Since these developers don't have access to the live process, they ask for the next best thing - a memory dump.
On the other hand, application crashes produce Watson dumps which can also be used to examine the state of the process at the time of the process and can be used to find the root cause of the failure.
What Are Dumps?
So, what are these dumps you talk about? A dump is defined as a representation of a working application at a particular state in time. What that means is that a dump is a snapshot of the application. Dumps are of three major types:
- Mini Dump - The dumps generated by Watson in its default mode are minidumps. These dumps contain loaded modules, call stack information. The
windbg command to generate minidumps is
".dump /m <dumpfile>".
- Heap Dump - In addition to loaded modules, these also contain heap memory. The
windbg command to generate heap dumps is
".dump /mw <dumpfile>".
- Full Dump - These contain all the information about the process. The windbg command to generate full-dumps is
".dump /ma <dumpfile>".
Debugging Story for Managed Dumps in Microsoft Visual Studio 2008
In Microsoft Visual Studio 2008, because of the lack of API support in .NET framework 3.5, there was only native dump debugging. If you wanted to do managed dump debugging, you would load the dump in
windbg and load the
sos.dll extension or the
sosex.dll extension (SOSEX v2 Now available here).
Change in Debugging Interfaces in .NET Framework 4.0
The CLR folks over at the .NET framework team added support to debug dumps in the
ICorDebug api. Details of the API changes are mentioned at the blog post titled, ICorDebug re-architecture in CLR 4.0. These changes mean that we no longer have to do native style debugging (windbg/sos) of a .NET framework 4.0 dump; rather, we can use VS 2010 or
mdbg (the sample managed debugger which ships with
.NET Framework 4.0 SDK) to do managed dump debugging.
How Do I Get Dumps of Managed Applications?
There are multiple ways you get dumps of managed applications.
- You can get dumps from Watson via application crashes handled by Windows Error Reporting.
- You can use Windows Task Manager and right click on a process and create a dump. One caveat though, dumps of 32 bit managed processes cannot be properly generated using this method on 64 bit machines.
- You can use Microsoft Visual Studio to snap a dump by attaching to a process and selecting "Save Dump as" option under Debug menu.
Exercise: Managed Dump debugging
Now that we have our dumps, let us go through an exercise of debugging dumps using managed debuggers like
mdbg and Microsoft Visual Studio 2010. Let us write a small application and then create a dump for debugging purposes.
public static void Main()
Console.WriteLine("Take a dump now");
Compile the above file
reader.cs in the debug mode to generate symbols to facilitate debugging.
C:\windows\microsoft.net\framework\v4.0.30319\csc /debug+ /optimize- reader.cs
reader.exe and snap a dump using either using Windows explorer or Microsoft Visual Studio 2010.
Dump debugging using MDBG
Once you have a dump file, open Microsoft Visual Studio 2010 command prompt by going to Start -> All programs -> Microsoft Visual Studio 2010 -> Microsoft Visual Studio Tools -> Microsoft Visual Studio Tools Command prompt.
mdbg.exe at the command prompt and execute as below
MDbg (Managed debugger) v4.0.30319.1 (RTMRel.030319-0100) started.
Copyright (C) Microsoft Corporation. All rights reserved.
For information about commands type "help";
to exit program type "quit".
mdbg> opendump reader.dmp
DBI path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordbi.dll
No exception in dump, current thread will be chosen randomly.
Dump loaded successfully.
[p#:0, t#:1] mdbg> pa c:\temp\dumpdebugging
Path set to: c:\temp\dumpdebugging
Error: No source location
[p#:0, t#:1] mdbg> w
[Internal Frame, 'M-->U']
[IL Method without Metadata]
*0. System.IO.__ConsoleStream.ReadFileNative (source line information unavailable)
1. System.IO.__ConsoleStream.Read (source line information unavailable)
2. System.IO.StreamReader.ReadBuffer (source line information unavailable)
3. System.IO.StreamReader.ReadLine (source line information unavailable)
4. System.IO.TextReader+SyncTextReader.ReadLine (source line information unavai
5. Reader.Main (c:\temp\dumpdebugging\reader.cs:7)
[p#:0, t#:1] mdbg>
Here is the description of the
mdbg commands we used:
- Opendump - this opens the dump for managed debugging.
- Pa - this sets the path to the symbols for the application. On my machine, the sources and symbols were in the
- w - shortcut for where - this shows the callstack of the active thread.
We can see that we were in the
ReadLine operation when the dump was taken.
Dump debugging using Microsoft Visual Studio 2010
To debug.NET Framework 4.0 process dumps in Visual Studio 2010, you will need Visual Studio Pro, VS Premium or VS Ultimate SKU. VS 2010 Express SKUs that do not offer the ability to debug dumps. You can read more details here, Dump Requirements and Limitations. Open the dump file like any other source file in Microsoft Visual Studio 2010. Your screen would like like the image below.
[select the dump to debug in VS File open menu.png]
Next, set the symbol path in Visual Studio to include symbols for the application being debugged. You get to the following screen by going to Tool -> Options and selecting debugging option in the left side of the treeview and expanding it and selecting Symbols.
[set symbols in VS.png]
After setting the symbols, select Debug with Mixed option on the home page.
[select debug with mixed option.png]
Once you click, Microsoft Visual Studio will become busy and load symbols for your application into a cache location (if you have not specified, it will cache to a system default location).
You will now see a callstack and your source file will be open and the cursor will point to the
Console.Readline line as the point of last execution.
[VS debug view.png]
If you had some variables in your application, you would be able to see them in your autos and local window. In fact, most of your debugging experience here will be mostly similar to debugging a live process except that you will not be able to step-into, step-out or step-over (since this is a dump, you cannot change process state).
Microsoft Visual Studio 2010 now allows developers to debug dumps of .NET Framework 4.0 applications. Hopefully this article has taught you how to do basic managed dump debugging. Thanks for reading.