我有一个奇怪的间歇性崩溃，仅在某些情况下发生，我无法解决它，并且我正在寻求SO的建议以了解如何解决它。
该错误
显然在随机点，Windows 显示“[App] 已停止工作”对话框。它是ntdll.dll中的一个APPPCRASH，异常代码4000001f，异常偏移000a2562。这就是它变得棘手的地方：这只发生在调试器下运行应用程序时。但是，调试器不会捕获此异常，并且在 Windows 显示此对话框时，IDE 没有响应。正常运行时（即不在 IDE 调试器内）不会出现此错误。
我无法在调试器之外重现它，因此无法运行该程序并附加当它已经崩溃的时候。当 Windows 显示此对话框时，我无法暂停执行，因为 IDE 没有响应。我可以手动跟踪代码行以查看它发生的位置。有好几种，而且出现的位置显然是随机的。有一段时间它发生在显示窗口（或新表单）时，一会发生在创建线程时。
编辑：我已将其跟踪到 IDE：如果我在断点处暂停并单击“线程状态”选项卡，程序将立即崩溃并显示上述对话框，即使它从理论上讲，是暂停了。在这种情况下，IDE 仍保持响应。这实在是太奇怪了。
更多信息
我刚刚将我的开发环境移至 VMWare Fusion。在我的新计算机上运行我的旧（本机 Windows）计算机上的构建时也会出现该错误；旧计算机上的相同 EXE 文件不会发生这种情况。这让我想知道它是否与 Fusion 或我的新设置中的某些内容有关。
我正在运行：
- Windows 7 Pro x64，WMWare Fusion 3.1.3，OSX Lion 10.7.1，全部更新。 Fusion 正在我的一个屏幕上以“全屏”模式运行。
- 本地运行 Windows 7（而不是在虚拟机中）的一位同事没有遇到此问题。我的旧 Vista 电脑上也没有。
- Embarcadero RAD Studio 2010，完全更新（我希望；大约有五个更新，将它们全部按顺序排列是很棘手的。）我安装了 DDevExtensions 2.4.1，也安装了最新的 IDE 修复包：卸载这两个都没有效果。
- 该应用程序主要用 C++ 编写，并带有 Delphi 代码片段。它是 32 位的。
- 我们使用EurekaLog，但异常也没有被它捕获。 （通常情况下，异常将首先由调试器捕获，然后由 EurekaLog 捕获。）
- 运行调试构建（无 EurekaLog、额外的调试信息等、调试 DCU 设置为 true）也会重现该异常。但是，C++Builder 项目设置对话框的 Delphi 链接页面上的“调试 DCU”选项似乎没有效果 - 我无法进入 VCL 代码并找到实际触发错误的行。
- Codeguard（检测内存访问错误、双重释放、已释放内存中的访问、缓冲区溢出等）没有报告任何内容。
I have an odd intermittent crash that only occurs under some circumstances that I am having trouble solving, and I'm seeking SO's advice for how to tackle it.
The bug
At apparently random points, Windows shows the "[App] has stopped working" dialog. It is an APPCRASH in ntdll.dll, exception code 4000001f, exception offset 000a2562. Here's where it gets tricky: this only occurs when running the application under the debugger. However, the debugger does not catch this exception, and at the point where Windows shows this dialog, the IDE is not responding. This bug does not occur when running normally, i.e. not within the IDE debugger.
I can't reproduce it outside the debugger, so I can't run the program and attach when it's already crashed. I can't pause execution when Windows shows this dialog, since the IDE isn't responding. I can manually trace through lines of code to see where it occurs. There are several, and where it occurs is apparently random. For a while it occurred when showing a window (or new form), for a while when creating a thread.
Edit: I have tracked it down to the IDE: if I pause on a breakpoint and click the Thread Status tab, the program will crash immediately with the above dialog even though it is, theoretically, paused. In this situation, the IDE remains responsive. This is really weird.
More information
I have just moved my development environment to VMWare Fusion. The bug also occurs running a build from my old (native Windows) computer on my new computer; it did not occur with the same EXE file on that old computer. This makes me wonder if it is related to Fusion or something in my new setup.
I am running:
- Windows 7 Pro x64 on WMWare Fusion 3.1.3 on OSX Lion 10.7.1, all fully updated. Fusion is running in "Full screen" mode on one of my screens.
- A colleague running Windows 7 natively (not in a VM) does not encounter this issue. Nor did I on my old Vista computer.
- Embarcadero RAD Studio 2010, fully updated (I hope; there are about five updates and getting them all in order is tricky.) I have DDevExtensions 2.4.1 installed, and the latest IDE Fix Pack too: uninstalling both these has no effect.
- The application is written mostly in C++, with snippets of Delphi. It is 32-bit.
- We use EurekaLog, but the exception is not caught by it either. (Normally, an exception would be caught first by the debugger, then by EurekaLog.)
- Running a debug build (no EurekaLog, extra debug info etc, debug DCUs set to true) also reproduces it. However, the "Debug DCUs" option on The Delphi Linking page of the C++Builder project settings dialog seems to have no effect - I can't step into the VCL code and find the line that actually triggers the error.
- Codeguard (which detects memory access errors, double frees, access in freed memory, buffer overruns, etc) reports nothing.
发布评论
评论（4）
这具有内存损坏的所有特征。它仅在您在一个特定环境下运行时出现，并且每次出现在不同的位置。都是典型症状。
我知道调试此问题的最佳方法是下载完整的 FastMM 并在启用完整调试选项的情况下运行。
如果这没有帮助，那么您只能逐一删除部分代码，直到可以隔离问题。
我在 D2010 中看到的另一个问题是将本地类定义（即类中的类）与泛型混合时出现的问题。生成的代码很好，但调试 DCU 是错误的，当单步执行代码时，调试器会跳转到错误的文件，并很快就会终止。您似乎没有遇到完全相同的问题，但 IDE 死亡有相似之处。
最后，我建议您怀疑您自己的代码，而不是 VMware。人们总是很容易责怪其他东西，但根据我的经验，每当我这样做时，最终总是我的代码！
This has all the hallmarks of a memory corruption. It only appears when you run under a one particular environment, and occurs at a different location each time. Both classic symptoms.
The best way I know to debug this is to download the full FastMM and run with full debugging options enabled.
If that doesn't help then you are reduced to removing parts of code, one by one, until you can isolate the problem.
Another problem I have seen in D2010 is a problem when mixing local class definitions (i.e. class inside class) with generics. The code generated is fine but the debug DCUs are wrong and when stepping through the code the debugger jumps to the wrong file and dies shortly after. You don't seem to have quite the same problem but there are similarities in the IDE deaths.
Finally I would advise you to suspect your own code rather than VMware. It's always tempting to blame something else but in my experience, whenever I have done so, it was always my code in the end!
我遇到了一个非常相似的问题。我还一直在开发一个 .dll，当我在代码中的任何位置设置断点时，Delphi 在源代码行处停止，主机应用程序立即崩溃。
关闭调试布局中的“线程状态窗口”“修复”了该问题。
我正在使用 Windows 7 64 位和 Delphi XE3。
I hit a quite similar problem. I've also been developing a .dll and when I've set a breakpoint anywhere in my code, Delphi stopped at the source code line and the host-application crashed immediately.
Closing the "Thread Status Window" in debug layout "fixed" the problem.
I'm working on Windows 7 64-bit and Delphi XE3.
4000001F是STATUS_WX86_BREAKPOINT，
换句话说，它是INT 3，没有被IDE处理。
由于它是在 NTDLL 中引发的 - 我猜测这表明系统堆中的内存损坏。请记住，某些 Windows 代码会切换到调试器版本 在调试器下运行时。这就是为什么当应用程序在调试器之外独立运行时无法重现此情况 - 因为未生成断点。
您可以在完全调试模式下尝试 FastMM，但我认为这对您没有帮助。损坏不会发生在您的内存中，而是发生在系统内存中。是的，也许内存分配方案会改变 - 并且你的腐败会在你的代码/内存中暴露出来......可能是。尝试使用自上而下的分配，尝试使用 SafeMM...
另一种可能的方法是使用 应用程序验证程序。
另请参阅：
4000001F is STATUS_WX86_BREAKPOINT
In other words, it is INT 3, which was not handled by IDE.
Since it is raised in NTDLL - I would guess that this is indication of memory corruption in system heap. Remember, some Windows code would switch to debugger version when running under debugger. That's why you can not reproduce this when application is running as standalone outside of the debugger - because breakpoint is not generated.
You may try FastMM in full debug mode, but I do not think that it will help you. The corruption does not happen in your memory, it happens in system memory. Yes, perhaps memory allocation scheme will be changed - and your corruption will reveal itself in your code/memory... may be. Try use top-down allocations, try use SafeMM...
Another possible approach would be using Application Verifier.
See also:
检查项目 dsk 文件并确保它没有指向错误单元的引用。修复方法是在编辑器中打开 dsk 并将文件位置更改为正确的位置。
Check the The projects dsk file and make sure it does not have a reference pointing to the wrong unit. The fix is to open the dsk in an editor and change the file location to the correct location.