I am currently debugging a user mode dll with cdb version 6.0.7.0. This
dll is dynamically loaded and unloaded by a service. It seems that if I
ask the service to unload the dll, then I make some changes to the dll
and ask the service to reload it, the sources displayed when I’m
stepping through the program are still the old version. I’ll have to
manually do a lsf- and then lsf to update them. Is it possible to
enhance the debugger in a future version so that it will automatically
unload the source file if its corresponding module is unloaded? Or am I
totally missing something? Thanks!
When you load the new version of the dll, do you do a .reload or .reload
/f to reload the cached information the debugger has about the
old dll and its symbols? This is just a suggestion if all else fails.
I don’t think this is your real problem…
You should not have to use lsf at all. That may be the real problem.
lsf is more for manually loading a source file that should not be loaded
(i.e. you want to browse the source from the debugger). Try using
.lines, point .srcpath to point to your sources, and just use ls. For
example: “ls .” will list source starting at the current instruction.
“ls. -10,20” will list 10 source lines before and 10 source lines after
the current instruction.
Depending on what you are debugging you may also want to use the l+s
command to list source lines at the debugger prompt while you are
stepping. l+t will make sure you are stepping by source line instead of
assembly instruction. You have to enable .lines for these to work. If
you have l+s enabled you may also want to use lsp to set the number of
source lines displayed at the prompt each time you step (e.g. lsp 4 4 or
lsp 8 8).
-----Original Message-----
From: Faris Y. Yau [mailto:xxxxx@stg.com]
Sent: Sunday, April 21, 2002 9:10 AM
To: Kernel Debugging Interest List
Subject: [windbg] Updating source file with cdb
I am currently debugging a user mode dll with cdb version 6.0.7.0. This
dll is dynamically loaded and unloaded by a service. It seems that if I
ask the service to unload the dll, then I make some changes to the dll
and ask the service to reload it, the sources displayed when I’m
stepping through the program are still the old version. I’ll have to
manually do a lsf- and then lsf to update them. Is it possible to
enhance the debugger in a future version so that it will automatically
unload the source file if its corresponding module is unloaded? Or am I
totally missing something? Thanks!
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
I haven’t tried .reload yet, since the symbols *appear* to be correct.
But I can be wrong. I thought the debugger would know that a module is
being loaded and automatically grab the new symbols.
Right now I use -c "$start cdb:
.lines -e
l+*
lsp 6
That’s how I see the sources when I’m stepping through the program with
p or t. And these sources are not updated when I reload my dll. I
didn’t use lsf before that. But I discovered that I can use lsf- to
help it “flush” the stale file out.
Well, I’ll try .reload to see if it helps. Thanks for your suggestions!
David Holcomb wrote:
>
> When you load the new version of the dll, do you do a .reload or .reload
> /f to reload the cached information the debugger has about the
> old dll and its symbols? This is just a suggestion if all else fails.
> I don’t think this is your real problem…
>
> You should not have to use lsf at all. That may be the real problem.
> lsf is more for manually loading a source file that should not be loaded
> (i.e. you want to browse the source from the debugger). Try using
> .lines, point .srcpath to point to your sources, and just use ls. For
> example: “ls .” will list source starting at the current instruction.
> “ls. -10,20” will list 10 source lines before and 10 source lines after
> the current instruction.
>
> Depending on what you are debugging you may also want to use the l+s
> command to list source lines at the debugger prompt while you are
> stepping. l+t will make sure you are stepping by source line instead of
> assembly instruction. You have to enable .lines for these to work. If
> you have l+s enabled you may also want to use lsp to set the number of
> source lines displayed at the prompt each time you step (e.g. lsp 4 4 or
> lsp 8 8).
>
> -----Original Message-----
> From: Faris Y. Yau [mailto:xxxxx@stg.com]
> Sent: Sunday, April 21, 2002 9:10 AM
> To: Kernel Debugging Interest List
> Subject: [windbg] Updating source file with cdb
>
> I am currently debugging a user mode dll with cdb version 6.0.7.0. This
> dll is dynamically loaded and unloaded by a service. It seems that if I
> ask the service to unload the dll, then I make some changes to the dll
> and ask the service to reload it, the sources displayed when I’m
> stepping through the program are still the old version. I’ll have to
> manually do a lsf- and then lsf to update them. Is it possible to
> enhance the debugger in a future version so that it will automatically
> unload the source file if its corresponding module is unloaded? Or am I
> totally missing something? Thanks!
>
> —
> You are currently subscribed to windbg as: xxxxx@microsoft.com To
> unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to windbg as: xxxxx@stg.com
> To unsubscribe send a blank email to %%email.unsub%%
Thanks for the clarification. It is possible that the source file is
being cached in memory too and not being released. I will look into it.
Please post if the .reload helps.
-----Original Message-----
From: Faris Y. Yau [mailto:xxxxx@stg.com]
Sent: Sunday, April 21, 2002 10:05 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Updating source file with cdb
I haven’t tried .reload yet, since the symbols *appear* to be correct.
But I can be wrong. I thought the debugger would know that a module is
being loaded and automatically grab the new symbols.
Right now I use -c "$start cdb:
.lines -e
l+*
lsp 6
That’s how I see the sources when I’m stepping through the program with
p or t. And these sources are not updated when I reload my dll. I
didn’t use lsf before that. But I discovered that I can use lsf- to
help it “flush” the stale file out.
Well, I’ll try .reload to see if it helps. Thanks for your suggestions!
David Holcomb wrote:
>
> When you load the new version of the dll, do you do a .reload or
> .reload /f to reload the cached information the debugger has
> about the old dll and its symbols? This is just a suggestion if all
> else fails. I don’t think this is your real problem…
>
> You should not have to use lsf at all. That may be the real problem.
> lsf is more for manually loading a source file that should not be
> loaded (i.e. you want to browse the source from the debugger). Try
> using .lines, point .srcpath to point to your sources, and just use
> ls. For
> example: “ls .” will list source starting at the current instruction.
> “ls. -10,20” will list 10 source lines before and 10 source lines
after
> the current instruction.
>
> Depending on what you are debugging you may also want to use the l+s
> command to list source lines at the debugger prompt while you are
> stepping. l+t will make sure you are stepping by source line instead
> of assembly instruction. You have to enable .lines for these to work.
> If you have l+s enabled you may also want to use lsp to set the number
> of source lines displayed at the prompt each time you step (e.g. lsp 4
> 4 or lsp 8 8).
>
> -----Original Message-----
> From: Faris Y. Yau [mailto:xxxxx@stg.com]
> Sent: Sunday, April 21, 2002 9:10 AM
> To: Kernel Debugging Interest List
> Subject: [windbg] Updating source file with cdb
>
> I am currently debugging a user mode dll with cdb version 6.0.7.0.
> This dll is dynamically loaded and unloaded by a service. It seems
> that if I ask the service to unload the dll, then I make some changes
> to the dll and ask the service to reload it, the sources displayed
> when I’m stepping through the program are still the old version. I’ll
> have to manually do a lsf- and then lsf to update them. Is it
> possible to enhance the debugger in a future version so that it will
> automatically unload the source file if its corresponding module is
> unloaded? Or am I totally missing something? Thanks!
>
> —
> You are currently subscribed to windbg as: xxxxx@microsoft.com To
> unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to windbg as: xxxxx@stg.com
> To unsubscribe send a blank email to %%email.unsub%%
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
I’ve tried it. .reload -f xxx.cpp does not solve the problem. Only
lsf- xxx.cpp will take care of it.
David Holcomb wrote:
Thanks for the clarification. It is possible that the source file is
being cached in memory too and not being released. I will look into it.
Please post if the .reload helps.-----Original Message-----
From: Faris Y. Yau [mailto:xxxxx@stg.com]
Sent: Sunday, April 21, 2002 10:05 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Updating source file with cdbI haven’t tried .reload yet, since the symbols *appear* to be correct.
But I can be wrong. I thought the debugger would know that a module is
being loaded and automatically grab the new symbols.Right now I use -c "$> start cdb:
>
> .lines -e
> l+*
> lsp 6
>
> That’s how I see the sources when I’m stepping through the program with
> p or t. And these sources are not updated when I reload my dll. I
> didn’t use lsf before that. But I discovered that I can use lsf- to
> help it “flush” the stale file out.
>
> Well, I’ll try .reload to see if it helps. Thanks for your suggestions!
>
> David Holcomb wrote:
> >
> > When you load the new version of the dll, do you do a .reload or
> > .reload /f to reload the cached information the debugger has
>
> > about the old dll and its symbols? This is just a suggestion if all
> > else fails. I don’t think this is your real problem…
> >
> > You should not have to use lsf at all. That may be the real problem.
> > lsf is more for manually loading a source file that should not be
> > loaded (i.e. you want to browse the source from the debugger). Try
> > using .lines, point .srcpath to point to your sources, and just use
> > ls. For
> > example: “ls .” will list source starting at the current instruction.
> > “ls. -10,20” will list 10 source lines before and 10 source lines
> after
> > the current instruction.
> >
> > Depending on what you are debugging you may also want to use the l+s
> > command to list source lines at the debugger prompt while you are
> > stepping. l+t will make sure you are stepping by source line instead
> > of assembly instruction. You have to enable .lines for these to work.
>
> > If you have l+s enabled you may also want to use lsp to set the number
>
> > of source lines displayed at the prompt each time you step (e.g. lsp 4
>
> > 4 or lsp 8 8).
> >
> > -----Original Message-----
> > From: Faris Y. Yau [mailto:xxxxx@stg.com]
> > Sent: Sunday, April 21, 2002 9:10 AM
> > To: Kernel Debugging Interest List
> > Subject: [windbg] Updating source file with cdb
> >
> > I am currently debugging a user mode dll with cdb version 6.0.7.0.
> > This dll is dynamically loaded and unloaded by a service. It seems
> > that if I ask the service to unload the dll, then I make some changes
> > to the dll and ask the service to reload it, the sources displayed
> > when I’m stepping through the program are still the old version. I’ll
>
> > have to manually do a lsf- and then lsf to update them. Is it
> > possible to enhance the debugger in a future version so that it will
> > automatically unload the source file if its corresponding module is
> > unloaded? Or am I totally missing something? Thanks!
> >
> > —
> > You are currently subscribed to windbg as: xxxxx@microsoft.com To
> > unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to windbg as: xxxxx@stg.com
> > To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to windbg as: xxxxx@microsoft.com To
> unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to windbg as: xxxxx@stg.com
> To unsubscribe send a blank email to %%email.unsub%%
–
Faris Y. Yau
Software Technologies Group, Inc.
Voice: (708) 547-0110 x270
Fax: (708) 547-0783
If the dll is called foo.dll you should try .reload foo or better yet
.reload foo.dll.
-----Original Message-----
From: Faris Y. Yau [mailto:xxxxx@stg.com]
Sent: Sunday, April 21, 2002 11:07 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Updating source file with cdb
I’ve tried it. .reload -f xxx.cpp does not solve the problem. Only
lsf- xxx.cpp will take care of it.
David Holcomb wrote:
Thanks for the clarification. It is possible that the source file is
being cached in memory too and not being released. I will look into
it. Please post if the .reload helps.-----Original Message-----
From: Faris Y. Yau [mailto:xxxxx@stg.com]
Sent: Sunday, April 21, 2002 10:05 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Updating source file with cdbI haven’t tried .reload yet, since the symbols *appear* to be correct.
But I can be wrong. I thought the debugger would know that a module
is being loaded and automatically grab the new symbols.Right now I use -c "$
> I start cdb:
>
> .lines -e
> l+*
> lsp 6
>
> That’s how I see the sources when I’m stepping through the program
> with p or t. And these sources are not updated when I reload my dll.
I
> didn’t use lsf before that. But I discovered that I can use lsf- to
> help it “flush” the stale file out.
>
> Well, I’ll try .reload to see if it helps. Thanks for your
> suggestions!
>
> David Holcomb wrote:
> >
> > When you load the new version of the dll, do you do a .reload or
> > .reload /f to reload the cached information the debugger
> > has
>
> > about the old dll and its symbols? This is just a suggestion if all
> > else fails. I don’t think this is your real problem…
> >
> > You should not have to use lsf at all. That may be the real
> > problem. lsf is more for manually loading a source file that should
> > not be loaded (i.e. you want to browse the source from the
> > debugger). Try using .lines, point .srcpath to point to your
> > sources, and just use ls. For
> > example: “ls .” will list source starting at the current
> > instruction. “ls. -10,20” will list 10 source lines before and 10
> > source lines
> after
> > the current instruction.
> >
> > Depending on what you are debugging you may also want to use the l+s
> > command to list source lines at the debugger prompt while you are
> > stepping. l+t will make sure you are stepping by source line
> > instead of assembly instruction. You have to enable .lines for
> > these to work.
>
> > If you have l+s enabled you may also want to use lsp to set the
> > number
>
> > of source lines displayed at the prompt each time you step (e.g. lsp
> > 4
>
> > 4 or lsp 8 8).
> >
> > -----Original Message-----
> > From: Faris Y. Yau [mailto:xxxxx@stg.com]
> > Sent: Sunday, April 21, 2002 9:10 AM
> > To: Kernel Debugging Interest List
> > Subject: [windbg] Updating source file with cdb
> >
> > I am currently debugging a user mode dll with cdb version 6.0.7.0.
> > This dll is dynamically loaded and unloaded by a service. It seems
> > that if I ask the service to unload the dll, then I make some
> > changes to the dll and ask the service to reload it, the sources
> > displayed when I’m stepping through the program are still the old
> > version. I’ll
>
> > have to manually do a lsf- and then lsf to update them. Is it
> > possible to enhance the debugger in a future version so that it will
> > automatically unload the source file if its corresponding module is
> > unloaded? Or am I totally missing something? Thanks!
> >
> > —
> > You are currently subscribed to windbg as: xxxxx@microsoft.com To
> > unsubscribe send a blank email to %%email.unsub%%
> >
> > —
> > You are currently subscribed to windbg as: xxxxx@stg.com
> > To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to windbg as: xxxxx@microsoft.com To
> unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to windbg as: xxxxx@stg.com
> To unsubscribe send a blank email to %%email.unsub%%
–
Faris Y. Yau
Software Technologies Group, Inc.
Voice: (708) 547-0110 x270
Fax: (708) 547-0783
—
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
I meant .reload foo.dll. Thinking a little bit ahead of myself… 
David Holcomb wrote:
If the dll is called foo.dll you should try .reload foo or better yet
.reload foo.dll.
If you are doing sorce level debugging then you should look into
switching to windbg. Windbg is the prefered tool for source level
debugging. With all the remoting options that the debugger provides I
really can’t think of any scenerio where it would be impossible to use
Windbg. You may still need to run cdb on the target computer and use
“-server” in it’s command line to share it out via the network
(preferred) or serial/1394. Then connect Windbg to the remote.
Windbg, BTW, does have code to detect when a source file is changed and
reload it.
-----Original Message-----
From: Faris Y. Yau [mailto:xxxxx@stg.com]
Sent: Sunday, April 21, 2002 11:17 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Updating source file with cdb
I meant .reload foo.dll. Thinking a little bit ahead of myself…
David Holcomb wrote:
If the dll is called foo.dll you should try .reload foo or better yet
.reload foo.dll.
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%
I’ve tried windbg before and I decided that I don’t like the way that
the sub windows pop up and interact in general. I’m sure there are ways
to customize the GUI to my taste, and I’ll definitely look into it again
in the future, but I’m not very good at this kind of thing and for now
I’m more comfortable with the cdb and kd environment. There is only 1
window and I can get everything I need from it.
Nathan Nesbit wrote:
If you are doing sorce level debugging then you should look into
switching to windbg. Windbg is the prefered tool for source level
debugging. With all the remoting options that the debugger provides I
really can’t think of any scenerio where it would be impossible to use
Windbg. You may still need to run cdb on the target computer and use
“-server” in it’s command line to share it out via the network
(preferred) or serial/1394. Then connect Windbg to the remote.Windbg, BTW, does have code to detect when a source file is changed and
reload it.