windbg locking symbols file

WINDBG
1

Sometimes when I leave windbg running and I rebuild my driver, the
symbol file
does not get written out because windbg seems to have locked it. I have
also
seen windbg lock my executable (even when I did not provide it a path to
find
it) such that it could not be updated. I have had to exit and re-enter
windbg to
get around this latter. I can do .reload to get it to release the
symbols file.

There must be a better way. I appreciate any help.

-Mark Roths

2

.reload /u [your-driver-name]

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roths
Sent: segunda-feira, 13 de outubro de 2003 23:19
To: Kernel Debugging Interest List
Subject: [windbg] windbg locking symbols file

Sometimes when I leave windbg running and I rebuild my driver, the
symbol file
does not get written out because windbg seems to have locked it. I have
also
seen windbg lock my executable (even when I did not provide it a path to
find
it) such that it could not be updated. I have had to exit and re-enter
windbg to
get around this latter. I can do .reload to get it to release the
symbols file.

There must be a better way. I appreciate any help.

-Mark Roths

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

3

Typically you cannot overwrite files that are currently being used. If you
have an active debug session, then the symbol and executable files are in
use and being referenced by WinDbg. Like Rodrigo said, do a “reload -u” on
the file name, or reboot the target.

–
Gary G. Little
Seagate Technologies, LLC

“Mark Roths” wrote in message news:xxxxx@windbg…
>
> Sometimes when I leave windbg running and I rebuild my driver, the
> symbol file
> does not get written out because windbg seems to have locked it. I have
> also
> seen windbg lock my executable (even when I did not provide it a path to
> find
> it) such that it could not be updated. I have had to exit and re-enter
> windbg to
> get around this latter. I can do .reload to get it to release the
> symbols file.
>
> There must be a better way. I appreciate any help.
>
> -Mark Roths
>
>
>

4

Right now .reload is the best way.
Rebooting the target shold also release the files.

Otherwise, you could write a little script (or use binplace) to copy the
files to another directory from which the debugger loads them. You still
need to ensure the file is unlocked before you run the copy, but at least
the compile and link won’t fail.

If we come up with something better, we’ll let you know.

Thanks,

-Andre

5

I have not found that rebooting the target reliably releases the lock on
the file, but I’ll retry. It would be a huge advantage for us (me) to
have the file be unlocked even while in use, because I’m typically
debugging 4 or 8 target machines (all of them running the same drivers)
from a single debug machine and it gets to be a nuisance to maintain 8
separate paths for the 8 different debuggers.

(I’ll freely admit that I’m certainly pushing the envelope of what the
debuggers are intended to be capable of, but hey, if I don’t speak up
you won’t know what people are up to out here, right?).

If you’re wondering: we build a cluster file system (shared data on a
SAN), and it’s a whole lot easier to have a single debug machine with
multiple debuggers running than to try to manage any other setup I’ve
tried.

…dave

-----Original Message-----
From: xxxxx@microsoft.com [mailto:xxxxx@microsoft.com]
Sent: Tuesday, October 14, 2003 10:33 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: windbg locking symbols file

Right now .reload is the best way.
Rebooting the target shold also release the files.

Otherwise, you could write a little script (or use binplace)
to copy the files to another directory from which the
debugger loads them. You still need to ensure the file is
unlocked before you run the copy, but at least the compile
and link won’t fail.

If we come up with something better, we’ll let you know.

Thanks,

-Andre

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

6

This used to be a big problem for me as well until I switched to using
symstore. Now all my builds install the symbols on my symbol server and the
debugger just loads them as needed.

  • Steve -

-----Original Message-----
From: Dave Beaver [mailto:xxxxx@polyserve.com]
Sent: Tuesday, October 14, 2003 1:44 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: windbg locking symbols file

I have not found that rebooting the target reliably releases the lock on
the file, but I’ll retry. It would be a huge advantage for us (me) to
have the file be unlocked even while in use, because I’m typically
debugging 4 or 8 target machines (all of them running the same drivers)
from a single debug machine and it gets to be a nuisance to maintain 8
separate paths for the 8 different debuggers.

(I’ll freely admit that I’m certainly pushing the envelope of what the
debuggers are intended to be capable of, but hey, if I don’t speak up
you won’t know what people are up to out here, right?).

If you’re wondering: we build a cluster file system (shared data on a
SAN), and it’s a whole lot easier to have a single debug machine with
multiple debuggers running than to try to manage any other setup I’ve
tried.

…dave

-----Original Message-----
From: xxxxx@microsoft.com [mailto:xxxxx@microsoft.com]
Sent: Tuesday, October 14, 2003 10:33 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: windbg locking symbols file

Right now .reload is the best way.
Rebooting the target shold also release the files.

Otherwise, you could write a little script (or use binplace)
to copy the files to another directory from which the
debugger loads them. You still need to ensure the file is
unlocked before you run the copy, but at least the compile
and link won’t fail.

If we come up with something better, we’ll let you know.

Thanks,

-Andre

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

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

7

I might be debugging a driver on my target system and all the sources, PBD,
etc are on the host. I find a bug and need to compile the driver. I want
to copy it to the target before I reboot the target or maybe it is a WDM
style driver that can be unloaded and reloaded by unplugging the hardware so
a reboot will not be required. When the compiler attempts to create the new
driver, the debugger has some of the files opened and a new version cannot
be created.

I think the best solution would be for the debugger to copy the input pdb on
the host system to the symbol store if it is available. The sys file might
have to be copied also and a utility provided to allow cleaning up of the
symbol store directory. The debugger could delete all symbol info for
non-MS drivers contained in the symbol store before a new version is
created - an option to permit this by name or globally might be useful.
This problem is one advantage to SoftIce - about the only advantage - in
that the NMS file contains all the sources and debug info needed to debug
the driver. It is located on the target and not in use after it was
initially read into memory. P.S. I know SoftIce is the only debugger worth
anything for 9x and during my mixed development time period, I used SoftIce
so I wouldn’t have to learn two different debuggers. It is also the only
single machine solution, but at its current price, another machine can be
had for considerably less.

wrote in message news:xxxxx@windbg…
>
> Right now .reload is the best way.
> Rebooting the target shold also release the files.
>
> Otherwise, you could write a little script (or use binplace) to copy the
> files to another directory from which the debugger loads them. You still
> need to ensure the file is unlocked before you run the copy, but at least
> the compile and link won’t fail.
>
> If we come up with something better, we’ll let you know.
>
> Thanks,
>
> -Andre
>
>