标签: postmortem-debugging

我使用的是WinDBG 6.12.0002.633 X86.

我遇到命令行调试器CDB的问题,并没有显示k与kL命令的WinDBG相同的结果.

在WinDBG中,该k命令正确显示了callstack的代码行,其中kL命令正确地删除了该信息并仅显示了偏移量.

1:128:armce> k
Child-SP RetAddr  Call Site
761efaf4 78013cdc module_78010000!SomeModule::Foo+0xb4 [bar.cpp @ 268]

1:128:armce> kL
Child-SP RetAddr  Call Site
761efaf4 78013cdc module_78010000!SomeModule::Foo+0xb4

在CDB,的结果k及kL是相同的:

1:128:armce> k
Child-SP RetAddr  Call Site
761efaf4 78013cdc module_78010000!SomeModule::Foo+0xb4

1:128:armce> kL
Child-SP RetAddr  Call Site
761efaf4 78013cdc module_78010000!SomeModule::Foo+0xb4

我能做些什么来让CDB k像WinDBG那样显示命令的代码行？

我需要一些调试Delphi XE2应用程序崩溃的建议.我自己从来没有见过崩溃 - 事实上它很少发生,并且不能按要求重现.

我们确实从MadExcept获得了一组10个崩溃报告.这些表明主线程在主窗体的列表视图中处理WM_PAINT消息.每种情况下的调用堆栈都没有显示对我自己的代码的引用,只显示了comctl32.dll,ntdll.dll和USER32.dll中的VCL代码和函数.

有问题的列表视图是TColorListView,它派生自TCustomListView,并处理OnCustomDrawItem和OnDeletion事件.但正如我所说,当崩溃发生时,我的TColorListView代码都没有在调用堆栈上.

每种情况下崩溃的实际位置都有所不同,但是通向它的调用顺序(从早到晚)始终是:

KiUserCallbackDispatcher
RtlAnsiStringToUnicodeString
StdWndProc
TWinControl.MainWndProc
TCustomListView.WndProc
TWinControl.WndProc
TControl.WndProc
TCustomListView.WMPaint
TWinControl.WMPaint
TWinControl.WMPaint
TWinControl.DefaultHandler
CallWindowProcA
TControl.WndProc

之后它进入StdWndProc/SendMessageW/TControl.Perform之一,每次路径都不同.最终它最终出现在comctl32.dll,USER32.dll,GDI32.dll或者只是TControl.WndProc中,并引发了EAccessViolation.遗憾的是,我没有关于用户当时尝试做什么的信息,因为用户没有填写错误报告的那一部分.

您能否建议我使用任何"通灵调试"技术来确定崩溃的原因(从而修复它)？

更新以回答以下评论中的问题:

procedure TColorListView.HandleCustomDrawItem(aSender: TCustomListView; aItem: TListItem;
                                              aState: TCustomDrawState; var aDefaultDraw: Boolean);
begin
  Canvas.Font.Color := ItemColors[aItem.Index];
end;

在(仅)其中一个崩溃报告中,它似乎进入TListItem.GetIndex并进一步崩溃了几个堆栈帧.这可能是一个红鲱鱼.

什么是'Perform'ed消息？对不起,我不知道.MadExcept没有给我方法参数值; 只是方法名称.

5月31日

虽然我更愿意根据我的信息找到错误,但我也欢迎我可以添加到程序中的任何新诊断的建议,以便如果在下一个版本之后再次发生这种崩溃,我将会继续.我很茫然,因为在崩溃时我甚至没有修改的代码甚至在调用堆栈上.

6月13日

我在MadExcept报告中添加了一行,告诉我发生异常时应用程序处于什么状态 - Starting/Active/Idle/ModalDlg/Terminated.(感谢Chris Thornton提出的建议.)我认为在关机期间发生异常的可能性是合理的.不幸的是,直到2014年我们才发布新版本并且有可能通过新诊断获取错误报告.

是否可以在崩溃时创建Windows服务的完整内存转储？显然,有一些众所周知的事后调试器,可以收集失败进程的内存转储.但Windows服务的问题在于它们是在系统上下文中运行而不是在用户上下文中运行.有谁能够帮我？

到现在为止,我尝试使用WinDbg:

• 我通过执行WinDbg -I将WinDbg设置为默认的事后调试器.
• 我验证了在注册表的两个位置(HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\AeDebug和HKLM\SOFTWARE\Wow6432Node\Microsoft\WindowsNT\CurrentVersion\AeDebug),存在两个条目Auto和Debugger.
• 我通过将调试器条目更改为"Path\WinDbg.exe"-p%ld -c".dump/ma/u D:\ CrashDump.dmp"-e%ld -g,将WinDbg配置为在启动时自动写入内存转储
• 我验证了WinDbg具有内存转储文件的目标位置的权限,具有和不具有管理权限.

但它不起作用.:(

如果我编写一个普通的用户模式应用程序,它在启动后故意崩溃,WinDbg弹出并自动将.dmp文件写入目标位置.但如果我的服务崩溃,它就不会崩溃.在任务管理器中,我可以看到WinDbg在我的服务崩溃过程之后启动,但两者都只保留在列表中而没有任何转储文件.

我正在做一些故障转储调试,我正在寻找从生产服务器获取的转储.我正在运行WinDbg的机器必须安装一个稍微不同的.NET运行时版本 - 我在加载.NET系统程序集的本机映像时出错(因此无法加载System.Data.Linq).

确保我的调试机器能够访问所有正确符号的最佳方法是什么？

编辑 为Thomas Weller添加的lmv输出

000007fb`68660000 000007fb`68993000   System_Data_Linq_ni C (pdb symbols)          C:\Program Files\Debugging Tools for Windows (x64)\sym\System.Data.Linq.pdb\703A918D116A4558BB44245924371ACD1\System.Data.Linq.pdb
    Loaded symbol image file: System.Data.Linq.ni.dll
    Image path: C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Data.Linq\acbd568cd3c2499fbb7b2639c4a46a81\System.Data.Linq.ni.dll
    Image name: System.Data.Linq.ni.dll
    Has CLR image header, track-debug-data flag not set
    Timestamp:        Fri Apr 11 20:41:26 2014 (534899C6)
    CheckSum:         00000000
    ImageSize:        00333000
    File version:     4.0.30319.34209
    Product version:  4.0.30319.34209
    File flags:       0 (Mask 3F)
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

无论如何，有没有办法从 gdb 中的 corefile 中发现 PyObject* 的 python 值

单步执行发布代码有什么意义吗？我注意到省略了一些代码行，即一些方法调用。此外，变量预览不显示某些变量，并显示其他一些变量的无效（非真实）值，因此这完全具有误导性。

我问这个问题是因为将 WinDbg 故障转储文件加载到 Visual Studio 中会带来与步骤执行相同的堆栈和变量部分视图。除了在没有优化的情况下重新编译应用程序之外，还有什么方法可以改善故障转储分析体验？

Windows、Visual Studio 2005、非托管 C++

假设,在调试会话中,我有一个地址,不幸的是它指向一些垃圾.我想检查周围的记忆,看看附近有什么.正如所料,发生以下错误:

(gdb) x/64 $t5
0x842da7ac:     Cannot access memory at address 0x842da7ac

所以,问题是:有没有办法读取一系列地址,其中一些无效？

(更准确地说,我怎么知道上面的例子$t5+n中某些人的有效地址0 < n <= 64？)

我试图在 Linux 系统上对崩溃的二进制文件“TestApp”进行事后分析。

我有一个二进制文件和共享对象的副本，它们被复制到路径中的设备上：

/usr/public/target

此文件夹包含在被测系统上使用的目录结构中的所有相关二进制文件，即：

/usr/public/target/sbin/TestApp
/usr/public/target/lib/TestAppLib.so
/usr/public/target/usr/lib/TestAppAPILib.so

自动构建过程从二进制文件中剥离调试信息，并将它们存储在外部符号文件中，全部位于：

/usr/public/target_external_symbols

因此，上述二进制文件的符号信息将存在于以下文件中：

/usr/public/target_external_symbols/sbin/TestApp.sym
/usr/public/target_external_symbols/lib/TestAppLib.so.sym
/usr/public/target_external_symbols/usr/lib/TestAppAPILib.so.sym

我如何让 GDB 知道这些外部符号的存在并加载它们？

我通常通过以下方式调用 GDB：

gdb TestApp TestApp.core

我参考了其他关于创建测试.gdbinit文件并通过-command参数将其传递给 GDB 的文章，但它似乎不起作用。每次我尝试从我的核心文件中获取回溯时，我都会收到来自 GDB 的指示，表明它无法打开调试符号。对解决此问题的任何帮助表示赞赏。

(gdb) info shared
From        To          Syms Read   Shared Object Library
0x78000000  0x780061e8  Yes (*)     /usr/public/target/lib/TestAppLib.so
0x78010000  0x7806e60c  Yes (*)     /usr/public/target/usr/lib/TestAppAPILib.so
0x78070000  0x78091d2c  Yes (*)     /usr/public/target/lib/libm.so.2
(*): Shared library is missing debugging information.

谢谢你。