Problems resolved, and other problems found

WINDBG
1

Problems solved:

Jason provided a lot of assistance in resolving the performance issues with
the checked build. A temporary work around seems to be to NOT use the symbol
in the path except when you REALLY want to update your symbols, but I will
let him address that.

Other problems found:

It seems that when using .kdfiles to map to the SYS file to an alternate,
the pdb will not automatically map as well. That really makes no sense,
because I map the deriver file to the target file from the build, which is
the same path to find the PDB as the SYS file in SystemRoot\Drivers. This
means that it is a pain in the ass to change the SYS file because it entails
booting to a clean OS that will not load your driver, typically Safe Mode,
replace the SYS files, and then boot BACK to the test OS that will load your
driver. I thought .kdfiles that if .kdfiles changed the path to the mapped
path, that it would do the same for the pdb file, but from what I have seen
thus far that is not the case.

Case in point:
After a rebuild, but before refreshing
:\Windows\System32\Drivers\OSEEntry.sys

1: kd> .kdfiles
KD file assocations loaded from ‘C:\Windows\Mapped.ini’
SystemRoot\System32\Drivers\OSEEntry.sys ->
C:\SandBox\OpenSea\SeaKernel\OSE\objchk_wnet_x86\i386\OSEEntry.sys
1: kd> bu OSEEntry!OSEEvtDevicePrepareHardware
1: kd> !reload
Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
SYMSRV:
c:\Symbols\Cache\ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb
not found
SYMSRV: ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb not
found
DBGHELP:
c:\symbols\ntkrnlmp.pdb\7DE39A3E89DA4B378B95A09FA3A6398C2\ntkrnlmp.pdb -
mismatched pdb
DBGHELP:
c:\symbols\ntkrnlmp.pdb\AA1EE1B2A63A4232A379F3EFDDC4CFE82\ntkrnlmp.pdb -
mismatched pdb
DBGHELP: nt - public symbols
c:\symbols\ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb
Loading Kernel Symbols
…
Loading unloaded module list
…
Loading User Symbols
…
SYMSRV:
c:\Symbols\Cache\OSEEntry.pdb\4E2ABB9D0C4B4AC0AAB1C0DE4A5CF91F1\OSEEntry.pdb
not found
SYMSRV: OSEEntry.pdb\4E2ABB9D0C4B4AC0AAB1C0DE4A5CF91F1\OSEEntry.pdb not
found
DBGHELP: c:\symbols\OSEEntry.pdb - file not found
DBGHELP: c:\symbols\symbols\sys\OSEEntry.pdb - file not found
DBGHELP: c:\symbols\sys\OSEEntry.pdb - file not found
DBGHELP:
c:\sandbox\opensea\seakernel\ose\objchk_wnet_x86\i386\OSEEntry.pdb -
mismatched pdb
DBGHELP: Couldn’t load mismatched pdb for OSEEntry.sys
*** ERROR: Module load completed but symbols could not be loaded for
OSEEntry.sys
DBGHELP: OSEEntry - no symbols loaded

The PDB file sits in the same path as the re-mapped SYS file, indeed has the
same date/time stamp.

–
The personal opinion of
Gary G. Little

2

Sheesh … talk about confusing …

The temporary work around is to NOT use the symbol SERVER in the debug
symbol path. You can set it to the server, then do a !reload /f, then set it
back, as needed.

–
The personal opinion of
Gary G. Little

“Gary G. Little” wrote in message news:xxxxx@windbg…
> Problems solved:
>
> Jason provided a lot of assistance in resolving the performance issues
> with the checked build. A temporary work around seems to be to NOT use the
> symbol in the path except when you REALLY want to update your symbols, but
> I will let him address that.
>
> Other problems found:
>
> It seems that when using .kdfiles to map to the SYS file to an alternate,
> the pdb will not automatically map as well. That really makes no sense,
> because I map the deriver file to the target file from the build, which is
> the same path to find the PDB as the SYS file in SystemRoot\Drivers. This
> means that it is a pain in the ass to change the SYS file because it
> entails booting to a clean OS that will not load your driver, typically
> Safe Mode, replace the SYS files, and then boot BACK to the test OS that
> will load your driver. I thought .kdfiles that if .kdfiles changed the
> path to the mapped path, that it would do the same for the pdb file, but
> from what I have seen thus far that is not the case.
>
> Case in point:
> After a rebuild, but before refreshing
> :\Windows\System32\Drivers\OSEEntry.sys
>
>
> 1: kd> .kdfiles
> KD file assocations loaded from ‘C:\Windows\Mapped.ini’
> SystemRoot\System32\Drivers\OSEEntry.sys ->
> C:\SandBox\OpenSea\SeaKernel\OSE\objchk_wnet_x86\i386\OSEEntry.sys
> 1: kd> bu OSEEntry!OSEEvtDevicePrepareHardware
> 1: kd> !reload
> Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
> SYMSRV:
> c:\Symbols\Cache\ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb
> not found
> SYMSRV: ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb not
> found
> DBGHELP:
> c:\symbols\ntkrnlmp.pdb\7DE39A3E89DA4B378B95A09FA3A6398C2\ntkrnlmp.pdb -
> mismatched pdb
> DBGHELP:
> c:\symbols\ntkrnlmp.pdb\AA1EE1B2A63A4232A379F3EFDDC4CFE82\ntkrnlmp.pdb -
> mismatched pdb
> DBGHELP: nt - public symbols
> c:\symbols\ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb
> Loading Kernel Symbols
> …
> Loading unloaded module list
> …
> Loading User Symbols
> …
> SYMSRV:
> c:\Symbols\Cache\OSEEntry.pdb\4E2ABB9D0C4B4AC0AAB1C0DE4A5CF91F1\OSEEntry.pdb
> not found
> SYMSRV: OSEEntry.pdb\4E2ABB9D0C4B4AC0AAB1C0DE4A5CF91F1\OSEEntry.pdb not
> found
> DBGHELP: c:\symbols\OSEEntry.pdb - file not found
> DBGHELP: c:\symbols\symbols\sys\OSEEntry.pdb - file not found
> DBGHELP: c:\symbols\sys\OSEEntry.pdb - file not found
> DBGHELP:
> c:\sandbox\opensea\seakernel\ose\objchk_wnet_x86\i386\OSEEntry.pdb -
> mismatched pdb
> DBGHELP: Couldn’t load mismatched pdb for OSEEntry.sys
> *** ERROR: Module load completed but symbols could not be loaded for
> OSEEntry.sys
> DBGHELP: OSEEntry - no symbols loaded
>
> The PDB file sits in the same path as the re-mapped SYS file, indeed has
> the same date/time stamp.
>
> –
> The personal opinion of
> Gary G. Little
>
>

3

I must stress that those steps are just that: a workaround. My
intention for having you try that was to eliminate the Internet Symbol
Server as a variable in the equation, to potentially find the cause of
your 2 hour boot time. Being that this appeared to be the cause, I
thought I’d mention the workaround just in case you were tired of
sending me more info and just wanted to be done with the whole thing :slight_smile:

In the last mail to you, I also mentioned to start from a fresh
workspace (yea, I know that sucks, but tends to lead to goodness).
Hopefully this will get you back to a speedy experience with the
internet symbol server turned on and working automagically.

Regarding the .kdfiles issue below, I can’t say what’s causing it very
easily from here, however can offer -yet another workaround-. ‘.reload
/f /i OSEEntry.sys’

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Tuesday, August 23, 2005 11:23 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Problems resolved, and other problems found

Sheesh … talk about confusing …

The temporary work around is to NOT use the symbol SERVER in the debug
symbol path. You can set it to the server, then do a !reload /f, then
set it
back, as needed.

–
The personal opinion of
Gary G. Little

“Gary G. Little” wrote in message
news:xxxxx@windbg…
> Problems solved:
>
> Jason provided a lot of assistance in resolving the performance issues

> with the checked build. A temporary work around seems to be to NOT use
the
> symbol in the path except when you REALLY want to update your symbols,
but
> I will let him address that.
>
> Other problems found:
>
> It seems that when using .kdfiles to map to the SYS file to an
alternate,
> the pdb will not automatically map as well. That really makes no
sense,
> because I map the deriver file to the target file from the build,
which is
> the same path to find the PDB as the SYS file in SystemRoot\Drivers.
This
> means that it is a pain in the ass to change the SYS file because it
> entails booting to a clean OS that will not load your driver,
typically
> Safe Mode, replace the SYS files, and then boot BACK to the test OS
that
> will load your driver. I thought .kdfiles that if .kdfiles changed the

> path to the mapped path, that it would do the same for the pdb file,
but
> from what I have seen thus far that is not the case.
>
> Case in point:
> After a rebuild, but before refreshing
> :\Windows\System32\Drivers\OSEEntry.sys
>
>
> 1: kd> .kdfiles
> KD file assocations loaded from ‘C:\Windows\Mapped.ini’
> SystemRoot\System32\Drivers\OSEEntry.sys ->
> C:\SandBox\OpenSea\SeaKernel\OSE\objchk_wnet_x86\i386\OSEEntry.sys
> 1: kd> bu OSEEntry!OSEEvtDevicePrepareHardware
> 1: kd> !reload
> Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
> SYMSRV:
>
c:\Symbols\Cache\ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp
.pdb
> not found
> SYMSRV: ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb
not
> found
> DBGHELP:
> c:\symbols\ntkrnlmp.pdb\7DE39A3E89DA4B378B95A09FA3A6398C2\ntkrnlmp.pdb
-
> mismatched pdb
> DBGHELP:
> c:\symbols\ntkrnlmp.pdb\AA1EE1B2A63A4232A379F3EFDDC4CFE82\ntkrnlmp.pdb
-
> mismatched pdb
> DBGHELP: nt - public symbols
> c:\symbols\ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb
> Loading Kernel Symbols
>
…
…
> Loading unloaded module list
> …
> Loading User Symbols
> …
> SYMSRV:
>
c:\Symbols\Cache\OSEEntry.pdb\4E2ABB9D0C4B4AC0AAB1C0DE4A5CF91F1\OSEEntry
.pdb
> not found
> SYMSRV: OSEEntry.pdb\4E2ABB9D0C4B4AC0AAB1C0DE4A5CF91F1\OSEEntry.pdb
not
> found
> DBGHELP: c:\symbols\OSEEntry.pdb - file not found
> DBGHELP: c:\symbols\symbols\sys\OSEEntry.pdb - file not found
> DBGHELP: c:\symbols\sys\OSEEntry.pdb - file not found
> DBGHELP:
> c:\sandbox\opensea\seakernel\ose\objchk_wnet_x86\i386\OSEEntry.pdb -
> mismatched pdb
> DBGHELP: Couldn’t load mismatched pdb for OSEEntry.sys
> *** ERROR: Module load completed but symbols could not be loaded for
> OSEEntry.sys
> DBGHELP: OSEEntry - no symbols loaded
>
> The PDB file sits in the same path as the re-mapped SYS file, indeed
has
> the same date/time stamp.
>
> –
> The personal opinion of
> Gary G. Little
>
>

—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

I almost had jumped in to ask if Gary had tried this with an empty
workspace, since I knew that was a problem with the “new and improved”
WinDBG, TWO YEARS AGO! But after this much time, one would have hoped it
was fixed.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Jason Shay” wrote:
In the last mail to you, I also mentioned to start from a fresh
workspace (yea, I know that sucks, but tends to lead to goodness).
Hopefully this will get you back to a speedy experience with the
internet symbol server turned on and working automagically.

5

Well, .kdfiles is useless, or I’m not using it correctly. The only way I can
get symbols resolved is to manually copy a new SYS file to the
>SystemRoot>\Drivers directory. And even doing that I often get this
sequence when I set a breakpoint:

0: kd> bu OSEEntry!OSEEvtDevicePrepareHardware
DBGHELP:
C:\Symbols\Cache\OSEEntry.pdb\A2C2A32E51624F3180B0E1B261C308661\OSEEntry.pdb

  • mismatched pdb
    DBGHELP:
    c:\sandbox\opensea\seakernel\ose\objchk_wnet_x86\i386\OSEEntry.pdb -
    mismatched pdb
    DBGHELP: Couldn’t load mismatched pdb for OSEEntry.sys
    *** ERROR: Module load completed but symbols could not be loaded for
    OSEEntry.sys
    DBGHELP: OSEEntry - no symbols loaded
    Couldn’t resolve error at ‘OSEEntry!OSEEvtDevicePrepareHardware’

By the way, I had manually created the proper directory’s in \Symbos and
\Symbols\Cache and copied the pdb file to both of them. Still did not work.

–
The personal opinion of
Gary G. Little

“Gary G. Little” wrote in message news:…
> Sheesh … talk about confusing …
>
> The temporary work around is to NOT use the symbol SERVER in the debug
> symbol path. You can set it to the server, then do a !reload /f, then set
> it back, as needed.
>
> –
> The personal opinion of
> Gary G. Little
>
> “Gary G. Little” wrote in message news:xxxxx@windbg…
>> Problems solved:
>>
>> Jason provided a lot of assistance in resolving the performance issues
>> with the checked build. A temporary work around seems to be to NOT use
>> the symbol in the path except when you REALLY want to update your
>> symbols, but I will let him address that.
>>
>> Other problems found:
>>
>> It seems that when using .kdfiles to map to the SYS file to an alternate,
>> the pdb will not automatically map as well. That really makes no sense,
>> because I map the deriver file to the target file from the build, which
>> is the same path to find the PDB as the SYS file in SystemRoot\Drivers.
>> This means that it is a pain in the ass to change the SYS file because it
>> entails booting to a clean OS that will not load your driver, typically
>> Safe Mode, replace the SYS files, and then boot BACK to the test OS that
>> will load your driver. I thought .kdfiles that if .kdfiles changed the
>> path to the mapped path, that it would do the same for the pdb file, but
>> from what I have seen thus far that is not the case.
>>
>> Case in point:
>> After a rebuild, but before refreshing
>> :\Windows\System32\Drivers\OSEEntry.sys
>>
>>
>> 1: kd> .kdfiles
>> KD file assocations loaded from ‘C:\Windows\Mapped.ini’
>> SystemRoot\System32\Drivers\OSEEntry.sys ->
>> C:\SandBox\OpenSea\SeaKernel\OSE\objchk_wnet_x86\i386\OSEEntry.sys
>> 1: kd> bu OSEEntry!OSEEvtDevicePrepareHardware
>> 1: kd> !reload
>> Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
>> SYMSRV:
>> c:\Symbols\Cache\ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb
>> not found
>> SYMSRV: ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb not
>> found
>> DBGHELP:
>> c:\symbols\ntkrnlmp.pdb\7DE39A3E89DA4B378B95A09FA3A6398C2\ntkrnlmp.pdb -
>> mismatched pdb
>> DBGHELP:
>> c:\symbols\ntkrnlmp.pdb\AA1EE1B2A63A4232A379F3EFDDC4CFE82\ntkrnlmp.pdb -
>> mismatched pdb
>> DBGHELP: nt - public symbols
>> c:\symbols\ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb
>> Loading Kernel Symbols
>> …
>> Loading unloaded module list
>> …
>> Loading User Symbols
>> …
>> SYMSRV:
>> c:\Symbols\Cache\OSEEntry.pdb\4E2ABB9D0C4B4AC0AAB1C0DE4A5CF91F1\OSEEntry.pdb
>> not found
>> SYMSRV: OSEEntry.pdb\4E2ABB9D0C4B4AC0AAB1C0DE4A5CF91F1\OSEEntry.pdb not
>> found
>> DBGHELP: c:\symbols\OSEEntry.pdb - file not found
>> DBGHELP: c:\symbols\symbols\sys\OSEEntry.pdb - file not found
>> DBGHELP: c:\symbols\sys\OSEEntry.pdb - file not found
>> DBGHELP:
>> c:\sandbox\opensea\seakernel\ose\objchk_wnet_x86\i386\OSEEntry.pdb -
>> mismatched pdb
>> DBGHELP: Couldn’t load mismatched pdb for OSEEntry.sys
>> *** ERROR: Module load completed but symbols could not be loaded for
>> OSEEntry.sys
>> DBGHELP: OSEEntry - no symbols loaded
>>
>> The PDB file sits in the same path as the re-mapped SYS file, indeed has
>> the same date/time stamp.
>>
>> –
>> The personal opinion of
>> Gary G. Little
>>
>>
>
>

6

This stuff works fine for me, oops I forgot I stuck with 6.2.13!

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

“Gary G. Little” wrote in message news:xxxxx@windbg…
> Well, .kdfiles is useless, or I’m not using it correctly. The only way I
> can get symbols resolved is to manually copy a new SYS file to the
> >SystemRoot>\Drivers directory. And even doing that I often get this
> sequence when I set a breakpoint:
>
> 0: kd> bu OSEEntry!OSEEvtDevicePrepareHardware
> DBGHELP:
> C:\Symbols\Cache\OSEEntry.pdb\A2C2A32E51624F3180B0E1B261C308661\OSEEntry.pdb
> - mismatched pdb
> DBGHELP:
> c:\sandbox\opensea\seakernel\ose\objchk_wnet_x86\i386\OSEEntry.pdb -
> mismatched pdb
> DBGHELP: Couldn’t load mismatched pdb for OSEEntry.sys
> ERROR: Module load completed but symbols could not be loaded for
> OSEEntry.sys
> DBGHELP: OSEEntry - no symbols loaded
> Couldn’t resolve error at ‘OSEEntry!OSEEvtDevicePrepareHardware’
>
> By the way, I had manually created the proper directory’s in \Symbos and
> \Symbols\Cache and copied the pdb file to both of them. Still did not
> work.
>
> –
> The personal opinion of
> Gary G. Little
>
> “Gary G. Little” wrote in message news:…
>> Sheesh … talk about confusing …
>>
>> The temporary work around is to NOT use the symbol SERVER in the debug
>> symbol path. You can set it to the server, then do a !reload /f, then set
>> it back, as needed.
>>
>> –
>> The personal opinion of
>> Gary G. Little
>>
>> “Gary G. Little” wrote in message
>> news:xxxxx@windbg…
>>> Problems solved:
>>>
>>> Jason provided a lot of assistance in resolving the performance issues
>>> with the checked build. A temporary work around seems to be to NOT use
>>> the symbol in the path except when you REALLY want to update your
>>> symbols, but I will let him address that.
>>>
>>> Other problems found:
>>>
>>> It seems that when using .kdfiles to map to the SYS file to an
>>> alternate, the pdb will not automatically map as well. That really makes
>>> no sense, because I map the deriver file to the target file from the
>>> build, which is the same path to find the PDB as the SYS file in
>>> SystemRoot\Drivers. This means that it is a pain in the ass to change
>>> the SYS file because it entails booting to a clean OS that will not load
>>> your driver, typically Safe Mode, replace the SYS files, and then boot
>>> BACK to the test OS that will load your driver. I thought .kdfiles that
>>> if .kdfiles changed the path to the mapped path, that it would do the
>>> same for the pdb file, but from what I have seen thus far that is not
>>> the case.
>>>
>>> Case in point:
>>> After a rebuild, but before refreshing
>>> :\Windows\System32\Drivers\OSEEntry.sys
>>>
>>>
>>> 1: kd> .kdfiles
>>> KD file assocations loaded from ‘C:\Windows\Mapped.ini’
>>> SystemRoot\System32\Drivers\OSEEntry.sys ->
>>> C:\SandBox\OpenSea\SeaKernel\OSE\objchk_wnet_x86\i386\OSEEntry.sys
>>> 1: kd> bu OSEEntry!OSEEvtDevicePrepareHardware
>>> 1: kd> !reload
>>> Connected to Windows XP 2600 x86 compatible target, ptr64 FALSE
>>> SYMSRV:
>>> c:\Symbols\Cache\ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb
>>> not found
>>> SYMSRV: ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb not
>>> found
>>> DBGHELP:
>>> c:\symbols\ntkrnlmp.pdb\7DE39A3E89DA4B378B95A09FA3A6398C2\ntkrnlmp.pdb -
>>> mismatched pdb
>>> DBGHELP:
>>> c:\symbols\ntkrnlmp.pdb\AA1EE1B2A63A4232A379F3EFDDC4CFE82\ntkrnlmp.pdb -
>>> mismatched pdb
>>> DBGHELP: nt - public symbols
>>> c:\symbols\ntkrnlmp.pdb\ED2A609FD13241BFB1E849ABEE67AE3B1\ntkrnlmp.pdb
>>> Loading Kernel Symbols
>>> …
>>> Loading unloaded module list
>>> …
>>> Loading User Symbols
>>> …
>>> SYMSRV:
>>> c:\Symbols\Cache\OSEEntry.pdb\4E2ABB9D0C4B4AC0AAB1C0DE4A5CF91F1\OSEEntry.pdb
>>> not found
>>> SYMSRV: OSEEntry.pdb\4E2ABB9D0C4B4AC0AAB1C0DE4A5CF91F1\OSEEntry.pdb not
>>> found
>>> DBGHELP: c:\symbols\OSEEntry.pdb - file not found
>>> DBGHELP: c:\symbols\symbols\sys\OSEEntry.pdb - file not found
>>> DBGHELP: c:\symbols\sys\OSEEntry.pdb - file not found
>>> DBGHELP:
>>> c:\sandbox\opensea\seakernel\ose\objchk_wnet_x86\i386\OSEEntry.pdb -
>>> mismatched pdb
>>> DBGHELP: Couldn’t load mismatched pdb for OSEEntry.sys
>>> ERROR: Module load completed but symbols could not be loaded for
>>> OSEEntry.sys
>>> DBGHELP: OSEEntry - no symbols loaded
>>>
>>> The PDB file sits in the same path as the re-mapped SYS file, indeed has
>>> the same date/time stamp.
>>>
>>> –
>>> The personal opinion of
>>> Gary G. Little
>>>
>>>
>>
>>
>
>
>