程序已退出，代码为 -2147483645 [英] Program has exited with code -2147483645

问题描述

我在使用 Visual Studio 调试混合的 WPF/CLR/非托管本机 C++ 项目时遇到了一个有趣(相当烦人)的错误，此错误仅在 Windows XP 中发生.看来我在程序中发生了内存损坏，其范围太大而无法在此处发布.我遇到的问题是，当程序发生崩溃时，它只是在没有 VS 调试器尝试定位异常的情况下退出，我假设是因为没有抛出任何异常.程序退出代码确实是我必须继续下去的唯一信息，它只是最小的 int 值.

Ive run into an interesting (rather annoying) error while using Visual Studio to debug a mixed WPF/CLR/Unmanaged native c++ project, this error occurs only in Windows XP. It would seem that I have a memory corruption occuring within the program, the scope of which is much too large to post here. The problem that I am having is that when the crash occurs in the program, it simply exits without the VS debugger attempting to locate an exception, I assume because none is thrown. The program exit code is really the only information I have to go on, and its just the minimum int value.

有没有人遇到过这种情况，也许能够为我指明正确的方向?

Has anyone encountered this and might be able to point me in the right direction as far as what it means?

继续调查这个问题，我发现有时我可以得到堆栈跟踪和异常，而不是直接退出程序.跟踪使我进入向量分配(推送).在程序刚刚退出的场景下，这仍然是最后一行执行.我假设我在某处有损坏的内存，尽管我希望这通常表现为程序转储而不是异常的事实能够帮助我指明正确的方向.

Continuing to investigate the problem, Ive discovered that I can sometimes get a stack trace and an exception as opposed to a straight program exit. The trace brings me to a vector allocation (push). In the scenario where the program just exits, this is still the last line executed. I assume that I have corrupt memory somewhere, though I was hoping that the fact that this usually manifests itself as a program dump and not an exception would be able to help point me in the right direction.

推荐答案

//
// MessageId: STATUS_BREAKPOINT
//
// MessageText:
//
// {EXCEPTION}
// Breakpoint
// A breakpoint has been reached.
//
#define STATUS_BREAKPOINT                ((NTSTATUS)0x80000003L)

程序登陆INT3指令并触发断点.但是没有调试器存在，因此终止了程序.它可能是您留在代码中的一个杂散的 __debugbreak()，也可能是程序状态损坏时的疯狂跳转触发的.

The program landed on an INT3 instruction and triggered a breakpoint. But no debugger present so that terminates the program. It could be a stray __debugbreak() you left in your code, it could be triggered by a wild jump when the program state got corrupted.

你需要调试它.如果您无法在开发机器上轻松重现它，那么您需要从故障机器上进行小型转储.

You'll need to debug it. If you can't easily repro it on your dev machine then you'll need a minidump from the failing machine.

这篇关于程序已退出，代码为 -2147483645的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！