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: … 0:000> !gle |
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 1: Last error for thread 2: |
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 |
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 |
Windows Explored 
Leave a Reply