WinDbg : Deferred Symbol Loading

WinDbg : Deferred Symbol Loading

Sometimes WinDbg won't load the symbols for a particular module. If you want to debug that module or process call stacks containing that module's symbols you are going to be in for a surprise. So lets try and see what can be done to resolve the situation.

16.0: kd> lmv m mydll.dll

start             end                 module name

Unable to enumerate user-mode unloaded modules, NTSTATUS 0xC0000147

So looks like the module was not found. Lets try and see if the module is actually there.

16.0: kd> lm

start             end                 module name

00000000`00b30000 00000000`00b55000   MySvc   (deferred)             

00000000`704f0000 00000000`70513000   MyDll   (deferred)             

00000000`710b0000 00000000`711e3000   msxml3     (deferred)             

00000000`711f0000 00000000`711f7000   WSOCK32    (deferred)             

00000000`71200000 00000000`7135f000   sis        (deferred)             

00000000`73a10000 00000000`73a6c000   wow64win   (deferred)             

00000000`73a70000 00000000`73aaf000   wow64      (pdb symbols)          d:\websyms\wow64.pdb\7818D2D03E1C4936B815636B5EC869B21\wow64.pdb

00000000`747e0000 00000000`7497e000   COMCTL32   (deferred)             

00000000`74e20000 00000000`74e28000   wow64cpu   (pdb symbols)          d:\websyms\wow64cpu.pdb\C8D4F6038D014F62AB0C6A28A7FAFEF21\wow64cpu.pdb

00000000`74ed0000 00000000`74edc000   CRYPTBASE   (deferred)             

00000000`771a0000 00000000`77349000   ntdll      (pdb symbols)          d:\websyms\ntdll.pdb\6192BFDB9F04442995FFCB0BE95172E12\ntdll.pdb

Unloaded modules:

fffff880`01846000 fffff880`01854000   crashdmp.sys

fffff880`01854000 fffff880`0185e000   dump_storport.sys

fffff880`0185e000 fffff880`0187b000   dump_LSI_SAS.sys

fffff880`0187b000 fffff880`0188e000   dump_dumpfve.sys

Unable to enumerate user-mode unloaded modules, NTSTATUS 0xC0000147

Aaah, so this the problem, the module is present but the symbols are not. For the more keen observer, this looks to be a dump from a 64 bit machine. Hence the 64 bit addresses and the presence of wow64.

Okay, lets try and see what is there at the address where the module is loaded.

16.0: kd> db 00000000`704f0000 

0000:0000  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

0000:0010  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

0000:0020  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

0000:0030  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

0000:0040  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

0000:0050  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

0000:0060  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

0000:0070  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

Ouch!!!!

Now lets try to load the symbols. However, to do so, we need to calculate the size of the module.

70513000 - 704f0000 = 0x23000

Lets use reload to force load the symbols.

16.0: kd>.reload /i MyDll.Dll= 704f0000 

This should load the symbols for the Dll and map it to the address given. At this point any reffernces to this address zone will lead WinDbg to use the symbols mapped to it.

It is important to map the symbols to the right address, else the stack dumps will be gibberish.