CODEWITHSUNDEEP
windbg
Santhosh77
Santhosh77

Reputation: 73

Windows debugging - WinDbg

I got the following error while debuggging a process with its core dump.

0:000> !lmi test.exe
Loaded Module Info: [test.exe] 
         Module: test
   Base Address: 00400000
     Image Name: test.exe
   Machine Type: 332 (I386)
     Time Stamp: 4a3a38ec Thu Jun 18 07:54:04 2009
           Size: 27000
       CheckSum: 54c30
Characteristics: 10f  
Debug Data Dirs: Type  Size     VA  Pointer
                 MISC   110,     0,   21000  [Debug data not mapped]
                  FPO    50,     0,   21110  [Debug data not mapped]
             CODEVIEW 31820,     0,   21160  [Debug data not mapped] - Can't validate symbols, if present.
     Image Type: FILE     - Image read successfully from debugger.
                 test.exe
    Symbol Type: CV       - Symbols loaded successfully from image path.
    Load Report: cv symbols & lines

Does any body know what the error CODEVIEW 31820, 0, 21160 [Debug data not mapped] - Can't validate symbols, if present. really mean?

Is this error meant that i can't read public/private symbols from the executable?

If it is not so, why does the WinDbg debugger throws this typr of error?

Thanks in advance, Santhosh.

Upvotes: 0

Views: 1101

Answers (2)

Anthony Albert
Anthony Albert

Reputation: 23

Debug data not mapped can mean the section of the executable that holds the debug information hasn't been mapped into memory. If this is a crash dump, your options are limited, but if it's a live debug session. you can use the WinDbg .pagein command to retrieve the data. To do that you need to know the address to page in. If you use the !dh command on the module start address (which you can see with lm - in my case, lm mmsvcr90 for msvcr90.dll), you may see something like this (scrolling down a ways):

Debug Directories(1)
    Type       Size     Address  Pointer  
    cv           29       217d0    20bd0    Can't read debug data cb=0

This shows you that the debug data is at offset 217d0 from the module start and is length 29. If you attempt to dump those bytes you'll see (78520000 is the module's start address):

kd> db 78520000+217d0 l29  
785417d0  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????  
785417e0  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????  
785417f0  ?? ?? ?? ?? ?? ?? ?? ??-??                       ?????????

If you execute .pagein /p 82218b90 785417d0, then F5, when the debugger breaks back in you'll see (82218b90 is the _EPROCESS address of the process that I'm debugging):

kd> db 78520000+217d0 l29  
785417d0  52 53 44 53 3f d4 6e 7a-e8 62 44 48 b2 54 ec 49  RSDS?.nz.bDH.T.I  
785417e0  ae f1 07 8c 01 00 00 00-6d 73 76 63 72 39 30 2e  ........msvcr90.  
785417f0  69 33 38 36 2e 70 64 62-00                       i386.pdb.

Now executing .reload /f msvcr90.dll will load the symbols. For a crash dump, if you can find the 0x29 bytes you're missing (from another dump maybe), you may be able to insert them and get the symbols loaded that way.

Upvotes: 1

anonymous
anonymous

Reputation: 3544

Have you set your symbol path for WinDbg (see Step 2 @ http://blogs.msdn.com/iliast/archive/2006/12/10/windbg-tutorials.aspx) and are your PDB files in the symbol path?

I assume you're testing an executable built in debug mode which generates the necessary PDB files.

Upvotes: 0

Related Questions