Отладка Windows - WinDbg - PullRequest
Новая
       6

Отладка Windows - WinDbg

0 голосов
/ 14 мая 2010

Я получил следующую ошибку при отладке процесса с дампом ядра. 

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

Кто-нибудь знает, что на самом деле означает ошибка CODEVIEW 31820, 0, 21160 [Debug data not mapped] - Can't validate symbols, if present.

Означает ли эта ошибка, что я не могу прочитать публичные / приватные символы из исполняемого файла?

Если это не так, почему отладчик WinDbg выдает этот тип ошибки?

Спасибо заранее, Сантош.

Ответы [ 2 ]

1 голос
/ 09 января 2015

Отладочные данные, которые не отображаются, могут означать, что раздел исполняемого файла, который содержит отладочную информацию, не был отображен в памяти. Если это аварийный дамп, ваши возможности ограничены, но если это живой сеанс отладки. Вы можете использовать команду WinDbg .pagein для получения данных. Для этого вам нужно знать адрес страницы. Если вы используете команду! Dh на начальном адресе модуля (который вы можете увидеть с помощью lm - в моем случае, lm mmsvcr90 для msvcr90.dll), вы можете увидеть что-то вроде это (прокручивая пути вниз): 

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

Это показывает, что данные отладки по смещению 217d0 от начала модуля имеют длину 29. Если вы попытаетесь сбросить эти байты, вы увидите (78520000 - начальный адрес модуля): 

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

Если вы выполните .pagein / p 82218b90 785417d0, то F5, когда отладчик перестанет работать, вы увидите (82218b90 - это адрес _EPROCESS процесса, который я отлаживаю): 

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.

Теперь выполнение .reload / f msvcr90.dll загрузит символы. Для аварийного дампа, если вы можете найти недостающие байты 0x29 (возможно, из другого дампа), вы сможете вставить их и загрузить символы таким образом.

0 голосов
/ 14 мая 2010

Вы установили свой путь символа для WinDbg (см. Шаг 2 @ http://blogs.msdn.com/iliast/archive/2006/12/10/windbg-tutorials.aspx) и находятся ли ваши файлы PDB в пути символа?

Я предполагаю, что вы тестируете исполняемый файл, встроенный в режим отладки, который генерирует необходимые файлы PDB.

...