Windows Explored

Everyday Windows Desktop Support, Advanced Troubleshooting & Other OS Tidbits

Get Last Error

Posted by William Diaz on July 14, 2012


Often times when doing some basic crash or hang analysis on a program, !analyze –v is not going to cut it because the heuristics engine is not going to reveal an interesting stack. Or maybe I don’t know what I’m looking for. Or maybe I don’t know advanced WinDbg debug techniques. Or … whatever. I define an “interesting” stack is one that contains unexpected components. If I don’t see it, I usually move on to some other techniques.

One of the things I try when a dump has nothing to offer me is to just take a look at the last error thrown. To do this, simply employ the get last error command, !gle. For example, an Outlook crash (which can be notoriously difficult to analyze even for the advanced Windbg enthusiast) I was asked to examine where the !analyze –v heuristics engine wasn’t telling me anything meaningful (at least to me) and where !gle might help:

 

STACK_TEXT: 
773bdff5 ntdll!RtlFreeHeap+0x64
66a49ed9 AcXtrnal!NS_FaultTolerantHeap::APIHook_RtlFreeHeap+0x61
753a4962 KERNELBASE!LocalFree+0x27
6a5602bb OLMAPI32!RTFSyncCpid+0x40bf5
6a515958 OLMAPI32!DllCanUnloadNow+0x4dd
6a5443da OLMAPI32!RTFSyncCpid+0x24d14
6a5711f5 OLMAPI32!MAPIOpenFormMgr+0x62a

0:000> !gle
LastErrorValue: (Win32) 0x6 (6) – The handle is invalid.
LastStatusValue: (NTSTATUS) 0xc0150008 – The requested lookup key was not found in any active activation context.

 

I’m not sure what I have here. Maybe this is not the problem thread. You can look at all errors in all threads by adding the –all switch. The third thread down throws a more promising error.

0:000> !gle -all
Last error for thread 0:
LastErrorValue: (Win32) 0x6 (6) – The handle is invalid.
LastStatusValue: (NTSTATUS) 0xc0150008 – The requested lookup key was not found in any active activation context.

Last error for thread 1:
LastErrorValue: (Win32) 0 (0) – The operation completed successfully.
LastStatusValue: (NTSTATUS) 0 – STATUS_WAIT_0

Last error for thread 2:
LastErrorValue: (Win32) 0 (0) – The operation completed successfully.
LastStatusValue: (NTSTATUS) 0xc0000135 – {Unable To Locate Component}  This application has failed to start because %hs was not found. Re-installing the application may fix this problem.

 

Missing components (DLLs, for example) are often causes for applications crashes. In this case, disabling an add-in was a workaround to resolve the issue. As the error states, the logical thing to do would be to reinstall the application, so we can deduce that we should start by reinstalling the add-in that was disabled.

You can also further investigate this suspicion by dumping the thread for this error. To do that, switch the examine thread to where the error is using ~ns and use the thread environment block command, !teb.

0:000> ~2s
eax=000002c4 ebx=1c552910 ecx=00000000 edx=00000000 esi=00000019 edi=00000000
eip=7736013d esp=03d1f648 ebp=03d1f6e4 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!ZwWaitForMultipleObjects+0x15:
7736013d 83c404          add     esp,4
0:002> !teb
TEB at 7efd7000
    ExceptionList:        03d1f6d4
    StackBase:           03d20000
    StackLimit:           03d1e000
    SubSystemTib:         00000000
    FiberData:            00001e00
    ArbitraryUserPointer: 00000000
    Self:                 7efd7000
    EnvironmentPointer:   00000000
    ClientId:             00001b0c . 00001094
    RpcHandle:            00000000
    Tls Storage:          003c51b8
    PEB Address:          7efde000
    LastErrorValue:       0
    LastStatusValue:      c0000135
    Count Owned Locks:    0
    HardErrorMode:        0

 

Stacklimit and StackBase are the address ranges you are going to dump. Use the display memory command (d) and format type (see Windbg help for details) for the desired output, unicode in this case.

ddu 03d1e000 03d20000

 

After the dump is complete, you can manually scan the output for printable characters like DLL for signs of the possible missing component or use the search command. Then examine the system for these DLLs.

In fact, you can confirm this is the problem thread by also dumping it to resolve modules and functions and find the pattern in the !analyze –v output from earlier by using dds instead of ddu:

03d1f720  66a49497 AcXtrnal!NS_FaultTolerantHeap::APIHook_RtlAllocateHeap+0x1ca
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: