I have a perplexing problem with livekd. I've downloaded the latest version of livekd (3.0) and the debugging tools for windows (server 2k3 R2). I configured the symbol path using the canonical example (minus the hxxp mangling ):
_NT_SYMBOL_PATH=srv*C:\Symbols*hxxp://msdl.microsoft.com/download/symbols

The _NT_SYMBOL_PATH environment variable is a user variable rather than a system variable, but I don't see why that would matter. Moreover, this is how livekd prefers to set the symbol path if you allow it to automatically configure the path for you.

Whenver I run livekd (whether I use use kd.exe or windbg.exe), it fails with the error, "Could not resolve symbols for ntoskrnl.exe." This is odd, because the symbol store seems to be working correctly in all other instances.

If I open an executable with windbg, I can see that it downloads and resolves the symbols for various linked microsoft dlls. Process explorer (also by sysinternals) is able to resolve symbols just fine, too. For example, it downloads notepad.pdb, and shows the start address of notepad.exe's only thread as "notepad.exe!WinMainCRTStartup" instead of a raw address.

In my local symbol store, livekd is definitely downloading the symbols for ntkrnlmp.exe. This workstation has a dual-core processor, so this should be correct. I don't know why livekd is failing to resolve the symbols for ntoskernel.exe since it successfully retreived ntkrnlmp.pdb. Has anyone encountered this before? Everything *looks* right; I don't know what I'm doing wrong.

Hi TBone

It sounds like livekd isn't recognizing that you're running the multiprocessor Ntkrnlmp.exe instead of the uniprocessor Ntoskrnl.exe, or it just doesn't support it. Are you sure your system is actually loading ntkrnlmp, as I think this can be bypassed in the bios setup.

I think your symbol download should also have included ntoskrnl.pdb as well as ntkrnlmp.pdb (I know my C:\Symbols directory includes both even though my system runs ntoskrnl.exe). Chances are if you have ntoskrnl.pdb present it should get rid of the error message at least.

Kayaker

Edit: I found the problem! Ok, sorry this is the 3rd time I've completely re-written this post, but the thread was going to be very long and largely irrelevant, now that I know what the problem was.

I found an interesting usenet post to microsoft.public.win32.programmer.tools yesterday. Somebody who was having the exact same problem posted:

Well, that didn't work for me. However, deleting everything in my symbols folder (except for pingme.txt), seems to have solved the problem. For reference, windbg does *not* download the debugging symbols for ntoskrnl.exe if you have the multiprocessor kernel. As I initially suspected, there are no common symbols that are shared between the different kernel images. The executables are likely different enough that there wouldn't be many variables/functions/etc. with the same RVA across all versions. Windbg and kd are both working correctly under livekd now, and only ntkrnlmp.pdb has been downloaded.

Other things that I have learned from this:
Always quit windbg with the Q command at the lkd> prompt. If you just exit windbg from the file menu or by hitting the x, it doesn't delete kldbgdrv.sys. This is probably a bug, but it's good procedure anyway. If you try to start a local kernel debugging session while kldbgdrv.sys exists, windbg believes that there's already a kernel debugging session in progress.