I am using windbg with xp embedded. Attempting to fetch the operating system symbols fails with the message “Symbol file could not be found. Defaulted to export symbols for ntdll.dll”. (Is this typical for xp embedded???)
I have no problem locating and loading symbols and source for my own code. However stepping through the code suggests there is a severe mismatch between the code and the symbol file as the location of variables in memory as returned by dv does not appear to agree with the actual memory contents (e.g. assign a variable, but afterwards, the address that dv claims corresponds to it doesn’t appears unchanged).
My sympath lists the symbol directory first, then the cache, then the server so cached symbol files shouldn’t be interfering.
Is this a latent effect of not finding the ntdll symbol files and using another one that doesn’t match correctly or is there something else that could be causing this?
Example:
.sympath D:/Symbols
.symfix+
.srcpath D:/Symbols ** Yes, currently the source is in with the symbols
.reload
** (defaults to export symbols for ntdll.dll since symbol file can't be found)
bp 00401000 (break at a constructor)
g
(program runs till it hits constructor)
l+t
dv /i /t /V ** look up this pointer memory location to check constructor
** We bring up a memory window at the location the this pointer refers to and
** step through the code, but no changes appear in that memory window
** moreover a local LARGE_INTEGER whose value is set with QueryPerformanceCounter
** also appears unchanged after the call
** when the constructor returns we assign the memory address returned by
** new to a global pointer, whose memory address we look up with dt, but
** after the call that address still has 0 in it
Can anyone tell me how to actually fix this?
As a side note we actually run cdb as a server on the xp embedded machine and use the “connect to remote session” option of windbg. The above commands are all executed through windbg.
Executing !sym noisy before the .reload will let you know why it’s not finding symbols for ntdll.dll. It’s entirely possible that they’re simply not indexed on the symbol server, which generally means you are out of luck (there really isn’t anyone to contact to get this fixed unfortunately).
As for your other symbol issues:
1) Is this the release build of your code? If so, it’s entirely expected
2) If it is the debug build, are you 100% sure that the source you’re pointing to matches the target machine? Make sure you’re 100% before answering 🙂
-scott