As mentioned in a previous post, I’ve been tracking down Windows performance issues using the remarkable Windows Performance Toolkit (WPT). Today, I tried launching the Windows Performance Analyzer tool on a fresh Windows 8.1 system but it silently disappeared when trying to load a performance trace. Monday afternoon detective time!
My first step was to isolate the problem even further. On the affected system it turned out that even clicking the File menu in Windows Performance Analyzer resulted in a silent crash.
Perhaps the Windows Event Viewer could shed some light on the situation? Not much, in this case:
Application: wpa.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: exception code c0000005, exception address 0000000000000000
If only I had a stack trace. There are a few ways to get the stack trace of a crashing application; I chose to use my favourite debugger, WinDbg. Briefly, WinDbg is a Microsoft debugger that can be used to debug both user mode applications as well as kernel mode drivers. It is also portable — I actually keep a copy of it on a USB stick for cases like this.
Before launching WinDbg, I set the symbol path so that the debugger could download any necessary symbols from the Microsoft public symbol server. You can set the symbol path within WinDbg, but I’ve recently learned that you can instead use a system environment variable:
After launching WinDbg, choosing File -> Open… and selecting the crashing executable file, I ended up with the screen below. We see the debugger breaking into the application during startup. I didn’t need to configure anything else, so I just hit F5.
Next, I reproduced the silent crash in my application. At this point, WinDbg broke into the application for a second time. Notice the access violation that the Event Viewer told us about.
Finally, it was time for the magic WinDbg analysis command:
I won’t reprint all the output here, but basically this command prompts WinDbg to spit out a bunch of diagnostic information about what has gone wrong. I was only interested in the stack trace. Here’s an excerpt:
0x0 igdumdim64!OpenAdapter+0xe4a99 igdumdim64!OpenAdapter+0xf1af5 igdumdim64!OpenAdapter+0xb6f51 d3d9!CD3DDDIDX10::TexBlt+0x7d d3d9!CD3DBase::TexBlt+0x51 d3d9!CMipMap::UpdateDirtyPortion+0x10c d3d9!CResourceManager::UpdateVideoInternal+0x144 d3d9!CResourceManager::UpdateVideo+0x31 d3d9!CD3DBase::UpdateTextures+0x3dd d3d9!CD3DBase::DrawPrimitive+0x221 wpfgfx_v0400!CD3DDeviceLevel1::DrawPrimitiveUP+0x512 wpfgfx_v0400!CD3DDeviceLevel1::FlushBufferFan+0x30 wpfgfx_v0400!CD3DDeviceLevel1::RenderTexture+0x252 wpfgfx_v0400!CD3DDeviceLevel1::TestRenderTargetFormat+0x267 wpfgfx_v0400!CD3DDeviceLevel1::CheckRenderTargetFormat+0x76 wpfgfx_v0400!CHwDisplayRenderTarget::Create+0x96 wpfgfx_v0400!CDesktopRenderTarget::Init+0x128 ...
It was clear by looking at the stack trace that something was going wrong in the graphics stack. d3d is part of Direct3D and doing a quick search on igdumdim64 reveals that it is a driver for Intel HD Graphtics 4000.
I fired up Windows Device Manager to see if there was a new version of the Graphics Adapter driver.
Yes! There was indeed a newer version of the driver. After updating the driver in Device Manager, I was finally able to click on the File menu in Windows Performance Analyzer. Wasn’t that exciting?! Now back to learning how to become a human data miner…