Unable to get full user-mode stacktrace while kernel debugging in windbg
<p>I have a virtual Windows 7 x64 machine on a Windows 10 host, and I kernel debug it with windbg <code>10.0.10586.567</code>. I'm running my own application on it, which I have full source and private symbols for. Whenever I break in and ask for stack traces of the app's threads, the backtrace always stops when one of my application's binaries are "hit."</p>

<p>So for instance, if I break in, switch to the process, and request a stacktrace with <code>!thread [thread address] 1f</code>, I get something like this (note the "early" zero return address at the last line):</p>

<pre><code>fffff880`0534e870 fffff800`026d6992 nt!KiSwapContext+0x7a
fffff880`0534e9b0 fffff800`026d81a2 nt!KiCommitThreadWait+0x1d2
fffff880`0534ea40 fffff800`029c7a2e nt!KeDelayExecutionThread+0x186
fffff880`0534eab0 fffff800`026d08d3 nt!NtDelayExecution+0x59
fffff880`0534eae0 00000000`76e7165a nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`0534eae0)
00000000`00276708 000007fe`fcf91203 ntdll!NtDelayExecution+0xa
00000000`00276710 00000001`410e7dd9 KERNELBASE!SleepEx+0xab
00000000`002767b0 00000000`00000000 MyApp!MainMessageLoop+0x4b1 [d:\whatever\path\myapplication.cpp @ 3024]
</code></pre>

<p>This looks very similar to when you you are missing a binary while debugging a user-mode dump (lack of unwind data) of an x64 process, except in that case the stack trace usually does not stop "this sudden", rather it goes astray at that point, and shows bogus values.</p>

<p>Some extra info/things I tried:</p>

<ul>
<li>I have the correct symbol paths set up (both the Microsoft symbol server, and a local folder on the host with matching PDBs, even though the latter is not needed for just the stack trace)</li>
<li>I have a binary path set up (<code>.exepath</code>) containing matching binaries on the host (I've made absolutely sure of this; copied the binaries directly from the guest to the host machine)</li>
<li>If I put a breakpoint in one of the app's exported DLL functions, then when the debugger breaks in, I get a one-liner stack trace like this: <code>0000000000274b40  0000000000000000 MyAppDLL!SomeExportedFunction+0x32 [d:\whatever\path\myapplicationDLL.cpp @ 232]</code></li>
<li>I've tried virtually every combination of commands to get a stacktrace (<code>.process /i</code>, <code>.process /r /p</code>, <code>!process -1 7</code>, <code>.reload</code>s, <code>.reload /user</code>s, <code>.reload /f MyApp.exe</code>, <code>!thread [address] 1f</code>, etc.) with no success</li>
<li>Tried with an older version of windbg (<code>6.11.0001.404</code>) as well, same result</li>
<li>Also tried on Windows 8.1 as a guest with the very same binaries, same result</li>
<li><p><code>!sym noisy</code> output (irrelevant lines omitted):</p>

<p><code>0: kd&gt;.process /i [address]
0: kd&gt;g
0: kd&gt;.reload /user
0: kd&gt; !process -1 2
0: kd&gt; !thread [address] 1f
[...]
DBGHELP: d:\symbolcache\MyApp.pdb\76931C5A6C284779AD2F916CA324617E1\MyApp.pdb already cached
DBGHELP: MyApp - private symbols &amp; lines 
[...]</code></p></li>
<li><p><code>lmvm MyApp</code> output:</p>

<p><code>[...]
Loaded symbol image file: MyApp.exe
Image path: C:\MyApp\MyApp.exe
[...]</code></p></li>
</ul>

<p>Any ideas?</p>