Windbg locking driver .pdb file

WINDBG
1

Hi,
everytime I need to recompile I’ve to close WinDBG because it locks the driver .pdb file,
Is there anything I could do to avoid this?

I found 1 or 2 posts related to this problem on the lists but no detailed explanation,
Posted by Roddy, Mark:
“I setup my development builds and my debugger so that the target
directory is NOT where I point windbg at to find the symbols for test
drivers/exes. That way the worst case is that windbg is looking at the
wrong symbols and not that I can’t build because the pdb file is locked.
I just have to remember to refresh the test directory as well as the
target system. That is error prone of course, but I’ve taken care of
that for all but boot drivers by using a map file.”

From what I know the driver shall have the .pdb location (somewhere in Debugging DataDirectory?)
so Mark meant he changes this location? or simply the location of the .pdb?

Thanks in advance!

Jean F.

2

Do you have a set of steps that we can try to consistently repro the
behavior. We’ve been getting complaints of this, but have never seen it
under a debugger.

Alternatively, if you turn on handle tracing, attach a debugger to the
debugger when its in the state, and take a full dump (.dump /ma) for us
to check out, we may be able to get something from it. Feel free to
contact xxxxx@microsoft.com if this is the route you want to take.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Thursday, September 08, 2005 5:44 PM
To: Kernel Debugging Interest List
Subject: [windbg] Windbg locking driver .pdb file

Hi,
everytime I need to recompile I’ve to close WinDBG because it locks the
driver .pdb file,
Is there anything I could do to avoid this?

I found 1 or 2 posts related to this problem on the lists but no
detailed explanation,
Posted by Roddy, Mark:
“I setup my development builds and my debugger so that the target
directory is NOT where I point windbg at to find the symbols for test
drivers/exes. That way the worst case is that windbg is looking at the
wrong symbols and not that I can’t build because the pdb file is locked.
I just have to remember to refresh the test directory as well as the
target system. That is error prone of course, but I’ve taken care of
that for all but boot drivers by using a map file.”

From what I know the driver shall have the .pdb location (somewhere in
Debugging DataDirectory?)
so Mark meant he changes this location? or simply the location of the
.pdb?

Thanks in advance!

Jean F.

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

3

When that happens

.reload /u

works for me most often.

4

Jason,
I’ve tried to attach WinDbg_B to WinDbg_A (which is debugging the driver and locking the .pdb),
however WinDbg_B gave an error (maybe I was attaching to the wrong WinDbg).

Then I tried ProcessExplorer (from SysInternals) to have a look at used windbg handles,
and there is one handle pointing to the driver pdb, access value is 0x00120089.
The security flags (handle properties dialog) look good since it allows Delete, Synchronize,
QueryState, ModifyState and SpecialPermissions to everyone user.

I closed WinDbg_A and reopenned it trough WinDbg_B (“Open executable…”) all ok, enabled handle
tracing, done some debugging on the driver, !htrace -diff and with the help of ProcessExplorer
found which was the handle pointing to the driver pdb:
(…)
Handle = 0x00000764 - OPEN
Thread ID = 0x00000FE8, Process ID = 0x00000CC4

0x030CCFEF: dbghelp!MiniDumpReadDumpStream+0x0007713F
0x030CE393: dbghelp!MiniDumpReadDumpStream+0x000784E3
0x030CE484: dbghelp!MiniDumpReadDumpStream+0x000785D4
0x030BE0C6: dbghelp!MiniDumpReadDumpStream+0x00068216
0x030BE5B9: dbghelp!MiniDumpReadDumpStream+0x00068709
0x03083610: dbghelp!MiniDumpReadDumpStream+0x0002D760
0x03017A84: dbghelp+0x00017A84
0x03018531: dbghelp+0x00018531

(…)
0:002> !handle 0x764 ff
Handle 764
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 4
No Object Specific Information available

(Note: I wasnt able to get an handle object, or that handle “name” from WinDbg, just from ProcessExplorer).

So I assume its due to how the .pdb file is openned, restricts how it can be accessed.
Shall windbg allow to delete\write on the .pdb file while debugging the driver or… we must unload
the symbols from the driver before compile?

Satya Das,
good hint, looks like WinDbg closes the pdb handle with that command, as expected.

Thanks both for replies,
Jean F.

“Jason Shay” wrote in message news:xxxxx@windbg…
Do you have a set of steps that we can try to consistently repro the
behavior. We’ve been getting complaints of this, but have never seen it
under a debugger.

Alternatively, if you turn on handle tracing, attach a debugger to the
debugger when its in the state, and take a full dump (.dump /ma) for us
to check out, we may be able to get something from it. Feel free to
contact xxxxx@microsoft.com if this is the route you want to take.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Thursday, September 08, 2005 5:44 PM
To: Kernel Debugging Interest List
Subject: [windbg] Windbg locking driver .pdb file

Hi,
everytime I need to recompile I’ve to close WinDBG because it locks the
driver .pdb file,
Is there anything I could do to avoid this?

I found 1 or 2 posts related to this problem on the lists but no
detailed explanation,
Posted by Roddy, Mark:
“I setup my development builds and my debugger so that the target
directory is NOT where I point windbg at to find the symbols for test
drivers/exes. That way the worst case is that windbg is looking at the
wrong symbols and not that I can’t build because the pdb file is locked.
I just have to remember to refresh the test directory as well as the
target system. That is error prone of course, but I’ve taken care of
that for all but boot drivers by using a map file.”

From what I know the driver shall have the .pdb location (somewhere in
Debugging DataDirectory?)
so Mark meant he changes this location? or simply the location of the
.pdb?

Thanks in advance!

Jean F.

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

5

Have you tried the following to unlock or unload your driver symbols
.reload /u <driver_name.sys>

-Pramod.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Friday, September 09, 2005 1:42 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Windbg locking driver .pdb file

Jason,
I’ve tried to attach WinDbg_B to WinDbg_A (which is debugging the driver
and locking the .pdb), however WinDbg_B gave an error (maybe I was
attaching to the wrong WinDbg).

Then I tried ProcessExplorer (from SysInternals) to have a look at used
windbg handles, and there is one handle pointing to the driver pdb,
access value is 0x00120089. The security flags (handle properties
dialog) look good since it allows Delete, Synchronize, QueryState,
ModifyState and SpecialPermissions to everyone user.

I closed WinDbg_A and reopenned it trough WinDbg_B (“Open
executable…”) all ok, enabled handle tracing, done some debugging on
the driver, !htrace -diff and with the help of ProcessExplorer found
which was the handle pointing to the driver pdb:
(…)
Handle = 0x00000764 - OPEN
Thread ID = 0x00000FE8, Process ID = 0x00000CC4

0x030CCFEF: dbghelp!MiniDumpReadDumpStream+0x0007713F
0x030CE393: dbghelp!MiniDumpReadDumpStream+0x000784E3
0x030CE484: dbghelp!MiniDumpReadDumpStream+0x000785D4
0x030BE0C6: dbghelp!MiniDumpReadDumpStream+0x00068216
0x030BE5B9: dbghelp!MiniDumpReadDumpStream+0x00068709
0x03083610: dbghelp!MiniDumpReadDumpStream+0x0002D760
0x03017A84: dbghelp+0x00017A84
0x03018531: dbghelp+0x00018531
---------
(…)
0:002> !handle 0x764 ff
Handle 764
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 4
No Object Specific Information available

(Note: I wasnt able to get an handle object, or that handle “name” from
WinDbg, just from ProcessExplorer).

So I assume its due to how the .pdb file is openned, restricts how it
can be accessed. Shall windbg allow to delete\write on the .pdb file
while debugging the driver or… we must unload the symbols from the
driver before compile?

—
Satya Das,
good hint, looks like WinDbg closes the pdb handle with that command, as
expected.

Thanks both for replies,
Jean F.

------------------------------------------------------------------------
-------------------
“Jason Shay” wrote in message
news:xxxxx@windbg… Do you have a set of steps that we can try to
consistently repro the behavior. We’ve been getting complaints of this,
but have never seen it under a debugger.

Alternatively, if you turn on handle tracing, attach a debugger to the
debugger when its in the state, and take a full dump (.dump /ma) for us
to check out, we may be able to get something from it. Feel free to
contact xxxxx@microsoft.com if this is the route you want to take.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Thursday, September 08, 2005 5:44 PM
To: Kernel Debugging Interest List
Subject: [windbg] Windbg locking driver .pdb file

Hi,
everytime I need to recompile I’ve to close WinDBG because it locks the
driver .pdb file, Is there anything I could do to avoid this?

I found 1 or 2 posts related to this problem on the lists but no
detailed explanation, Posted by Roddy, Mark: “I setup my development
builds and my debugger so that the target directory is NOT where I point
windbg at to find the symbols for test drivers/exes. That way the worst
case is that windbg is looking at the wrong symbols and not that I can’t
build because the pdb file is locked. I just have to remember to refresh
the test directory as well as the target system. That is error prone of
course, but I’ve taken care of that for all but boot drivers by using a
map file.”

From what I know the driver shall have the .pdb location (somewhere in
Debugging DataDirectory?) so Mark meant he changes this location? or
simply the location of the .pdb?

Thanks in advance!

Jean F.

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

—
You are currently subscribed to windbg as: pramod.paranjape@ca.com To
unsubscribe send a blank email to xxxxx@lists.osr.com</driver_name.sys>

6

That has not worked for me on 6.4/6.5. The reload trick works on 6.3
however.

–
The personal opinion of
Gary G. Little

“Satya Das” wrote in message news:xxxxx@windbg…
When that happens

.reload /u

works for me most often.

7

Stop all of the device instances that are using the driver. The debug
target will then unload the driver, WinDbg will notice this and will release
the PDB file. You usually need to do this anyway when you are loading your
new driver code, so it’s a fairly natural work flow.

– arlie

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Thursday, September 08, 2005 8:44 PM
To: Kernel Debugging Interest List
Subject: [windbg] Windbg locking driver .pdb file

Hi,
everytime I need to recompile I’ve to close WinDBG because it locks the
driver .pdb file, Is there anything I could do to avoid this?

I found 1 or 2 posts related to this problem on the lists but no detailed
explanation, Posted by Roddy, Mark:
“I setup my development builds and my debugger so that the target directory
is NOT where I point windbg at to find the symbols for test drivers/exes.
That way the worst case is that windbg is looking at the wrong symbols and
not that I can’t build because the pdb file is locked.
I just have to remember to refresh the test directory as well as the target
system. That is error prone of course, but I’ve taken care of that for all
but boot drivers by using a map file.”

From what I know the driver shall have the .pdb location (somewhere in
Debugging DataDirectory?) so Mark meant he changes this location? or simply
the location of the .pdb?

Thanks in advance!

Jean F.

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

8

>> Satya Das,

> good hint, looks like WinDbg closes the pdb handle with that command,
as >> expected.

Ahh – I didn’t realize that your target system hadn’t actually unloaded
the driver yet.

Well to anyone else listening, if you get into a situation with WinDbg
6.5 where:

  • Your driver is unloaded
  • Your driver is not listed in the module list under ‘lm’, unless under
    the unloaded module section
  • Your PDB file remains locked

Then we’re interested in debugging this situation, and appreciate any
help you can provide. We’re also interested in cases where ‘.reload /u’
does not work.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Friday, September 09, 2005 5:42 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Windbg locking driver .pdb file

Jason,
I’ve tried to attach WinDbg_B to WinDbg_A (which is debugging the driver
and locking the .pdb),
however WinDbg_B gave an error (maybe I was attaching to the wrong
WinDbg).

Then I tried ProcessExplorer (from SysInternals) to have a look at used
windbg handles,
and there is one handle pointing to the driver pdb, access value is
0x00120089.
The security flags (handle properties dialog) look good since it allows
Delete, Synchronize,
QueryState, ModifyState and SpecialPermissions to everyone user.

I closed WinDbg_A and reopenned it trough WinDbg_B (“Open
executable…”) all ok, enabled handle
tracing, done some debugging on the driver, !htrace -diff and with the
help of ProcessExplorer
found which was the handle pointing to the driver pdb:
(…)
Handle = 0x00000764 - OPEN
Thread ID = 0x00000FE8, Process ID = 0x00000CC4

0x030CCFEF: dbghelp!MiniDumpReadDumpStream+0x0007713F
0x030CE393: dbghelp!MiniDumpReadDumpStream+0x000784E3
0x030CE484: dbghelp!MiniDumpReadDumpStream+0x000785D4
0x030BE0C6: dbghelp!MiniDumpReadDumpStream+0x00068216
0x030BE5B9: dbghelp!MiniDumpReadDumpStream+0x00068709
0x03083610: dbghelp!MiniDumpReadDumpStream+0x0002D760
0x03017A84: dbghelp+0x00017A84
0x03018531: dbghelp+0x00018531

(…)
0:002> !handle 0x764 ff
Handle 764
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 4
No Object Specific Information available

(Note: I wasnt able to get an handle object, or that handle “name” from
WinDbg, just from ProcessExplorer).

So I assume its due to how the .pdb file is openned, restricts how it
can be accessed.
Shall windbg allow to delete\write on the .pdb file while debugging the
driver or… we must unload
the symbols from the driver before compile?

Satya Das,
good hint, looks like WinDbg closes the pdb handle with that command, as
expected.

Thanks both for replies,
Jean F.

“Jason Shay” wrote in message
news:xxxxx@windbg…
Do you have a set of steps that we can try to consistently repro the
behavior. We’ve been getting complaints of this, but have never seen it
under a debugger.

Alternatively, if you turn on handle tracing, attach a debugger to the
debugger when its in the state, and take a full dump (.dump /ma) for us
to check out, we may be able to get something from it. Feel free to
contact xxxxx@microsoft.com if this is the route you want to take.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Thursday, September 08, 2005 5:44 PM
To: Kernel Debugging Interest List
Subject: [windbg] Windbg locking driver .pdb file

Hi,
everytime I need to recompile I’ve to close WinDBG because it locks the
driver .pdb file,
Is there anything I could do to avoid this?

I found 1 or 2 posts related to this problem on the lists but no
detailed explanation,
Posted by Roddy, Mark:
“I setup my development builds and my debugger so that the target
directory is NOT where I point windbg at to find the symbols for test
drivers/exes. That way the worst case is that windbg is looking at the
wrong symbols and not that I can’t build because the pdb file is locked.
I just have to remember to refresh the test directory as well as the
target system. That is error prone of course, but I’ve taken care of
that for all but boot drivers by using a map file.”

From what I know the driver shall have the .pdb location (somewhere in
Debugging DataDirectory?)
so Mark meant he changes this location? or simply the location of the
.pdb?

Thanks in advance!

Jean F.

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

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

9

Arlie Davis wrote:

Stop all of the device instances that are using the driver. The debug
target will then unload the driver, WinDbg will notice this and will release
the PDB file. You usually need to do this anyway when you are loading your
new driver code, so it’s a fairly natural work flow.

I’m not so sure it’s natural. My usual work flow is “debug, find
problem, edit code, recompile, copy to target, devcon restart driver”.
That fails, because the recompile fails, because the PDB is still open.
A .reload fixes it, although it’s sometimes quicker just to reboot…

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

10

You can also move the file while windbg is using it. Moving the file
out of the way will allow you to recompile. This is ok for one or two
build cycles, but it gets tedious quickly.

I found it took quite a bit of experimenting with my workflow before
I got to a point where I wasn’t fighting with windbg, particularly
with the PDB issue.

On 9-Sep-05, at 10:17 AM, Tim Roberts wrote:

Arlie Davis wrote:

> Stop all of the device instances that are using the driver. The
> debug
> target will then unload the driver, WinDbg will notice this and
> will release
> the PDB file. You usually need to do this anyway when you are
> loading your
> new driver code, so it’s a fairly natural work flow.
>
>

I’m not so sure it’s natural. My usual work flow is “debug, find
problem, edit code, recompile, copy to target, devcon restart
driver”. That fails, because the recompile fails, because the PDB
is still open. A .reload fixes it, although it’s sometimes quicker
just to reboot…

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

11

I use a symbol server just for intermediate builds, and
as a part of my build, add my symbols to the server.
I use ddkbuild.bat and I’ve just added the following call in
after the build command:

“C:\Program Files\Debugging Tools for Windows 64-bit\symstore”
add /s e:\SymServer /f . /r /t “IntermediateBuildSymbols”

Then, WinDBG locks the files in e:\symserver, not the files in
my build environment. Since the symstore add copies new files
into the symbol server, the fact that the old files are locked
doesn’t matter.

I periodically (like every month or so) just delete everything in
e:\symserver and start over.

Works great… one day I’ll get the source server stuff
integrated and happening automatically too… but since I
am generally just debugging the current build, it doesn’t
really matter, except on the rare occasions where I’ve a
test build out to someone.

Thanks,

Joseph

Cliff Russell wrote:

You can also move the file while windbg is using it. Moving the file out
of the way will allow you to recompile. This is ok for one or two build
cycles, but it gets tedious quickly.

I found it took quite a bit of experimenting with my workflow before I
got to a point where I wasn’t fighting with windbg, particularly with
the PDB issue.

On 9-Sep-05, at 10:17 AM, Tim Roberts wrote:

> Arlie Davis wrote:
>
>
>> Stop all of the device instances that are using the driver. The debug
>> target will then unload the driver, WinDbg will notice this and will
>> release
>> the PDB file. You usually need to do this anyway when you are
>> loading your
>> new driver code, so it’s a fairly natural work flow.
>>
>>
>
> I’m not so sure it’s natural. My usual work flow is “debug, find
> problem, edit code, recompile, copy to target, devcon restart
> driver”. That fails, because the recompile fails, because the PDB is
> still open. A .reload fixes it, although it’s sometimes quicker just
> to reboot…
>
> --Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> You are currently subscribed to windbg as: xxxxx@telus.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

12

Note that there is a tool in the debugger package called agestore, which
can age of the symbols which you haven’t accessed recently. Sometimes
more convenient than deleting the whole thing.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Friday, September 09, 2005 12:00 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Windbg locking driver .pdb file

I use a symbol server just for intermediate builds, and
as a part of my build, add my symbols to the server.
I use ddkbuild.bat and I’ve just added the following call in
after the build command:

“C:\Program Files\Debugging Tools for Windows 64-bit\symstore”
add /s e:\SymServer /f . /r /t “IntermediateBuildSymbols”

Then, WinDBG locks the files in e:\symserver, not the files in
my build environment. Since the symstore add copies new files
into the symbol server, the fact that the old files are locked
doesn’t matter.

I periodically (like every month or so) just delete everything in
e:\symserver and start over.

Works great… one day I’ll get the source server stuff
integrated and happening automatically too… but since I
am generally just debugging the current build, it doesn’t
really matter, except on the rare occasions where I’ve a
test build out to someone.

Thanks,

Joseph

Cliff Russell wrote:

You can also move the file while windbg is using it. Moving the file
out
of the way will allow you to recompile. This is ok for one or two
build
cycles, but it gets tedious quickly.

I found it took quite a bit of experimenting with my workflow before I

got to a point where I wasn’t fighting with windbg, particularly with
the PDB issue.

On 9-Sep-05, at 10:17 AM, Tim Roberts wrote:

> Arlie Davis wrote:
>
>
>> Stop all of the device instances that are using the driver. The
debug
>> target will then unload the driver, WinDbg will notice this and will

>> release
>> the PDB file. You usually need to do this anyway when you are
>> loading your
>> new driver code, so it’s a fairly natural work flow.
>>
>>
>
> I’m not so sure it’s natural. My usual work flow is “debug, find
> problem, edit code, recompile, copy to target, devcon restart
> driver”. That fails, because the recompile fails, because the PDB is

> still open. A .reload fixes it, although it’s sometimes quicker just

> to reboot…
>
> --Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> You are currently subscribed to windbg as: xxxxx@telus.net
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>

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

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

13

Looks like the .reload /u module not always works,

  1. The driver is unloaded

lm
(…)
Unloaded modules:
f7378000 f737f000 driver.sys
be4fb000 be509000 swmidi.sys
be197000 be1bc000 kmixer.sys
(…)

  1. ProcessExplorer tells me that WinDbg owns an handle pointing to the pdb.
    Attached a WinDbg to this WinDbg_A , !handle 0x2ec gives:

Handle 2ec
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 3
No Object Specific Information available

(However ProcessExplorer says its 1 handle and 1 reference, who knows?)

.reload /u driver doesnt work because the driver isnt on lm list:

kd> .reload /u driver
Unable to find module ‘driver’
(same with driver.sys)

I done a .reload /s after that, only ntoskrnl.pdb and my driver.pdb were still being used by WinDbg,
at first sight looks that WinDbg or DBGHELP is forgetting to close the driver pdb handle.

“Jason Shay” wrote in message news:xxxxx@windbg…
>> Satya Das,
>> good hint, looks like WinDbg closes the pdb handle with that command,
as >> expected.

Ahh – I didn’t realize that your target system hadn’t actually unloaded
the driver yet.

Well to anyone else listening, if you get into a situation with WinDbg
6.5 where:
- Your driver is unloaded
- Your driver is not listed in the module list under ‘lm’, unless under
the unloaded module section
- Your PDB file remains locked

Then we’re interested in debugging this situation, and appreciate any
help you can provide. We’re also interested in cases where ‘.reload /u’
does not work.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Friday, September 09, 2005 5:42 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Windbg locking driver .pdb file

Jason,
I’ve tried to attach WinDbg_B to WinDbg_A (which is debugging the driver
and locking the .pdb),
however WinDbg_B gave an error (maybe I was attaching to the wrong
WinDbg).

Then I tried ProcessExplorer (from SysInternals) to have a look at used
windbg handles,
and there is one handle pointing to the driver pdb, access value is
0x00120089.
The security flags (handle properties dialog) look good since it allows
Delete, Synchronize,
QueryState, ModifyState and SpecialPermissions to everyone user.

I closed WinDbg_A and reopenned it trough WinDbg_B (“Open
executable…”) all ok, enabled handle
tracing, done some debugging on the driver, !htrace -diff and with the
help of ProcessExplorer
found which was the handle pointing to the driver pdb:
(…)
Handle = 0x00000764 - OPEN
Thread ID = 0x00000FE8, Process ID = 0x00000CC4

0x030CCFEF: dbghelp!MiniDumpReadDumpStream+0x0007713F
0x030CE393: dbghelp!MiniDumpReadDumpStream+0x000784E3
0x030CE484: dbghelp!MiniDumpReadDumpStream+0x000785D4
0x030BE0C6: dbghelp!MiniDumpReadDumpStream+0x00068216
0x030BE5B9: dbghelp!MiniDumpReadDumpStream+0x00068709
0x03083610: dbghelp!MiniDumpReadDumpStream+0x0002D760
0x03017A84: dbghelp+0x00017A84
0x03018531: dbghelp+0x00018531
---------
(…)
0:002> !handle 0x764 ff
Handle 764
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 4
No Object Specific Information available

(Note: I wasnt able to get an handle object, or that handle “name” from
WinDbg, just from ProcessExplorer).

So I assume its due to how the .pdb file is openned, restricts how it
can be accessed.
Shall windbg allow to delete\write on the .pdb file while debugging the
driver or… we must unload
the symbols from the driver before compile?

—
Satya Das,
good hint, looks like WinDbg closes the pdb handle with that command, as
expected.

Thanks both for replies,
Jean F.

------------------------------------------------------------------------
-------------------
“Jason Shay” wrote in message
news:xxxxx@windbg…
Do you have a set of steps that we can try to consistently repro the
behavior. We’ve been getting complaints of this, but have never seen it
under a debugger.

Alternatively, if you turn on handle tracing, attach a debugger to the
debugger when its in the state, and take a full dump (.dump /ma) for us
to check out, we may be able to get something from it. Feel free to
contact xxxxx@microsoft.com if this is the route you want to take.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Thursday, September 08, 2005 5:44 PM
To: Kernel Debugging Interest List
Subject: [windbg] Windbg locking driver .pdb file

Hi,
everytime I need to recompile I’ve to close WinDBG because it locks the
driver .pdb file,
Is there anything I could do to avoid this?

I found 1 or 2 posts related to this problem on the lists but no
detailed explanation,
Posted by Roddy, Mark:
“I setup my development builds and my debugger so that the target
directory is NOT where I point windbg at to find the symbols for test
drivers/exes. That way the worst case is that windbg is looking at the
wrong symbols and not that I can’t build because the pdb file is locked.
I just have to remember to refresh the test directory as well as the
target system. That is error prone of course, but I’ve taken care of
that for all but boot drivers by using a map file.”

From what I know the driver shall have the .pdb location (somewhere in
Debugging DataDirectory?)
so Mark meant he changes this location? or simply the location of the
.pdb?

Thanks in advance!

Jean F.

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

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

14

I have seen that happen in 6.5 more often than 6.4. I have stopped using
6.5 for some time now.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Friday, September 09, 2005 1:50 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Windbg locking driver .pdb file

Looks like the .reload /u module not always works,

  1. The driver is unloaded
15

I just tried again and my *trivial* repro didn’t cause problems.

Can you enable handle tracing for WinDbg, and when you attach WinDbg to
WinDbg_A, create a full dump (.dump /ma).

Send mail to xxxxx@microsoft.com and we’ll look into how to get the
dump file to us. This would be much appreciated.

Thanks,
Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Friday, September 09, 2005 1:50 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Windbg locking driver .pdb file

Looks like the .reload /u module not always works,

  1. The driver is unloaded

lm
(…)
Unloaded modules:
f7378000 f737f000 driver.sys
be4fb000 be509000 swmidi.sys
be197000 be1bc000 kmixer.sys
(…)

  1. ProcessExplorer tells me that WinDbg owns an handle pointing to the
    pdb.
    Attached a WinDbg to this WinDbg_A , !handle 0x2ec gives:

Handle 2ec
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 3
No Object Specific Information available

(However ProcessExplorer says its 1 handle and 1 reference, who knows?)

.reload /u driver doesnt work because the driver isnt on lm list:

kd> .reload /u driver
Unable to find module ‘driver’
(same with driver.sys)

I done a .reload /s after that, only ntoskrnl.pdb and my driver.pdb were
still being used by WinDbg,
at first sight looks that WinDbg or DBGHELP is forgetting to close the
driver pdb handle.

“Jason Shay” wrote in message
news:xxxxx@windbg…
>> Satya Das,
>> good hint, looks like WinDbg closes the pdb handle with that command,
as >> expected.

Ahh – I didn’t realize that your target system hadn’t actually unloaded
the driver yet.

Well to anyone else listening, if you get into a situation with WinDbg
6.5 where:
- Your driver is unloaded
- Your driver is not listed in the module list under ‘lm’, unless under
the unloaded module section
- Your PDB file remains locked

Then we’re interested in debugging this situation, and appreciate any
help you can provide. We’re also interested in cases where ‘.reload /u’
does not work.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Friday, September 09, 2005 5:42 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Windbg locking driver .pdb file

Jason,
I’ve tried to attach WinDbg_B to WinDbg_A (which is debugging the driver
and locking the .pdb),
however WinDbg_B gave an error (maybe I was attaching to the wrong
WinDbg).

Then I tried ProcessExplorer (from SysInternals) to have a look at used
windbg handles,
and there is one handle pointing to the driver pdb, access value is
0x00120089.
The security flags (handle properties dialog) look good since it allows
Delete, Synchronize,
QueryState, ModifyState and SpecialPermissions to everyone user.

I closed WinDbg_A and reopenned it trough WinDbg_B (“Open
executable…”) all ok, enabled handle
tracing, done some debugging on the driver, !htrace -diff and with the
help of ProcessExplorer
found which was the handle pointing to the driver pdb:
(…)
Handle = 0x00000764 - OPEN
Thread ID = 0x00000FE8, Process ID = 0x00000CC4

0x030CCFEF: dbghelp!MiniDumpReadDumpStream+0x0007713F
0x030CE393: dbghelp!MiniDumpReadDumpStream+0x000784E3
0x030CE484: dbghelp!MiniDumpReadDumpStream+0x000785D4
0x030BE0C6: dbghelp!MiniDumpReadDumpStream+0x00068216
0x030BE5B9: dbghelp!MiniDumpReadDumpStream+0x00068709
0x03083610: dbghelp!MiniDumpReadDumpStream+0x0002D760
0x03017A84: dbghelp+0x00017A84
0x03018531: dbghelp+0x00018531
---------
(…)
0:002> !handle 0x764 ff
Handle 764
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 4
No Object Specific Information available

(Note: I wasnt able to get an handle object, or that handle “name” from
WinDbg, just from ProcessExplorer).

So I assume its due to how the .pdb file is openned, restricts how it
can be accessed.
Shall windbg allow to delete\write on the .pdb file while debugging the
driver or… we must unload
the symbols from the driver before compile?

—
Satya Das,
good hint, looks like WinDbg closes the pdb handle with that command, as
expected.

Thanks both for replies,
Jean F.

------------------------------------------------------------------------
-------------------
“Jason Shay” wrote in message
news:xxxxx@windbg…
Do you have a set of steps that we can try to consistently repro the
behavior. We’ve been getting complaints of this, but have never seen it
under a debugger.

Alternatively, if you turn on handle tracing, attach a debugger to the
debugger when its in the state, and take a full dump (.dump /ma) for us
to check out, we may be able to get something from it. Feel free to
contact xxxxx@microsoft.com if this is the route you want to take.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Thursday, September 08, 2005 5:44 PM
To: Kernel Debugging Interest List
Subject: [windbg] Windbg locking driver .pdb file

Hi,
everytime I need to recompile I’ve to close WinDBG because it locks the
driver .pdb file,
Is there anything I could do to avoid this?

I found 1 or 2 posts related to this problem on the lists but no
detailed explanation,
Posted by Roddy, Mark:
“I setup my development builds and my debugger so that the target
directory is NOT where I point windbg at to find the symbols for test
drivers/exes. That way the worst case is that windbg is looking at the
wrong symbols and not that I can’t build because the pdb file is locked.
I just have to remember to refresh the test directory as well as the
target system. That is error prone of course, but I’ve taken care of
that for all but boot drivers by using a map file.”

From what I know the driver shall have the .pdb location (somewhere in
Debugging DataDirectory?)
so Mark meant he changes this location? or simply the location of the
.pdb?

Thanks in advance!

Jean F.

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

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

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

16

I also have noticed it quite a bit in 6.5, including in cases where the
driver itself has unloaded and the target rebooted. For me, at least,
it appears to be a state that, once entered, continues to perpetuate
itself. If I exit the debugger and restart the problem will “go away”.
In the interim I usually just rename the PDB file and then insert the
new one for the rebuilt driver.

The most disturbing issue I’ve run across is when I received “lost
delayed write data” errors from my PDB file (it was stored on a network
drive) because it suggests that the file was modified…

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Looking forward to seeing you at the next OSR File Systems class in Los
Angeles, CA October 24-27, 2005.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Satya Das
Sent: Friday, September 09, 2005 5:14 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Windbg locking driver .pdb file

I have seen that happen in 6.5 more often than 6.4. I have stopped using
6.5 for some time now.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Friday, September 09, 2005 1:50 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Windbg locking driver .pdb file

Looks like the .reload /u module not always works,

  1. The driver is unloaded

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

17

I’m sorry for my “ignorance” I didnt understood in your first post the
meaning of “repro” word.

I’ll send a mail to the address given by you, explaining the steps
I’ve done to build the dump and to repro the problem.

Right, the dump should be around 50Mb, thats quite a bit to exchange trough mails.

I also noticed an exception occured in the thread associated with the pdb handle.

Thanks for the replies,
Jean F.

“Jason Shay” wrote in message news:xxxxx@windbg…
I just tried again and my trivial repro didn’t cause problems.

Can you enable handle tracing for WinDbg, and when you attach WinDbg to
WinDbg_A, create a full dump (.dump /ma).

Send mail to xxxxx@microsoft.com and we’ll look into how to get the
dump file to us. This would be much appreciated.

Thanks,
Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Friday, September 09, 2005 1:50 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Windbg locking driver .pdb file

Looks like the .reload /u module not always works,

1) The driver is unloaded

2)
> lm
(…)
Unloaded modules:
f7378000 f737f000 driver.sys
be4fb000 be509000 swmidi.sys
be197000 be1bc000 kmixer.sys
(…)

3) ProcessExplorer tells me that WinDbg owns an handle pointing to the
pdb.
Attached a WinDbg to this WinDbg_A , !handle 0x2ec gives:

Handle 2ec
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 3
No Object Specific Information available

(However ProcessExplorer says its 1 handle and 1 reference, who knows?)

.reload /u driver doesnt work because the driver isnt on lm list:

kd> .reload /u driver
Unable to find module ‘driver’
(same with driver.sys)

I done a .reload /s after that, only ntoskrnl.pdb and my driver.pdb were
still being used by WinDbg,
at first sight looks that WinDbg or DBGHELP is forgetting to close the
driver pdb handle.

—
“Jason Shay” wrote in message
news:xxxxx@windbg…
>> Satya Das,
>> good hint, looks like WinDbg closes the pdb handle with that command,
as >> expected.

Ahh – I didn’t realize that your target system hadn’t actually unloaded
the driver yet.

Well to anyone else listening, if you get into a situation with WinDbg
6.5 where:
- Your driver is unloaded
- Your driver is not listed in the module list under ‘lm’, unless under
the unloaded module section
- Your PDB file remains locked

Then we’re interested in debugging this situation, and appreciate any
help you can provide. We’re also interested in cases where ‘.reload /u’
does not work.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Friday, September 09, 2005 5:42 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Windbg locking driver .pdb file

Jason,
I’ve tried to attach WinDbg_B to WinDbg_A (which is debugging the driver
and locking the .pdb),
however WinDbg_B gave an error (maybe I was attaching to the wrong
WinDbg).

Then I tried ProcessExplorer (from SysInternals) to have a look at used
windbg handles,
and there is one handle pointing to the driver pdb, access value is
0x00120089.
The security flags (handle properties dialog) look good since it allows
Delete, Synchronize,
QueryState, ModifyState and SpecialPermissions to everyone user.

I closed WinDbg_A and reopenned it trough WinDbg_B (“Open
executable…”) all ok, enabled handle
tracing, done some debugging on the driver, !htrace -diff and with the
help of ProcessExplorer
found which was the handle pointing to the driver pdb:
(…)
Handle = 0x00000764 - OPEN
Thread ID = 0x00000FE8, Process ID = 0x00000CC4

0x030CCFEF: dbghelp!MiniDumpReadDumpStream+0x0007713F
0x030CE393: dbghelp!MiniDumpReadDumpStream+0x000784E3
0x030CE484: dbghelp!MiniDumpReadDumpStream+0x000785D4
0x030BE0C6: dbghelp!MiniDumpReadDumpStream+0x00068216
0x030BE5B9: dbghelp!MiniDumpReadDumpStream+0x00068709
0x03083610: dbghelp!MiniDumpReadDumpStream+0x0002D760
0x03017A84: dbghelp+0x00017A84
0x03018531: dbghelp+0x00018531
---------
(…)
0:002> !handle 0x764 ff
Handle 764
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 4
No Object Specific Information available

(Note: I wasnt able to get an handle object, or that handle “name” from
WinDbg, just from ProcessExplorer).

So I assume its due to how the .pdb file is openned, restricts how it
can be accessed.
Shall windbg allow to delete\write on the .pdb file while debugging the
driver or… we must unload
the symbols from the driver before compile?

—
Satya Das,
good hint, looks like WinDbg closes the pdb handle with that command, as
expected.

Thanks both for replies,
Jean F.

------------------------------------------------------------------------
-------------------
“Jason Shay” wrote in message
news:xxxxx@windbg…
Do you have a set of steps that we can try to consistently repro the
behavior. We’ve been getting complaints of this, but have never seen it
under a debugger.

Alternatively, if you turn on handle tracing, attach a debugger to the
debugger when its in the state, and take a full dump (.dump /ma) for us
to check out, we may be able to get something from it. Feel free to
contact xxxxx@microsoft.com if this is the route you want to take.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jean F.
Sent: Thursday, September 08, 2005 5:44 PM
To: Kernel Debugging Interest List
Subject: [windbg] Windbg locking driver .pdb file

Hi,
everytime I need to recompile I’ve to close WinDBG because it locks the
driver .pdb file,
Is there anything I could do to avoid this?

I found 1 or 2 posts related to this problem on the lists but no
detailed explanation,
Posted by Roddy, Mark:
“I setup my development builds and my debugger so that the target
directory is NOT where I point windbg at to find the symbols for test
drivers/exes. That way the worst case is that windbg is looking at the
wrong symbols and not that I can’t build because the pdb file is locked.
I just have to remember to refresh the test directory as well as the
target system. That is error prone of course, but I’ve taken care of
that for all but boot drivers by using a map file.”

From what I know the driver shall have the .pdb location (somewhere in
Debugging DataDirectory?)
so Mark meant he changes this location? or simply the location of the
.pdb?

Thanks in advance!

Jean F.

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

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

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

18

“If I exit the debugger and restart the problem will “go away”.”

Indeed, also happens with me, sometimes.
I guess if the problem isnt solved I’ll try stick with the symbol server idea,
didnt knew about symstore.

Jean F.

19

Jason,

You are just chock full of good information. I think Monday I’ll re-install
6.5, and use the symbol server trick

–
Gary G. Little
“Jason Shay” wrote in message
news:xxxxx@windbg…
Note that there is a tool in the debugger package called agestore, which
can age of the symbols which you haven’t accessed recently. Sometimes
more convenient than deleting the whole thing.

Jason

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
Sent: Friday, September 09, 2005 12:00 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Windbg locking driver .pdb file

I use a symbol server just for intermediate builds, and
as a part of my build, add my symbols to the server.
I use ddkbuild.bat and I’ve just added the following call in
after the build command:

“C:\Program Files\Debugging Tools for Windows 64-bit\symstore”
add /s e:\SymServer /f . /r /t “IntermediateBuildSymbols”

Then, WinDBG locks the files in e:\symserver, not the files in
my build environment. Since the symstore add copies new files
into the symbol server, the fact that the old files are locked
doesn’t matter.

I periodically (like every month or so) just delete everything in
e:\symserver and start over.

Works great… one day I’ll get the source server stuff
integrated and happening automatically too… but since I
am generally just debugging the current build, it doesn’t
really matter, except on the rare occasions where I’ve a
test build out to someone.

Thanks,

Joseph

Cliff Russell wrote:
> You can also move the file while windbg is using it. Moving the file
out
> of the way will allow you to recompile. This is ok for one or two
build
> cycles, but it gets tedious quickly.
>
> I found it took quite a bit of experimenting with my workflow before I

> got to a point where I wasn’t fighting with windbg, particularly with
> the PDB issue.
>
> On 9-Sep-05, at 10:17 AM, Tim Roberts wrote:
>
>> Arlie Davis wrote:
>>
>>
>>> Stop all of the device instances that are using the driver. The
debug
>>> target will then unload the driver, WinDbg will notice this and will

>>> release
>>> the PDB file. You usually need to do this anyway when you are
>>> loading your
>>> new driver code, so it’s a fairly natural work flow.
>>>
>>>
>>
>> I’m not so sure it’s natural. My usual work flow is “debug, find
>> problem, edit code, recompile, copy to target, devcon restart
>> driver”. That fails, because the recompile fails, because the PDB is

>> still open. A .reload fixes it, although it’s sometimes quicker just

>> to reboot…
>>
>> --Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> You are currently subscribed to windbg as: xxxxx@telus.net
>> To unsubscribe send a blank email to
xxxxx@lists.osr.com
>>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@vandyke.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

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

20

I use my own script to sync with Perforce server, generate change/job lists,
checkin, run setenv/build, binplace, source index, symstore, compress PDB,
generating “P4 change for review” notification mail. All is done with a
single master build command.

In this way, I can easily get to exact state of any point and review any
relevant changes in a convenient and well organized way. I can easily debug
any interim build in the bindrop store without complicated “sym matching,
polling out source, rebuild binary, repro” that kind of thing. It’s very
important if one has to work with combinations of instable OS interim builds,
instable H/W interim build (pre-silicon FPGA array simulation), and driver
that supports these new OS and new HW.

Great thanks to Source Indexing and Perforce!

Calvin Guan (Windows DDK MVP)
NetXtreme Longhorn Miniport Prime
Broadcom Corp. www.broadcom.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-219653-
xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Saturday, September 10, 2005 10:56 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] Windbg locking driver .pdb file

Jason,

You are just chock full of good information. I think Monday I’ll re-
install
6.5, and use the symbol server trick

–
Gary G. Little
“Jason Shay” wrote in message
> news:xxxxx@windbg…
> Note that there is a tool in the debugger package called agestore, which
> can age of the symbols which you haven’t accessed recently. Sometimes
> more convenient than deleting the whole thing.
>
> Jason
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Galbraith
> Sent: Friday, September 09, 2005 12:00 PM
> To: Kernel Debugging Interest List
> Subject: Re: [windbg] Windbg locking driver .pdb file
>
> I use a symbol server just for intermediate builds, and
> as a part of my build, add my symbols to the server.
> I use ddkbuild.bat and I’ve just added the following call in
> after the build command:
>
> “C:\Program Files\Debugging Tools for Windows 64-bit\symstore”
> add /s e:\SymServer /f . /r /t “IntermediateBuildSymbols”
>
> Then, WinDBG locks the files in e:\symserver, not the files in
> my build environment. Since the symstore add copies new files
> into the symbol server, the fact that the old files are locked
> doesn’t matter.
>
> I periodically (like every month or so) just delete everything in
> e:\symserver and start over.
>
> Works great… one day I’ll get the source server stuff
> integrated and happening automatically too… but since I
> am generally just debugging the current build, it doesn’t
> really matter, except on the rare occasions where I’ve a
> test build out to someone.
>
> Thanks,
>
> Joseph
>
>
>
> Cliff Russell wrote:
> > You can also move the file while windbg is using it. Moving the file
> out
> > of the way will allow you to recompile. This is ok for one or two
> build
> > cycles, but it gets tedious quickly.
> >
> > I found it took quite a bit of experimenting with my workflow before I
>
> > got to a point where I wasn’t fighting with windbg, particularly with
> > the PDB issue.
> >
> > On 9-Sep-05, at 10:17 AM, Tim Roberts wrote:
> >
> >> Arlie Davis wrote:
> >>
> >>
> >>> Stop all of the device instances that are using the driver. The
> debug
> >>> target will then unload the driver, WinDbg will notice this and will
>
> >>> release
> >>> the PDB file. You usually need to do this anyway when you are
> >>> loading your
> >>> new driver code, so it’s a fairly natural work flow.
> >>>
> >>>
> >>
> >> I’m not so sure it’s natural. My usual work flow is “debug, find
> >> problem, edit code, recompile, copy to target, devcon restart
> >> driver”. That fails, because the recompile fails, because the PDB is
>
> >> still open. A .reload fixes it, although it’s sometimes quicker just
>
> >> to reboot…
> >>
> >> --Tim Roberts, xxxxx@probo.com
> >> Providenza & Boekelheide, Inc.
> >>
> >>
> >> —
> >> You are currently subscribed to windbg as: xxxxx@telus.net
> >> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> >>
> >
> >
> > —
> > You are currently subscribed to windbg as: xxxxx@vandyke.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@broadcom.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com