Windows调试-WinDbg

发布于 2024-09-01 21:20:40 字数 1051 浏览 3 评论 0原文

我在使用核心转储调试进程时遇到以下错误。

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 returned] - Can't validatesymbols, if present. 的真正含义是什么？

这个错误是否意味着我无法从可执行文件中读取公共/私有符号？

如果不是这样，为什么 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.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

残龙傲雪 2024-09-08 21:20:40

未映射的调试数据可能意味着保存调试信息的可执行文件部分尚未映射到内存中。如果这是故障转储，则您的选择是有限的，但如果这是实时调试会话。您可以使用 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 字节（可能来自另一个转储），您也许可以插入它们并以这种方式加载符号。

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.

回复收藏 0 原文