我有一个我不熟悉的庞大代码库,程序异常终止,因为某个地方的某个线程正在调用__fastfail
。这基于消息,以
...请求致命程序退出。
调用堆栈没有符号,因为它在C ++ 2015运行时(ucrtbase.dll
)内。该调用似乎是在我的主线程以外的线程上进行的。这个神秘的线程只在问题出现之前就开始了,所以我无法从调试器中开始抓住它的行为 - 我不知道是什么启动它,以及导致整个过程的原因是什么第一名。
我使用main()
在__try/__catch
中使用SEH,因此任何未处理的异常都应该被困在那里。相反,我猜测某些地方冒泡到运行时并产生__fastfail
。
我尝试将所有线程与SEH一起使用,就像main()
一样,尝试挂钩abort()
,exit()
和terminate()
,但无法找到问题。我如何调试这个,任何提示?
答案 0 :(得分:3)
我想说这对WinDbg来说是个不错的任务。 WinDbg是Debugging Tools for Windows的一部分,它是免费的。安装两个版本,x64和x86,以便您可以调试任何类型的应用程序。
File/Open executable
)下运行您的可执行文件。它会在最初的断点处停止。.symfix c:\debug\symbols
和.reload
。正如@ James McNellis所提到的,符号可用,这将在需要时下载。g
.dump /ma c:\debug\mydump.dmp
创建故障转储,以便稍后进行分析.exr -1
~#s
k
学习WinDbg是一项艰巨的任务,因为大多数事情都是通过神秘的命令完成的,而不是通过UI完成的,但它几乎可以做任何事情。
如果您有更多线索可以解决更具体的问题,请使用windbg标记提出其他问题。
Visual Studio也可以从Microsoft Servers下载符号(PDB文件; callstack信息)。
答案 1 :(得分:0)
Hans和James是对的,获得一个可读的调用堆栈对于解决这种情况至关重要。
代码库安装了一个执行快速失败的纯调用处理程序。纯粹的处理程序通过SEH。程序中40个线程之一有一个纯调用错误,因为其他一些线程部分清理了程序状态,然后问题线程试图访问。一旦我有符号Visual Studio在调用purecall处理程序的地方进入C ++运行时库,我就将其追溯到他们自己安装的程序中。
他们做快速失败的方式是复杂的并且解决了一些RtlXXX功能,显然不能被信号(SIGABRT)困住,因为我之前尝试过。
再次感谢大家的帮助!