DCSIMG
Open Kernel Crash Dumps in Visual Studio 11 - All Your Base Are Belong To Us

All Your Base Are Belong To Us

Mostly .NET internals and other kinds of gory details

Open Kernel Crash Dumps in Visual Studio 11

A dream is coming true. A dream where all the debugging you’ll ever do on your developer box is going to be in a single tool – Visual Studio.

In a later post, I will discuss device driver development in Visual Studio 11, which is another dream come true. For now, let’s take a look at how Visual Studio can open kernel crash dumps and perform crash analysis with all the comfy tool windows and UI that we know and love.

To perform kernel crash analysis in Visual Studio 11, you will need to install the Windows Driver Kit (WDK) on top of Visual Studio. Go on, I’ll wait here.

First things first – you go to File | Open Crash Dump, and you’re good to go:

image

Visual Studio will load that dump file and open the initial analysis window – which is a new tool called Debugger Immediate Window.

image

Note that the Threads window displays processors, and you can switch between processors to examine their call stack in the Call Stack window. Finally, if you’re dead serious and want to run some real debugger commands, there’s command-line IntelliSense for debugger commands, complete with a documentation tooltip.

image

In case you’re wondering, there is still room for WinDbg as a standalone tool. The obvious difference between WinDbg and Visual Studio – other than usability – is installation size. You can copy WinDbg over to a machine or run it from a USB stick, which is amazing in a production environment. So no, WinDbg isn’t redundant yet, but Visual Studio has just earned itself some street cred in the most hardcore debugging circles.

Posted: Oct 14 2011, 05:48 PM by Sasha Goldshtein | with 7 comment(s)
תגים:, , ,

Comments

Mike Fishre said:

Is it possible to load .NET's debugging extensions (sos.dll) into VS11 like you can with WinDbg?

# October 18, 2011 8:56 AM

Sasha Goldshtein said:

Yes, you can use the .load command in the Debugger Immediate Window. In fact, you can use any debugger command that you can use in WinDbg - when using the Windows Debugger engine.

# October 19, 2011 12:23 PM

Josh said:

Is there a way to launch the debugger immediate window when debugging an application, rather than opening crash dumps?  

Debug->Windows->Immediate appears to be the old immediate window, not the WinDbg equivalent.

# November 3, 2011 12:12 AM

Sasha Goldshtein said:

@Josh: When you attach the debugger (or launch the application from within VS) you need to specify that you want to use the Windows Debugger and not Visual Studio Debugger. Then, you will have access to the Debugger Immediate Window.

# November 6, 2011 8:32 AM

Josh said:

Awesome!  Thanks.  

Got it working with Attach by selecting "Windows User Mode Debugger" instead of "Default" in the transport dropdown, which will be great for now - saves switching debuggers when looking at more complex issues.

I tried changing my default debugger when launching C++ projects, but "Local Windows Debugger" on the Debugging tab of the project properties is the current selection and there doesn't seem to be a more appropriate selection under "Debugger to Launch:" dropdown.

# November 7, 2011 1:12 AM

Josh said:

One small caveat - "Debugging a 64-bit dump of a 32-bit process is not supported, place collect a 32-bit dump of a 32-bit process"  .  

Windows 8 Task Manager creates 64-bit dumps - so back to WinDbg for them.

# November 7, 2011 6:51 AM

Sasha Goldshtein said:

@Josh, it's in general not such a great idea to debug 64-bit dumps of 32-bit processes. I mean, it works, but why bother?

You can use the 32-bit Task Manager on a 64-bit system to take the dump. It's in C:\windows\syswow64\taskmgr.exe

# November 15, 2011 1:04 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Enter the numbers above: