如何调试“此应用程序已请求运行时以不寻常的方式终止它。”当我什至无法输入代码时?

发布于 2024-11-17 19:13:17 字数 1001 浏览 5 评论 0原文

我有一个 C++ 程序,进程一启动就会出现此错误 - 显然是在任何用户代码执行之前。仅当启用内联时才会发生这种情况。即使内置了调试符号,我也无法单步执行代码。当我在 Visual Studio 中按 F10 时,我收到错误并且程序停止。我检查了“调试/异常”中的所有异常/检查,但仍然没有休息。

通常,我预计类似的情况是由于缺少运行时依赖项造成的,但我非常肯定这里的情况并非如此(使用 Dependency Walker 进行了验证)。

编辑:我使用了 Steve Townsend 推荐的 CDB,现在我可以单步执行程序的预用户代码部分。最终的堆栈跟踪是:

Child-SP          RetAddr           Call Site
00000000`0008e308 00000000`7541601a ntdll!ZwTerminateProcess+0xa
00000000`0008e310 00000000`7540cf87 wow64!Wow64EmulateAtlThunk+0x86ba
00000000`0008e340 00000000`7539276d wow64!Wow64SystemServiceEx+0xd7
00000000`0008ec00 00000000`7540d07e wow64cpu!TurboDispatchJumpAddressEnd+0x24
00000000`0008ecc0 00000000`7540c549 wow64!Wow64SystemServiceEx+0x1ce
00000000`0008ed10 00000000`7776ae27 wow64!Wow64LdrpInitialize+0x429
00000000`0008f260 00000000`777672f8 ntdll!LdrGetKnownDllSectionHandle+0x1a7
00000000`0008f760 00000000`77752ace ntdll!RtlInitCodePageTable+0xe8
00000000`0008f7d0 00000000`00000000 ntdll!LdrInitializeThunk+0xe

I have a C++ program that is giving this error as soon as the process starts - apparently before any user code executes. It only happens when inlining is enabled. Even with debug symbols built in, I can't step in the code. As soon as I press F10 in Visual Studio I get the error and the program stops. I checked all exceptions/checks in "Debug/Exceptions" but still don't get a break.

Normally I would expect something like this to be due to a missing runtime dependency but I'm quite positive that's not the case here (verified with Dependency Walker).

edit: I used Steve Townsend's recommendation of CDB and now I'm able to step through the pre-user-code parts of the program. The final stack trace is:

Child-SP          RetAddr           Call Site
00000000`0008e308 00000000`7541601a ntdll!ZwTerminateProcess+0xa
00000000`0008e310 00000000`7540cf87 wow64!Wow64EmulateAtlThunk+0x86ba
00000000`0008e340 00000000`7539276d wow64!Wow64SystemServiceEx+0xd7
00000000`0008ec00 00000000`7540d07e wow64cpu!TurboDispatchJumpAddressEnd+0x24
00000000`0008ecc0 00000000`7540c549 wow64!Wow64SystemServiceEx+0x1ce
00000000`0008ed10 00000000`7776ae27 wow64!Wow64LdrpInitialize+0x429
00000000`0008f260 00000000`777672f8 ntdll!LdrGetKnownDllSectionHandle+0x1a7
00000000`0008f760 00000000`77752ace ntdll!RtlInitCodePageTable+0xe8
00000000`0008f7d0 00000000`00000000 ntdll!LdrInitializeThunk+0xe

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

伤痕我心 2024-11-24 19:13:17

您可以尝试设置 Process Dumper 并配置它可以让您的 EXE 在任何进程退出时创建转储。然后从命令行启动该过程以排除 IDE 的任何工件。

这应该为您提供用于事后调试的转储,并且可能是来自现有线程的可能有用的调用堆栈。

You could try setting up Process Dumper and configure it for your EXE to create a dump on any process exit. Then start the process from the command line to rule out any artifacts of the IDE.

This ought to give you a dump for post-mortem debugging, and maybe a callstack fromm the exiting thread that could be useful.

荒路情人 2024-11-24 19:13:17

这可能与全局变量的初始化顺序有关。在 C++ 中,模块之间的顺序是未指定的。因此,如果全局的初始化程序依赖于已初始化的另一个模块中的全局,那么您就会遇到麻烦。

可以在调用 main(或 wmain、WinMain 或您正在使用的任何内容)之前运行的 CRT 初始化代码中放置一个断点。您可以单步执行该代码并查看导致问题的原因。

另一个可能的原因是 DllMain 函数在 DLL_PROCESS_ATTACH 期间返回错误或引发异常。

It probably has to do with the order that your globals are being initialized. In C++, the order between modules is unspecified. So if a global's initializer depends on a global in another module already being initialized, you're in trouble.

It's possible to put a break point in the CRT initialization code that runs before calling main (or wmain, or WinMain, or whatever you're using). You can step through that code and see what's causing the problem.

Another possible cause is a DllMain function is returning an error or throwing an exception during DLL_PROCESS_ATTACH.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文