帮助混合模式 Win32 应用程序的事后调试
情况如下：
背景
我有一个在 Visual Studio 2008 中开发的混合模式 .NET/Native 应用程序。
我所说的混合模式是指前端是用 C++ .NET 编写的，它调用本机C++ 库。 本机代码完成应用程序中的大部分工作，包括根据需要启动新线程。 .NET 代码仅用于 UI 目的（win 表单）。
我有一个在测试人员的计算机上运行的应用程序的发布版本。
本机库是在完全优化的情况下编译的，而且还启用了调试（“调试信息格式”设置为“程序数据库”）。
这意味着我在 PDB 文件中拥有应用程序的调试符号。
问题
所以无论如何，其中一位测试人员遇到了应用程序的问题，它在 XP 上偶尔会崩溃。 我已经能够使用 Dr Watson 多次运行来获取崩溃的小型转储。
当我调试它时（使用小型转储 - 我实际上并没有调试真正的应用程序），所有调试符号都被正确加载：我可以正确地看到所有本机线程的完整堆栈跟踪。 其他线程（大概是 .NET 线程）没有堆栈跟踪，但它们至少都显示了线程是在哪个 dll 上启动的（即 ntdll.dll）。
它正确地报告失败的线程（“user(5).dmp 中 0x0563d652 处未处理的异常：0xC0000005：访问冲突读取位置 0x00000000）。
但是，当我进入该线程时，它没有显示任何有用的内容。在堆栈跟踪中，有一个条目只有内存地址“0563d652()”（甚至不是“ntldll.dll”）。
当我进入 disasembly 时，它只显示大约 30 条指令的随机部分。 “。它几乎看起来不是我的源代码的一部分（你的二进制文件不是按顺序加载到内存中的吗？在不知名的地方有一组随机的汇编语句是正常的吗？）。
我的问题< /strong>
所以基本上我的问题有三重。
1）任何人都可以解释调试器缺乏信息吗？
2）请记住，我无法显示我的代码中发生的错误，任何人都可以提出失败的原因
吗？我将来会做些什么来帮助我诊断当前的问题
这是来自WinDBG
John
更新：
的失败线程的堆栈转储
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 099bf414 02d0e7fc 0x563d652
01 00000000 00000000 0x2d0e7fc
奇怪吧？ 甚至不显示 DLL。
我是否有可能以某种方式损坏了堆栈/堆，导致线程损坏......？
Here's the situation:
Background
I have a mixed mode .NET/Native application developed in Visual Studio 2008.
What I mean by mixed mode is that the front end is written in C++ .NET which calls into a native C++ library. The native code does the bulk of the work in the app, including kicking off new threads as it requires. The .NET code is just for UI purposes (win forms).
I have a release build of application running on a tester's computer.
The native libraries were compiled with full optimisations but also with debugging enabled (the "Debug Information Format" was set to "Program Database").
What this means is that I have the debugging symbols for the application in a PDB file.
The problem
So anyway, one of the testers is having a problem with the app where it occasionally crashes on XP. I've been able to get the minidump of the crash using Dr Watson for several runs.
When I debug into it (using the minidump - I'm not actually debugging the real app), all the debugging symbols are loaded correctly: I can see the full stack trace of all of the native threads correctly. Other threads (which are presumably the .NET threads) don't have a stack trace, but they all at least show me which dll the thread was started on (i.e. ntdll.dll).
It correctly reports the thread which fails ("Unhandled exception at 0x0563d652 in user(5).dmp: 0xC0000005: Access violation reading location 0x00000000).
However when I go into the thread it shows nothing useful. In the stack trace there is a single entry which just has the memory address "0563d652()" (not even "ntldll.dll").
When I go into dissasembly it just shows a random section of about 30 instructions. Either side of the memory address is just "???". It almost looks like it is not part of my source code (isn't your binary loaded sequentially into memory? is it normal to have a random set of assembly statements in the middle of nowhere?).
My questions
So basically my questions are threfold.
1) Can anyone explain the debugger's lack of information?
2) Bearing in mind, I can't show the error occurred in my code, can anyone suggest a reason for the failure
3) Can I do anything else to help me diagnose this current problem in the future?
Help!
John
Update:
Here is the stack dump for the failing thread from WinDBG
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 099bf414 02d0e7fc 0x563d652
01 00000000 00000000 0x2d0e7fc
Weird huh? Doesn't even show a DLL.
Is it possible that I've corrupted the stack/heap somehow which has caused a thread to just get corrupted...?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你在使用WinDbg吗？ 如果是这样，您是否正在使用“罢工之子”扩展程序？
Bugslayer：Son-of-Strike
- 或 -
深入了解 .NET Framework 内部结构以了解 CLR 如何创建运行时对象？
Are you using WinDbg? If so, are you using the Son of strike extension?
Bugslayer: Son-of-Strike
-or-
Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects?
我们遇到了与此类似的问题，其中代码错误在 MSVC2K5 SP1 中没有出现，但如果您安装了 MSVC2K5 SP2 运行时，则会导致错误，该错误未指向有效代码。
部分问题是，当您开始将数据作为代码执行时，您可以执行任何操作，因此崩溃位置变得毫无用处，因为您甚至无法返回到有效的堆栈跟踪。
当新的 .Net 运行时安装在 SxS 目录中安装了较新版本的 MSVC C++ 运行时时，我们就遇到了这种情况。
最后，我们解决该问题的方法是让崩溃频繁发生，并添加尽可能多的日志记录以将其本地化。
We had an issue similar to this where a code bug was silent in MSVC2K5 SP1, but if you had the MSVC2K5 SP2 runtime installed it caused an error which didn't point at valid code.
Part of the problem is, when you start executing data as code you could be doing anything and so the crash location becomes useless as you cannot even get back to a valid stack trace.
We had this happen to us when the new .Net runtime install installed a newer version of the MSVC C++ Runtime in the SxS directory.
In the end our method to resolve the issue was to make the crash happen frequently and add as much logging as necessary to localize it.
一旦您获取并安装了 Windbg 的副本并打开了转储文件，您可以发布错误线程的堆栈吗？
我们可以从那里开始。
could you post the stack of the faulting thread once you've grabbed and installed a copy of windbg and opened the dump file there?
we could start from there.
您的 EIP 刚刚损坏。
假设 ESP 有效，您可以查看调用堆栈，只需键入：
dds esp [输入]
dds [enter]
您还可以使用内存窗口：
将地址设置为：esp
设置格式为：指针&符号
Your EIP was just corrupted.
Assuming the ESP is valid, you can view the callstack, just type:
dds esp [enter]
dds [enter]
You can also use the memory windows:
Set address to: esp
Set format to: Pointer&Symbol