Friday, June 12, 2009

Debugging Windows 7

The correct way to debug a crash is to send it to the vendor, but sometimes that isn’t an option. In this case on my Windows 7 RC laptop which had been very stable. Support isn’t really an option on this pre-release software, so in an effort to determine why it had suddenly become unstable I broke down and did some investigation.

Windows 7 by default is configured to capture a kernel memory dump. I resisted the instinct to hard power off the laptop when it blue screened and waited for the memory.dmp file to finish writing. After that the laptop restarted itself, reported the error to Microsoft and offered me no advice.

To examine the dump file I downloaded the Windows Debugging Tools. They did not explicitly state they would work for Windows 7, but I had no problems. I did have to install them from an elevated command prompt to get the install to succeed. After that I started WinDbg from the start menu:


I then configured the debugger to use the Microsoft web symbols by choosing Symbol File Path in the File Menu (it’s that or download the actual symbols which takes too long):




After that I chose File – Open Crash Dump and navigated to c:\windows\memory.dmp. And received an error: “You don’t have permission to open this file”.


I then exited out from the debugger and restarted it by right clicking on the shortcut and choosing Run as administrator. Choose to save the workspace when prompted or you will have to reconfigure the symbol path. Then reopen the memory.dmp file. It opens the debugger and looks like this:


Type: !analyze -v

I got results like this:

0: kd> !analyze -v
* *
* Bugcheck Analysis *
* *

A driver is causing an inconsistent power state.
Arg1: 00000003, A device object has been blocking an Irp for too long a time
Arg2: 84d07c78, Physical Device Object of the stack
Arg3: 82b41ae0, Functional Device Object of the stack
Arg4: 85153f00, The blocked IRP

Debugging Details:


IRP_ADDRESS: 85153f00



IMAGE_NAME: disk.sys

Clicking on the hyperlinked device object in the above output gave me the following information (after a brief wait while the debugger chatted with the symbol server):

0: kd> !devobj ffffffff8511a7e0 f
Device object (8511a7e0) is for:
DR2 \Driver\Disk DriverObject 85633d00
Current Irp 00000000 RefCount 0 Type 00000007 Flags 01002050
Vpb 84cbe3f8 Dacl 8a848b84 DevExt 8511a898 DevObjExt 8511acd8 Dope 84c0a410
ExtensionFlags (0x00000800)
Unknown flags 0x00000800
AttachedDevice (Upper) 85144020 \Driver\partmgr
AttachedTo (Lower) 84d07c78 \Driver\iScsiPrt

A-ha! The iScsiPrt driver. I had recently attached an iSCSI disk and was amazed at how well it worked despite the fact that my laptop was constantly docked, undocked and moved to disconnected networks. Apparently it wasn’t quite as stable as I suspected. I removed the favorite target and volume in the iSCSI control panel applet. Hopefully, that will allow a return to stability.

Despite this small amount of instability, I still adore Windows 7. I never took to Vista despite many attempts on home and work machines, and stayed on Windows XP. Now I cannot imagine going back.

1 comment:

  1. It sounds like you have been having similar problems with Windows 7 as a few other users. A great site to get direct support from Microsoft's product engineers and IT Pro's is Microsoft's Springboard site and Windows 7 forums. -- Microsoft Springboard

    In the bottom right hand corner is a link for direct access to Microsoft's Windows 7 Forums.

    Also, check out the tips / tricks section -- its essential for any Windows 7 RC user.

    Microsoft Windows Client Team