WinDbg !wmitrace.start failing due to missing symbols?

dbarrie

I'm trying to set up a good workflow for getting trace logs displayed nicely in WinDbg for my kernel-mode driver that doesn't involve having to remember to copy files and muck about first on the target machine every time I start a new debug session. I am currently able to use traceview to load the driver's PDB file and get traces displayed in WinDbg, but it seems like the !wmitrace group of commands should allow me to do exactly the same operation from within the debugger, entirely on the host machine. Save the commands off as a script I can run easily, whatever.

However, attempting to start a new trace reports a bunch of missing symbols:

2: kd> !wmitrace.start myloggerid -kd
sym lookup 'nt!EtwpHostSiloState' failure
sym lookup 'nt!EtwpHostSiloState' failure
sym lookup 'nt!EtwpHostSiloState' failure
sym lookup 'nt!EtwpHostSiloState' failure
sym lookup 'nt!EtwpSiloState' failure
sym lookup 'nt!EtwpSiloState' failure
------------------------------------------------------
|                                                    |
|            NT symbols are not available            |
|   Kernel hints available (reduced functionality)   |
|                                                    |
------------------------------------------------------

sym lookup 'nt!EtwpHostSiloState' failure
sym lookup 'nt!EtwpHostSiloState' failure
sym lookup 'nt!EtwpSiloState' failure
sym lookup 'nt!EtwpSiloState' failure
sym lookup 'nt!EtwWmitraceWork' failure
sym lookup 'nt!EtwWmitraceWork' failure
sym lookup 'nt!ExpDebuggerWork' failure
sym lookup 'nt!ExpDebuggerWork' failure
Symbols are wrong or this version of the operating system does not support this command.

Obviously the command fails, and no myloggerid is created.

I'm pulling symbols down from MS' symbol store

2: kd> .sympath
Symbol search path is: srv*
Expanded Symbol search path is: cache*;SRV*https://msdl.microsoft.com/download/symbols

and other nt symbols show up just fine in the callstack. Running .symfix does not change the behavior. Symbols for the driver I'm debugging are also available, and I can step through code just fine. Everything else seems to be working, is what I'm getting at.

Both host and target machines are using the same version of Windows 10.

What gives?