Archive for April 21st, 2008

What was this process doing?

Monday, April 21st, 2008

This is a common question we have when faced with stack traces for which we don’t have symbols. Consider the following stack trace from a complete memory dump where a bugcheck thread belongs to one graphical application:

2: kd> kL 100
ChildEBP RetAddr 
aa1999b4 8082d800 nt!KeBugCheckEx+0x1b
aa199d78 8088a262 nt!KiDispatchException+0x3a2
aa199de0 8088a216 nt!CommonDispatchException+0x4a
aa199e5c bfe7e5b7 nt!KiExceptionExit+0x186
aa19a110 bf8b2fe6 win32k!GrePolyPatBlt+0x45
aa19a148 bf89422b win32k!FillRect+0x58
aa19a16c bf8942f7 win32k!xxxPaintRect+0x70
aa19a19c bf8942ac win32k!xxxFillWindow+0x3e
aa19a1b4 bf8adf6e win32k!xxxDWP_EraseBkgnd+0x51
aa19a214 bf884771 win32k!xxxRealDefWindowProc+0x318
aa19a22c bf8847a1 win32k!xxxWrapRealDefWindowProc+0x16
aa19a248 bf8c1459 win32k!NtUserfnNCDESTROY+0x27
aa19a280 8088978c win32k!NtUserMessageCall+0xc0
aa19a280 7c8285ec nt!KiFastCallEntry+0xfc
0013f68c 7739d1ec ntdll!KiFastSystemCallRet
0013f6e0 7739c6ae USER32!NtUserMessageCall+0xc
0013f6fc 7739c718 USER32!RealDefWindowProcW+0x47
0013f744 3003a5b3 USER32!DefWindowProcW+0x72
0013f75c 300a0d72 Application+0x3a5b3
0013f7bc 300a0cb2 Application+0xa0d72
0013f7f4 7739b6e3 Application+0xa0cb2
0013f820 7739b874 USER32!InternalCallWinProc+0x28
0013f898 7739c8b8 USER32!UserCallWinProcCheckWow+0x151
0013f8f4 7739c9c6 USER32!DispatchClientMessage+0xd9
0013f91c 7c828536 USER32!__fnDWORD+0x24
0013f91c 808308f4 ntdll!KiUserCallbackDispatcher+0x2e
aa19a564 8091d6d1 nt!KiCallUserMode+0x4
aa19a5bc bf8a2622 nt!KeUserModeCallback+0x8f
aa19a640 bf8a242d win32k!SfnDWORD+0xb4
aa19a688 bf8a13d9 win32k!xxxSendMessageToClient+0x176
aa19a6d4 bf8a12ee win32k!xxxSendMessageTimeout+0x1a6
aa19a6f8 bf8c1342 win32k!xxxSendMessage+0x1b
aa19a71c bf85e0a1 win32k!xxxSendEraseBkgnd+0x5c
aa19a73c bf85dee1 win32k!xxxSimpleDoSyncPaint+0xc6
aa19a758 bf8ae16d win32k!xxxInternalDoSyncPaint+0x12
aa19a7b4 bf884771 win32k!xxxRealDefWindowProc+0x753
aa19a7cc bf8847a1 win32k!xxxWrapRealDefWindowProc+0x16
aa19a7e8 bf8c1459 win32k!NtUserfnNCDESTROY+0x27
aa19a820 8088978c win32k!NtUserMessageCall+0xc0
aa19a820 7c8285ec nt!KiFastCallEntry+0xfc
0013f91c 7c828536 ntdll!KiFastSystemCallRet
0013f91c 808308f4 ntdll!KiUserCallbackDispatcher+0x2e
aa19ab00 8091d6d1 nt!KiCallUserMode+0x4
aa19ab58 bf8a2622 nt!KeUserModeCallback+0x8f
aa19abdc bf8a242d win32k!SfnDWORD+0xb4
aa19ac24 bf8c4177 win32k!xxxSendMessageToClient+0x176
aa19ac94 bf89b829 win32k!xxxReceiveMessage+0x2b5
aa19ace4 bf89c4d9 win32k!xxxRealInternalGetMessage+0x1da
aa19ad48 8088978c win32k!NtUserPeekMessage+0x42
aa19ad48 7c8285ec nt!KiFastCallEntry+0xfc
0013fbd8 7c828536 ntdll!KiFastSystemCallRet
0013fc04 7739bde5 ntdll!KiUserCallbackDispatcher+0x2e
0013fc30 7739be5e USER32!NtUserPeekMessage+0xc
0013fc5c 3002baa0 USER32!PeekMessageW+0xab
0013fc84 3002b556 Application+0x2baa0
0013fca8 3000abf5 Application+0x2b556
0013fcf4 30005dfd Application+0xabf5
0013ff34 3000248c Application+0x5dfd
0013ffc0 77e6f23b Application+0x248c
0013fff0 00000000 kernel32!BaseProcessStart+0x23

The thread seems to be doing some drawing in response to WM_ERASEBKGND message generated from the code processing WM_TIMER:

2: kd> kv 100
aa19a6f8 bf8c1342 be63f8b8 00000014 91010979 win32k!xxxSendMessage+0×1b
aa19a71c bf85e0a1 be63f8b8 00000000 00000001 win32k!xxxSendEraseBkgnd+0×5c
0013fc5c 3002baa0 0013fcc0 00000000 00000000 USER32!PeekMessageW+0xab

2: kd> dd 0013fcc0 l4
0013fcc0  00000000 00000113 000066c2 00000000

The first parameter to PeekMessage function is a pointer to MSG structure whose second member is a message code (from MSDN): 

BOOL PeekMessage(
    LPMSG lpMsg,
    HWND hWnd,
    UINT wMsgFilterMin,
    UINT wMsgFilterMax,
    UINT wRemoveMsg

typedef struct {
    HWND hwnd;
    UINT message;
    WPARAM wParam;
    LPARAM lParam;
    DWORD time;
    POINT pt;

In WinUser.h we can find message codes:

#define WM_ERASEBKGND  0x0014
#define WM_TIMER       0x0113

Now we can ask the next troubleshooting question: what was the application file loaded before the system crash? We know that the application uses EXT file extension for its data. If we look at the handle table we find the only one such instance of File object:

2: kd> !handle
processor number 2, process a31a4a08
PROCESS a31a4a08  SessionId: 1  Cid: 2440    Peb: 7ffd7000  ParentCid: 1180
    DirBase: bffca720  ObjectTable: ddc38eb8  HandleCount: 291.
    Image: Application.EXE

Handle table at dcb65000 with 291 Entries in use


03f4: Object: a2ee85b0  GrantedAccess: 00120089 Entry: dcb657e8
Object: a2ee85b0  Type: (a55c8ca0) File
    ObjectHeader: a2ee8598 (old version)
        HandleCount: 1  PointerCount: 1
        Directory Object: 00000000  Name: \Profiles\MYNAME\LOCALS~1\Temp\APPDATA\MyFile.ext {HarddiskVolume3}


Now we can check other crash dumps to see whether there is any consistency in file names.

- Dmitry Vostokov @ -