I’m having some issues with WinDbg and wdfkd.dll extensions for kernel
mode debugging. I don’t have access to the checked build, so I am using
Windows XP Free build for x86 32-bit.
First of all, my symbol path seems to be correct (below), and
C:\driver\debug contains the PDB file with my driver’s private symbols.
When I break into the target machine, I first execute the following on
the debugger command prompt:
!sym noisy
.load C:\WinDDK\6001.18002\bin\x86\wdfkd.dll
.reload /f
g
I then run until I hit one of my break points. In the driver, data from
an is copied to a WDFMEMORY object on the local stack. I’d like to get
the address of the buffer associated with the WDFMEMORY object so I can
inspect its contents. As such, I used !wdfkd.wdfmemory passing it the
handle (the variable name, right?). I received a symbol error, so I
then tried to pass it the address of the WDFMEMORY object, but the same
error appeared (shown below).
1: kd> !wdfkd.wdfmemory reqMemory
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: IFxMemory ***
*** ***
*************************************************************************
Could not evaluate expression reinterpret_cast*>((FxMemoryObject *)(0x637da4c8))
Am I using the !wdf extensions incorrectly, or is there something else that I need to load? Is there a separate location other than the Microsoft URL for the WDF symbols? I’d greatly appreciate any ideas, thanks!
What version of KMDF are you using? Based on your WDK version I would assume 1.7 but it is good to verify. I took a quick look at the public symbols for wdf01000.sys and we are indeed exposing the type that the debugger says is missing. There could be a couple of issues.
WDFHANDLE addresses are typically under the 2GB (0x80000000) range, while the value you are passing in is over. The 0x637da4c8 value from your error looks promising as a handle value. Another useful command is “!wdfdriverinfo 0x10” is useful for dumping the entire handle hierarchy if there is any doubt.
2. If you are running a UMDF driver as well, it is possible you are getting a name conflict from that. If you do have a UMDF driver running as well, unload all the umdf symbols (wudf*.) and try again.
If this still doesn’t help, can you run “!lmi wdf01000” and post the output.
Brandon
-----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bryan R Sent: Monday, May 11, 2009 7:49 PM To: Kernel Debugging Interest List Subject: [windbg] WDF symbols issue
I’m having some issues with WinDbg and wdfkd.dll extensions for kernel mode debugging. I don’t have access to the checked build, so I am using Windows XP Free build for x86 32-bit.
First of all, my symbol path seems to be correct (below), and C:\driver\debug contains the PDB file with my driver’s private symbols.
----------------------------------------------------------------------------------------- 0: kd> .sympath Symbol search path is: srvC:\Symbols\WebSymbolshttp://msdl.microsoft.com/download/symbols;C:\driver\debug -----------------------------------------------------------------------------------------
When I break into the target machine, I first execute the following on the debugger command prompt:
----------------------------------------------------------------------------------------- !sym noisy .load C:\WinDDK\6001.18002\bin\x86\wdfkd.dll .reload /f g -----------------------------------------------------------------------------------------
I then run until I hit one of my break points. In the driver, data from an is copied to a WDFMEMORY object on the local stack. I’d like to get the address of the buffer associated with the WDFMEMORY object so I can inspect its contents. As such, I used !wdfkd.wdfmemory passing it the handle (the variable name, right?). I received a symbol error, so I then tried to pass it the address of the WDFMEMORY object, but the same error appeared (shown below).
1: kd> !wdfkd.wdfmemory reqMemory Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: IFxMemory
Could not evaluate expression reinterpret_cast>((FxMemoryObject *)(0x637da4c8))
Am I using the !wdf extensions incorrectly, or is there something else that I need to load? Is there a separate location other than the Microsoft URL for the WDF symbols? I’d greatly appreciate any ideas, thanks!
Thanks for the feedback.
I’m using WDK 6001.18002, with KMDF 1.7. I just thought I should
mention that WinDbg has wdfkd.dll (v 6.1.6721.1)in its winext folder,
but I am explicitly loading wdfkd.dll (v 6.0.6001.18000) that is
provided in the WDK. Could this be a potential source of problems?
WDFHANDLE addresses are typically under the 2GB (0x80000000) range, while the value you are passing in is
over. The 0x637da4c8 value from your error looks promising as a handle
value. Another useful command is “!wdfdriverinfo 0x10” is useful for dumping the entire handle hierarchy if there is any doubt.
I tried “!wdfdriverinfo 0x10” and have pasted the output at the end of this message due to the length. It would appear that I’m having a symbol issue. Before executing the command, I did use the .load command to bring in wdfkd.dll. When I do this, there is no output on the screen–is that normal? I also did a “.reload /f” just to make sure all of the right modules were loaded.
> 2. If you are running a UMDF driver as well, it is possible you are getting a name conflict from that. If you do have a UMDF driver running as well, unload all the umdf symbols (wudf*.) and try again.
I’m not using UMDF for this driver, but it is possible that the JTAG debugger attached to the hardware is using UMDF. I ran the following and it doesn’t appear that UMDF modules are loaded: ------------------------------------ 0: kd> lm m wudf start end module name ------------------------------------
> If this still doesn’t help, can you run “!lmi wdf01000” and post the output.
Here is the output I have: ------------------------------------ 1: kd> !lmi wdf01000 Loaded Module Info: [wdf01000] Couldn’t find process 0xf0f0f0f0 while looking for wdf01000 ------------------------------------
I then ran the following: ------------------------------------ 1: kd> lm m wdf* start end module name b8cc4000 b8d40000 wdf01000 (no symbols) f751a000 f7527000 WDFLDR (export symbols) WDFLDR.SYS ------------------------------------
Does this provide any additional clues? Thank you for your time and help.
Bryan
Output of “!wdfdriverinfo” ------------------------------------- 1: kd> !wdfdriverinfo dspdriver 0x10 ---------------------------------- Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
warning: Could not read the WdfBindInfo pointer Default driver image name: dspdriver WDF library image name: Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
FxDriverGlobals 0x8a0c31f8 Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
WdfBindInfo 0x00000000 ---------------------------------- Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
Well the problem is there are no symbols (private or public) loaded for wdf01000. The output of “!lmi” is very strange, this should display info about the module even if the symbols are not loaded. It is possible that you don’t have some of the core symbols loaded needed to do this mapping. Do:
.reload /u
.reload // Makes sure you have all the correct symbols
!sym noisy // This will hopefully give some hints as to why symbol loads are failing, “!sym quiet” undoes this
.reload /f wdf01000.sys // This will force it to load the wdf01000 symbols
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bryan R
Sent: Wednesday, May 13, 2009 8:40 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] WDF symbols issue
Hello Brandon,
Thanks for the feedback.
I’m using WDK 6001.18002, with KMDF 1.7. I just thought I should
mention that WinDbg has wdfkd.dll (v 6.1.6721.1)in its winext folder,
but I am explicitly loading wdfkd.dll (v 6.0.6001.18000) that is
provided in the WDK. Could this be a potential source of problems?
WDFHANDLE addresses are typically under the 2GB (0x80000000) range, while the value you are passing in is
over. The 0x637da4c8 value from your error looks promising as a handle
value. Another useful command is “!wdfdriverinfo 0x10” is useful for dumping the entire handle hierarchy if there is any doubt.
I tried “!wdfdriverinfo 0x10” and have pasted the output at the end of this message due to the length. It would appear that I’m having a symbol issue. Before executing the command, I did use the .load command to bring in wdfkd.dll. When I do this, there is no output on the screen–is that normal? I also did a “.reload /f” just to make sure all of the right modules were loaded.
> 2. If you are running a UMDF driver as well, it is possible you are getting a name conflict from that. If you do have a UMDF driver running as well, unload all the umdf symbols (wudf*.) and try again.
I’m not using UMDF for this driver, but it is possible that the JTAG debugger attached to the hardware is using UMDF. I ran the following and it doesn’t appear that UMDF modules are loaded: ------------------------------------ 0: kd> lm m wudf start end module name ------------------------------------
> If this still doesn’t help, can you run “!lmi wdf01000” and post the output.
Here is the output I have: ------------------------------------ 1: kd> !lmi wdf01000 Loaded Module Info: [wdf01000] Couldn’t find process 0xf0f0f0f0 while looking for wdf01000 ------------------------------------
I then ran the following: ------------------------------------ 1: kd> lm m wdf* start end module name b8cc4000 b8d40000 wdf01000 (no symbols) f751a000 f7527000 WDFLDR (export symbols) WDFLDR.SYS ------------------------------------
Does this provide any additional clues? Thank you for your time and help.
Bryan
Output of “!wdfdriverinfo” ------------------------------------- 1: kd> !wdfdriverinfo dspdriver 0x10 ---------------------------------- Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
warning: Could not read the WdfBindInfo pointer Default driver image name: dspdriver WDF library image name: Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
FxDriverGlobals 0x8a0c31f8 Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
WdfBindInfo 0x00000000 ---------------------------------- Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
Your debugger is not using the correct symbols In order for this command to work properly, your symbol path must point to .pdb files that have full type information. Certain .pdb files (such as the public OS symbols) do not contain the required information. Contact the group that provided you with these symbols if you need this command to work. Type referenced: _FX_DRIVER_GLOBALS
I then thought I’d try the symbol package download. I downloaded the
symbol package and installed it locally on my machine, in
C:\Symbols\Installed, and changed WinDbg’s symbol path. The transcript
of the session is below:
0: kd> .sympath C:\Symbols\Installed
Symbol search path is: C:\Symbols\Installed
0: kd> .reload
Connected to Windows XP 2600 x86 compatible target at (Fri May 15
14:03:20.078 2009 (GMT+9)), ptr64 FALSE
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for ntkrnlmp.exe -
Loading Kernel Symbols
…
…
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol
loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
…
…
Loading User Symbols
Loading unloaded module list
…
0: kd> lm m wdf*
start end module name
b8d08000 b8d84000 wdf01000 (deferred)
ba23c000 ba249000 WDFLDR (deferred)
0: kd> .reload /f wdf01000.sys
*** ERROR: Module load completed but symbols could not be loaded for
wdf01000.sys
0: kd> lm m wdf*
start end module name
b8d08000 b8d84000 wdf01000 (no symbols)
ba23c000 ba249000 WDFLDR (deferred)
Did !sym noisy give any hints as to why it is failing to load modules?
Can you load symbols for other OS modules from either the symbol store or the symbol CD? If you can’t load other modules from the symbol server, it sounds like a general problem with how you are configured, perhaps windbg doesn’t have access to the network.
What version of the symbol package download did you get? KMDF is not inbox on XP so it would not be present in any of the XP symbol packages. Version 1.7 shipped with Vista SP1/Server 2k8 so it would be present in those packages, although that is a bit overkill.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Bryan R
Sent: Thursday, May 14, 2009 10:21 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] WDF symbols issue
I tried the steps you outlined, and after executing “.reload /f
wdf01000.sys”, WinDbg reported:
0: kd> .reload /f wdf01000.sys
*** ERROR: Module load completed but symbols could not be loaded for
wdf01000.sys
I then thought I’d try the symbol package download. I downloaded the
symbol package and installed it locally on my machine, in
C:\Symbols\Installed, and changed WinDbg’s symbol path. The transcript
of the session is below:
0: kd> .sympath C:\Symbols\Installed
Symbol search path is: C:\Symbols\Installed
0: kd> .reload
Connected to Windows XP 2600 x86 compatible target at (Fri May 15
14:03:20.078 2009 (GMT+9)), ptr64 FALSE
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for ntkrnlmp.exe -
Loading Kernel Symbols
…
…
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol
loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
…
…
Loading User Symbols
Loading unloaded module list
…
0: kd> lm m wdf*
start end module name
b8d08000 b8d84000 wdf01000 (deferred)
ba23c000 ba249000 WDFLDR (deferred)
0: kd> .reload /f wdf01000.sys
*** ERROR: Module load completed but symbols could not be loaded for
wdf01000.sys
0: kd> lm m wdf*
start end module name
b8d08000 b8d84000 wdf01000 (no symbols)
ba23c000 ba249000 WDFLDR (deferred)
This is a total guess with nothing really to support it, but I noticed that the bin\x86 dir of the 6001.18002 wdk has it’s own copy of dbghelp.dll and I’m wondering if this might be contributing to the (what appear to be) weird symbol problems.
I don’t imagine that it is, but I thought I would throw it out there.
Did !sym noisy give any hints as to why it is failing to load modules?
I attached a transcript at the end of this e-mail, but there were no
hints as to why the symbols could not be loaded.
What version of the symbol package download did you get?
Can you load symbols for other OS modules from either the symbol store or the symbol CD?
I switched over from the using the web downloaded symbols to a local
install of the Windows Vista SP2 symbols. The package I downloaded is
“WindowsVista.6002.090410-1830.x86fre.Symbols”.
I tried a few other sys files from System32\Drivers, but I got the same
error:
0: kd> .reload /f pci.sys
*** ERROR: Module load completed but symbols could not be loaded for pci.sys
0: kd> .reload /f usbehci.sys
*** ERROR: Module load completed but symbols could not be loaded for
usbehci.sys
Oddly enough, C:\Symbols\Installed\sys has both pci.pdb and usbehci.pdb.
It also has wdf01000.pdb.
I checked the symbol path and it should be OK:
C:\Symbols\Installed
I even tried
C:\Symbols\Installed\sys
but with no success.
_NT_SYMBOL_PATH
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \.\com1
Waiting to reconnect…
Connected to Windows XP 2600 x86 compatible target at (Mon May 18
11:05:34.281 2009 (GMT+9)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is:
srv*C:\Symbols\WebSymbols*http://msdl.microsoft.com/download/symbols;C:\driver\debug
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86
compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp3_gdr.090206-1234
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x805634c0
Debug session time: Mon May 18 11:05:41.078 2009 (GMT+9)
System Uptime: 0 days 0:23:28.765
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
*
*
* You are seeing this message because you pressed either
*
* CTRL+C (if you run kd.exe) or,
*
* CTRL+BREAK (if you run WinDBG),
*
* on your debugger machine’s keyboard.
*
*
*
* THIS IS NOT A BUG OR A SYSTEM CRASH
*
*
*
* If you did not intend to break into the debugger, press the “g” key,
then *
* press the “Enter” key now. This message might immediately reappear.
If it *
* does, press “g” and “Enter” again.
*
*
*
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
804e2a52 cc int 3
0: kd> .reload /u
Unloaded all modules
0: kd> .reload
Connected to Windows XP 2600 x86 compatible target at (Mon May 18
11:06:38.609 2009 (GMT+9)), ptr64 FALSE
Loading Kernel Symbols
…
…
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol
loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
…
…
Loading User Symbols
Loading unloaded module list
…
0: kd> !sym noisy
noisy mode - symbol prompts on
0: kd> .reload /f wdf01000.sys
*** ERROR: Module load completed but symbols could not be loaded for
wdf01000.sys
0: kd> lm m wdf*
start end module name
b8cfe000 b8d7a000 wdf01000 (no symbols)
ba246000 ba253000 WDFLDR (deferred)
> This is a total guess with nothing really to support it, but I noticed that the bin\x86 dir of the 6001.18002 wdk has it’s own copy of dbghelp.dll and I’m wondering if this might be contributing to the (what appear to be) weird symbol problems.
I don’t imagine that it is, but I thought I would throw it out there.
Speaking of dbghelp.dll, I was debugging with the TraceView utility up
until recently as the complexity increased in the driver and outgrew
TraceView.
I had to copy dbghelp.dll from %WDKPATH%\bin\x86 to
%WDKPATH%\tools\tracing\i386 to properly generate trace files. My
current Makefile still produces the the trace files just in case. I
will remove the trace file generation from my build process and see what
happens. It is worth a try at this point.
I apologize for the last message, hitting the enter key sent the message
when I meant for a line break.
> 3. What version of the symbol package download did you get?
> 2. Can you load symbols for other OS modules from either the symbol
store or the symbol CD?
For some reason I cannot get WinDbg (or kd stand-alone) to recognize the
symbol files in C:\Symbols\Installed from the Windows Vista SP2 symbol
package. I’ve refreshed and updated the WinDbg workspace, I set the
_NT_SYMBOL_PATH environment variable, and I have also overridden the
symbol path with the .sympath command. When WinDbg breaks into a debug
session, the symbol path seems to be set properly:
Opened \.\com1
Waiting to reconnect…
Connected to Windows XP 2600 x86 compatible target at (Mon May 18
11:05:34.281 2009 (GMT+9)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is:
C:\Symbols\Installed;C:\driver\debug
I have confirmed that wdf01000.pdb is physically on the disk in
C:\Symbols\Installed\sys, but still I cannot load symbols for
wdf01000.sys and !sym noisy does not provide any information on why it
could not load the symbol package.
Does one have to have the checked build of Windows from MSDN to be able
to do WDF debugging?
Also, you’re output doesn’t look correct, assuming that you’ve issued a ‘!sym noisy.’
This might be due to no using the ‘-f’ with .reload.
Just to make sure:
Restart windbg
break in
.symopt+ 0x80000000
.reload -f -n
Somewhere in that output, you should see something like what’s below for any file for which symbols failed to load (like, for example, ‘peauth.sys’ which never has symbols):
If you don’t see this, then you have something fundamentally wrong with either your windbg installation and/or you might have some rogue dbghelp.dll/dbgeng.dll out there. Either way, if you don’t see this type of trace information, I would recommend that you cease and desist on trying to figure out why it’s not working, and reinstall (in this order): wdk & windbg. You could also search all your local drivers for copies of dbghelp.dll/dbgeng.dll and rename/delete, but I would waste any more time, if this is the case.
I don’t think so. There are quite a few symbols that have been
downloaded, but wdf01000.pdb in the sys folder is not downloaded. For
now I’m working with the installable symbol package for Vista SP2.
How about your own symbols?
I think so. If I load the symbols manually, there is no output in
WinDbg reporting success or error, but I can set breakpoints using
function names in my driver and I can generally step through my driver
with no problems.
Also, you’re output doesn’t look correct, assuming that you’ve issued a ‘!sym noisy.’
This might be due to no using the ‘-f’ with .reload.
.reload -f -n
WinDbg spewed out quite a bit, and a lot of it looked like this:
DBGENG: \SystemRoot\System32\win32k.sys - Image mapping disallowed by
non-local path.
DBGHELP: Module is not fully loaded into memory.
DBGHELP: Searching for symbols using debugger-provided data.
DBGHELP: C:\Symbols\Installed\win32k.pdb - file not found
DBGHELP: C:\Symbols\Installed\sys\win32k.pdb - mismatched pdb
DBGHELP: C:\Symbols\Installed\symbols\sys\win32k.pdb - file not found
DBGHELP: C:\driver\debug\win32k.pdb - file not found
DBGHELP: C:\driver\debug\sys\win32k.pdb - file not found
DBGHELP: C:\driver\debug\symbols\sys\win32k.pdb - file not found
DBGHELP: C:\Symbols\Installed\sys\win32k.pdb - mismatched pdb
DBGHELP: C:\Symbols\Installed\sys\sys\win32k.pdb - file not found
DBGHELP: C:\Symbols\Installed\sys\symbols\sys\win32k.pdb - file not found
DBGHELP: win32k.pdb - file not found
DBGHELP: Couldn’t load mismatched pdb for win32k.sys
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for
win32k.sys
DBGHELP: win32k - no symbols loaded
The “DBGHELP: C:\Symbols\Installed\sys\win32k.pdb - mismatched pdb”
really stands out as odd to me. I’ll take your advice and re-install
WDK and WinDbg. Thanks for all of the help!
Are you launching the debugger from its installation directory?
This sounds to me a bit like the debugger is picking up dbghelp.dll or dbgeng.dll that ship with the OS and don’t have symbol server support enabled, rather than the DLLs shipping with the debugger distribution which support the symbol server.
S
From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Bryan R [xxxxx@gmail.com]
Sent: Monday, May 18, 2009 3:28 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] WDF symbols issue
I don’t think so. There are quite a few symbols that have been
downloaded, but wdf01000.pdb in the sys folder is not downloaded. For
now I’m working with the installable symbol package for Vista SP2.
How about your own symbols?
I think so. If I load the symbols manually, there is no output in
WinDbg reporting success or error, but I can set breakpoints using
function names in my driver and I can generally step through my driver
with no problems.
Also, you’re output doesn’t look correct, assuming that you’ve issued a ‘!sym noisy.’
This might be due to no using the ‘-f’ with .reload.
.reload -f -n
WinDbg spewed out quite a bit, and a lot of it looked like this:
DBGENG: \SystemRoot\System32\win32k.sys - Image mapping disallowed by
non-local path.
DBGHELP: Module is not fully loaded into memory.
DBGHELP: Searching for symbols using debugger-provided data.
DBGHELP: C:\Symbols\Installed\win32k.pdb - file not found
DBGHELP: C:\Symbols\Installed\sys\win32k.pdb - mismatched pdb
DBGHELP: C:\Symbols\Installed\symbols\sys\win32k.pdb - file not found
DBGHELP: C:\driver\debug\win32k.pdb - file not found
DBGHELP: C:\driver\debug\sys\win32k.pdb - file not found
DBGHELP: C:\driver\debug\symbols\sys\win32k.pdb - file not found
DBGHELP: C:\Symbols\Installed\sys\win32k.pdb - mismatched pdb
DBGHELP: C:\Symbols\Installed\sys\sys\win32k.pdb - file not found
DBGHELP: C:\Symbols\Installed\sys\symbols\sys\win32k.pdb - file not found
DBGHELP: win32k.pdb - file not found
DBGHELP: Couldn’t load mismatched pdb for win32k.sys
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for
win32k.sys
DBGHELP: win32k - no symbols loaded
The “DBGHELP: C:\Symbols\Installed\sys\win32k.pdb - mismatched pdb”
really stands out as odd to me. I’ll take your advice and re-install
WDK and WinDbg. Thanks for all of the help!