答案1
我发现 0xC000041d = STATUS_FATAL_USER_CALLBACK_EXCEPTION
发生的情况似乎是由于应用程序创建的早期线程导致应用程序以异常代码 0xc000041d 退出。
点击阅读更多并查看来源。。
答案2
0xC000041d
是状态微软定义的代码常量ntstatus.h头文件:
定义名称(MessageId
)为STATUS_FATAL_USER_CALLBACK_EXCEPTION
,其描述为:
"An unhandled exception was encountered during a user callback."
状态代码通常用于传递系统信息,例如在 Windows 系统和设备驱动程序之间,有时在 Windows 和应用程序之间:
- https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/c8b512d5-70b1-4028-95f1-ec92d35cb51S
- https://www.osr.com/blog/2020/04/23/ntstatus-to-win32-error-code-mappings/
的含义状态也可以使用 Microsoft 错误查找工具来查找代码:
正如描述所示,Windows 使用这个特定的状态当在调用用户模式(https://www.tutorialspoint.com/User-Mode-vs-Kernel-Mode)回调函数(https://en.wikipedia.org/wiki/Callback_(computer_programming))。
有很多情况都可能产生此消息。因此,仅在状态代码0xC000041d
可能会产生不相关的结果。如果同时包含进程的确切文件名(在本例中为 iexplore.exe)、错误模块(见下文)和/或甚至确切的内存地址(在本例中0x7149B7C0
),则可能会出现更相关的结果。
搜索完整的内存地址可能有点棘手,因为程序的编译/构建版本略有不同,执行模型也不同(例如,Windows 的 32 位版本与 64 位版本),并且模块(.dll、.exe、.sys 文件等,它们共同构成执行程序代码)加载到不同的基址。仅匹配B7C0
地址的最后四个字符可能足以表明存在相关问题。
为了实际调试该问题,可以使用 Visual Studio 查看导致异常的线程的调用堆栈:
https://stackoverflow.com/questions/945193/how-do-i-find-the-stack-trace-in-visual-studio
调用堆栈显示了异常发生时相互调用的不同模块和这些模块中的方法。模块名称可以表明问题发生时程序正在做什么。
如果符号(https://devblogs.microsoft.com/devops/understanding-symbol-files-and-visual-studios-symbol-settings/) 可用于导致问题的模块 - 甚至可能是这些模块的源代码文件 - 调试变得更加容易。