Reputation: 380
I wrote a program with Visual C++ and it crashes Windows. Luckily, I have a crash dump!
!analyze -v
states that the faulty process is indeed my program and shows me a kernel-mode call stack. However, I need to understand the state of my user-mode program to make sense of it.
According to some other answers here (e.g. this one), it should just work.
But I cannot get any such information out of windbg. All call stacks simply end at nt!KiSystemServiceCopyEnd+0x28
. As a minimal example, the call stack for an idle worker thread of mine from the standard Win32 thread pool:
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
I would at least expect RtlUserThreadStart
somewhere, but nothing in sight.
The program in question was compiled in Visual C++ 2019 for x64 with debug information. The program and the PDB files are still in place, untouched since the crash. The Visual Studio debugger was attached at the time of the crash, but I have another one without a debugger and it’s no better.
Interestingly, if I select other processes which ran during the crash and if I happen to hit one which wasn’t paged out (e.g. firefox), their callstacks end at nt!KiSystemServiceCopyEnd+0x28
as well.
What can I do to retrieve the state of my program during the crash?
Upvotes: 3
Views: 1868
Reputation: 380
RbMm was right – the dump doesn’t include any user address space, so there’s nothing for windbg to show.
When opening a dump file with windbg, watch the first few lines of output. There should be a message like Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available
, which says it all.
Upvotes: 3