【发布时间】：2020-10-31 21:52:56
【问题描述】：
我用 Visual C++ 编写了一个程序，它使 Windows 崩溃。幸运的是，我有一个崩溃转储！
!analyze -v 指出错误进程确实是我的程序，并向我显示了内核模式调用堆栈。但是，我需要了解我的用户模式程序的状态才能理解它。
根据这里的一些其他答案（例如this one），它应该可以工作。
但我无法从 windbg 中获取任何此类信息。所有调用堆栈都以nt!KiSystemServiceCopyEnd+0x28 结束。作为一个最小的例子，我的一个空闲工作线程的调用堆栈来自标准 Win32 线程池：
nt!KiSwapContext+0x76
nt!KiSwapThread+0xbfd
nt!KiCommitThreadWait+0x144
nt!KeRemoveQueueEx+0x27e
nt!IoRemoveIoCompletion+0x99
nt!NtWaitForWorkViaWorkerFactory+0x25e
nt!KiSystemServiceCopyEnd+0x28 (TrapFrame @ ffff820d`2a2dfb00)
0x00007ff8`08a1fa54
我至少会期待RtlUserThreadStart 在某个地方，但什么都看不到。
有问题的程序是在 Visual C++ 2019 for x64 中编译的，带有调试信息。程序和 PDB 文件仍然存在，自崩溃以来未受影响。崩溃时附加了 Visual Studio 调试器，但我有另一个没有调试器的调试器，也好不到哪里去。
有趣的是，如果我选择了在崩溃期间运行的其他进程，并且碰巧遇到了一个未分页的进程（例如 firefox），它们的调用堆栈也会以 nt!KiSystemServiceCopyEnd+0x28 结束。
如何在崩溃期间检索程序的状态？
【问题讨论】：
-
是不同的转储类型 - 完整内存、仅内核内存、迷你转储。你不要说 - 什么转储类型（windbg 在开始时写这个）。可能你有内核内存转储或迷你转储。在这种情况下，用户模式内存根本不包括转储，也不可能显示任何用户模式堆栈
-
确实：
Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.输出是压倒性的，我想......你想发布这个作为答案吗？ -
在这种情况下 - 转储中没有用户空间内存并且不可能显示用户模式堆栈。但什么是蓝屏死机？您的用户模式代码是否导致蓝屏死机？！或崩溃在内核中？发生了什么？或者这是关键进程终止崩溃？
-
这绝对是我的用户模式调用。没有蓝屏，但系统挂起几秒钟并转储内核。之后它确实会正常继续，所以我认为它遇到了一个非关键的断言或其他东西。我想了解程序状态，以便可靠地重现它。
-
@ThomasWeller 可能，但是 a) 机器没有任何其他转储的迹象； b) 通过至少 4 次图形驱动程序更新问题仍然存在； c) 我在一台非常不同的机器上观察到类似的行为，我将在本周末重新访问。
标签： c++ debugging winapi windbg