中国服务器网
  1. 中国服务器网
  3. 使用WinDBG来识别有缺陷的function
Intereting Posts
不同DLL的公共运行时 将在UNIX（linux / osx）中创build的符号链接仍然在Windows中工作？ nginx作为反向代理来限制http动词访问 linux内核进程调度器的FCFSalgorithm 我应该使用WPF的数据应用程序，将在Windows XP上运行？ 运行在Linux上的.Net Stracing附加到一个multithreading的过程 使用CreateProcess，不能获取CREATE_NO_WINDOW来压缩控制台 NTFS CRC窗口在什么地方和哪里抱怨？ 用于查看ELF文件格式的窗口中的任何工具/软件？ Linux文件系统自动由磁盘支持，但完全托pipe在内存中？ 在C中设置进程的内存限制（用fork和exec） 在Ubuntu上安装C ++库 手动安装Windows XP驱动程序 Apache DocumentRoot到虚拟主机的networking目录

使用WinDBG来识别有缺陷的function

我已经从7.1 Windows SDK安装了WinDBG。 然后，在VC ++ 2008中，我做了一个程序“CleanPayload.exe”，它只包含一个“main”和一个对故意包含缺陷的函数的调用。 这是一个包含debugging符号的发行版本。 我打开那个程序到WindDBG然后

  1. 做了一个.sympath+来表明PDB在那个程序里的位置。
  2. 做了一个ld *加载所有的符号
  3. 做了一个lm来validation所有的符号加载（我的程序的私有符号，Windows库的公共符号）。

然后，我运行了程序，它抛出了一个第一次偶然的例外，这是相当期待的。 如下： 

 (910.12a0): WOW64 breakpoint - code 4000001f (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. ntdll32!LdrpDoDebuggerBreak+0x2c: 771e0f2b cc int 3

但是，当我要求WinDBG向我展示堆栈时，它不会显示我的程序“CleanPayload.exe”的任何内容。 相反，它显示了这一点： 

 0:000:x86> kb ChildEBP RetAddr Args to Child 004bf5ec 771c122b 7efdd000 7efde000 7724206c ntdll32!LdrpDoDebuggerBreak+0x2c 004bf764 77192187 004bf7d8 77140000 7c185e6a ntdll32!LdrpInitializeProcess+0x132f 004bf7b4 77179e89 004bf7d8 77140000 00000000 ntdll32!_LdrpInitialize+0x78 004bf7c4 00000000 004bf7d8 77140000 00000000 ntdll32!LdrInitializeThunk+0x10

我需要做什么，它会显示一个堆栈跟踪（1）包括我的程序和（2）抛出exception的函数？

更新我遵循拉里的build议，跑过第一个exception，并得到以下结果： 

 0:000:x86> g ntdll!NtTerminateProcess+0xa: 00000000`76faf97a c3 ret 0:000> kb RetAddr : Args to Child : Call Site 00000000`74c6601a : 00000000`00000000 00000000`000de600 00000000`000ddc80 00000000`74c60304 : ntdll!NtTerminateProcess+0xa 00000000`74c5cf87 : 00000000`0030f988 00000000`0030dba8 00000000`7efdb000 00000000`0030f934 : wow64!whNtTerminateProcess+0x46 00000000`74be276d : 00000000`77150190 00000000`74c50023 00000000`00000000 00000000`0030fab8 : wow64!Wow64SystemServiceEx+0xd7 00000000`74c5d07e : 00000000`00000000 00000000`74be1920 00000000`000de820 00000000`76f93501 : wow64cpu!TurboDispatchJumpAddressEnd+0x24 00000000`74c5c549 : 00000000`00000000 00000000`00000000 00000000`74c54ac8 00000000`7ffe0030 : wow64!RunCpuSimulation+0xa 00000000`76faae27 : 00000000`004a3100 00000000`00000000 00000000`7707a1e0 00000000`7efdf000 : wow64!Wow64LdrpInitialize+0x429 00000000`76fa72f8 : 00000000`00000000 00000000`76fa8641 00000000`76fb84e0 00000000`00000000 : ntdll!LdrpInitializeProcess+0x1780 00000000`76f92ace : 00000000`000df1b0 00000000`00000000 00000000`7efdf000 00000000`00000000 : ntdll! ?? ::FNODOBFM::`string'+0x2af20 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe

因此，不幸的是，我仍然没有看到相关的堆栈跟踪信息。 在上述步骤之前，我也尝试了.effmach x86命令，但似乎没有影响。 顺便说一句，我也然后重新执行整个testing与应用程序validation激活的目标程序，我正在testing。 我得到了非常矛盾的结果： 

 0:000> g ModLoad: 00000000`76d40000 00000000`76e5f000 WOW64_IMAGE_SECTION ModLoad: 00000000`74f90000 00000000`75090000 WOW64_IMAGE_SECTION ModLoad: 00000000`76d40000 00000000`76e5f000 NOT_AN_IMAGE ModLoad: 00000000`76e60000 00000000`76f5a000 NOT_AN_IMAGE ModLoad: 00000000`71160000 00000000`711c0000 C:\Windows\syswow64\verifier.dll Page heap: pid 0x1A54: page heap enabled with flags 0x3. AVRF: CleanPayload.exe: pid 0x1A54: flags 0x80643027: application verifier enabled ModLoad: 00000000`71130000 00000000`7115b000 C:\Windows\SysWOW64\vrfcore.dll ModLoad: 00000000`710d0000 00000000`71128000 C:\Windows\SysWOW64\vfbasics.dll ModLoad: 00000000`74f90000 00000000`75090000 C:\Windows\syswow64\kernel32.dll ModLoad: 00000000`76830000 00000000`76876000 C:\Windows\syswow64\KERNELBASE.dll ModLoad: 00000000`715c0000 00000000`7164e000 C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_508ed732bcbc0e5a\MSVCP90.dll ModLoad: 00000000`73dc0000 00000000`73e63000 C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4926_none_508ed732bcbc0e5a\MSVCR90.dll (1a54.17dc): WOW64 breakpoint - code 4000001f (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. ntdll32!LdrpDoDebuggerBreak+0x2c: 771e0f2b cc int 3 0:000:x86> !avrf ************************************************************************* *** *** *** *** *** Your debugger is not using the correct symbols *** *** *** *** In order for this command to work properly, your symbol path *** *** must point to .pdb files that have full type information. *** *** *** *** Certain .pdb files (such as the public OS symbols) do not *** *** contain the required information. Contact the group that *** *** provided you with these symbols if you need this command to *** *** work. *** *** *** *** Type referenced: wow64!_TEB32 *** *** *** ************************************************************************* Application verifier is not enabled for this process. Use appverif.exe tool to enable it.

上面的执行说AVRF: Cleanpayload.exe ... application verifier enabled ，这表明它是locking到目标。 但是随后的!avrf命令显示debugging符号是不好的，即使lm命令显示它们全部正确加载！ 这里究竟发生了什么？

你正在运行64位版本的windbg和32位应用程序。 初始断点在64位代码中运行。

如果你点击“g”，你应该打开32位应用程序的初始断点，你应该可以从那里开始。

要从64位调试切换到32位调试（例如，如果您点击CTRL-C），请输入： 

 .effmach x86

这将把调试器从64位模式切换到32位模式。

一旦软件被打包并发送给QA或客户，您是否正试图弄清楚如何调试真正的问题？ 如果是的话，还有另外一个可以使用的工具，adplus。 Adplus启动调试器，只有一个目的（实际上是两个，如果你运行在挂起模式，但这不是你想要的），这是等待异常。 当发生异常时，它将生成一个可以加载到WinDbg中的进程内存转储文件。

使用这种方法，您不必依靠QA或您的客户知道如何使用WinDbg。 你只要给他们说明如何运行一个命令行。 他们运行后，他们只是压缩整个输出目录，并将其发送给您进行分析。

一旦加载到WinDbg，内存转储文件将显示当时异常和所有本地/成员变量的确切位置（尽管如果您的代码已经优化，您可能必须为这些值钓鱼一下）。