WinDbg 2.0.0023.0,PEB problem

Hello all,

I have install Windbg 2.0.0023.0 on host m/c.i have copied all the symbols
directory from WinNT and sp cd’s to host m/c and set this directory as
symbol path in windbg.
when i set breakpoint in the source code then a message comes “Symbol
information for current line could not be located in the current loaded
symbols”, i click “Yes” option in this message which perform the search for
symbols.then it displayed “could not found, breakpoint not set”.
when i type “.reload” in KD> windows,then following message displayed
“loading user symbols
unable to retrive the PEB address this is usaly caused by being in
the wrong process context or by pegging”

how can i overcome this situation?

Regards,
Akhil


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

When you see this message, “unable to retrieve the PEB address…” when
you do a .reload it means that the user mode module list is paged out
and therefore the debugger has no idea what modules to load symbols for
at what addresses. This is true for UM modules only. So drivers are
unaffected. The majority of the time when people are doing kernel
debugging with Windbg they are interested in KM modules only and so this
normally can be safely ignored.

If you need to do user mode debugging and keep hitting this (and other
paging issues) then you should really investigate using a user mode
debugger (you can use windbg or cdb from the debugger package). Because
the system is running when the UM debugger does a memory access, the
memory will get paged in if it is not already.

As to your breakpoint problem, here are some ideas:
Use the version 3 beta rather than version 2. IMO the v3 betas
are better than v2.
Set the symbol path and do a .reload BEFORE attempting to set
breakpoints.
Verify you that the symbols are loading correctly. “!sym noisy”
really helps to diagnose symbol problems.

-----Original Message-----
From: xxxxx@yahoo.co.in [mailto:xxxxx@yahoo.co.in]
Sent: Tuesday, July 10, 2001 3:44 AM
To: Kernel Debugging Interest List
Subject: [windbg] WinDbg 2.0.0023.0,PEB problem

Hello all,

I have install Windbg 2.0.0023.0 on host m/c.i have copied all the
symbols
directory from WinNT and sp cd’s to host m/c and set this directory as
symbol path in windbg.
when i set breakpoint in the source code then a message comes “Symbol
information for current line could not be located in the current loaded
symbols”, i click “Yes” option in this message which perform the search
for
symbols.then it displayed “could not found, breakpoint not set”.
when i type “.reload” in KD> windows,then following message displayed
“loading user symbols
unable to retrive the PEB address this is usaly caused by being in
the wrong process context or by pegging”

how can i overcome this situation?

Regards,
Akhil


You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Can’t a kernel module – a device driver – be paged out entirely?
Assuming, that is, it was linked, or has marked itself, pageable.


James Antognini
IBM Watson Research


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You are probably trying to set the breakpoint before your driver is loaded
and lazy symbol loading turned on. Lazy symbol loading won’t load your
symbols until your driver is actually loaded by the system. Even .reload
will not work. To overcome this either use the command line options as
documented to disable lazy symbol loading (also called deferred symbol
loading). This, however, can slow things down. You can also whip Windbg
into action for your specific driver’s symbols by reloading them with the
/f option and specifying your specific path and module name. (i.e.,
.reload /f ). I believe you can override it with the
ld extension.


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com

When you set a breakpoint on a line of source you can think of it doing
the following (overly simplistic algorithm)

For each module loaded
Load symbols
Search symbols to see if we get a source file name match
If match found then set BP and exit loops
Next

If no match found then remember source info and create a
deferred breakpoint. When a module is loaded it’s symbols will be
loaded and compared with the deferred breakpoint. If a match is found
then the deferred breakpoint is turned into a real breakpoint. If not
then it remains a deferred breakpoint to be processed at the next module
load.

You should (and I do) set source breakpoints in unloaded modules
without having to do any tricks. However if you want to provide some
more info to the debugger then it can imploy some smarter algorithms.

For example, setting a source breakpoint on an unloaded module
will be time consuming because all modules will be searched for a match.
So there are 2 ways you can avoid this:

  1. Set the BP after your module has loaded
  2. Specify the module when you set the BP. This must be done
    from the command window. To set it on a function you can do “bp
    mod!DriverEntry”. For a source like you can do “bp mod!source.c:12”.
    Either one of these methods will skip the searching all modules, because
    you have told the debugger what module it applys to.

Things like turning off lazy symbol loading or doing tricks with
.reload indicate that there is probably some other problem or
misunderstanding. All lazy symbol loading does is has you pay the price
of the symbol load front up, rather than scattered around driven by
access.

-----Original Message-----
From: xxxxx@unisys.com [mailto:xxxxx@unisys.com]
Sent: Tuesday, July 10, 2001 6:00 PM
To: Kernel Debugging Interest List
Subject: [windbg] Re: WinDbg 2.0.0023.0,PEB problem

You are probably trying to set the breakpoint before your driver is
loaded
and lazy symbol loading turned on. Lazy symbol loading won’t load your
symbols until your driver is actually loaded by the system. Even
.reload
will not work. To overcome this either use the command line options as
documented to disable lazy symbol loading (also called deferred symbol
loading). This, however, can slow things down. You can also whip
Windbg
into action for your specific driver’s symbols by reloading them with
the
/f option and specifying your specific path and module name. (i.e.,
.reload /f ). I believe you can override it with
the
ld extension.


You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to windbg as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-windbg-$subst(‘Recip.MemberIDChar’)@lists.osr.com