Re (to Gary Little): RE: WinDbg quick tips

NTDEV
1

Thank’s, Gary. :slight_smile: I rest my case and peacefully accept it… Oh, and how
about those .dbg files? Do I need them? Isn’t the debug info already
placed in the .pdb?

BTW (off-topic), this reminds me of an old joke where there were 3 guys
(an electrician, a mechanic and a programmer) driving a car in a desert.
Suddenly, the car stops.
The electician saids: -There must be something wrong with the electric
system.
The mechanic saids: -Oh, no. Surely, the problem is mechanical.
Then the programmer saids: -Naah… Let us just leave the car and got
back inside!!

The old trick still works… exit and run it again, he?.. :)))

Miguel Monteiro
xxxxx@criticalsoftware.com
www.criticalsoftware.com

«Humour and love are God’s answers
to Human weaknesses»

On Tuesday, March 13, 2001 7:26 PM “Gary Little” wrote:

I think WinDbg needs a potty break very now and then.

I have gotten that also, as well as some really bogus symbols when I
have
been actively debugging across many many boots of the target. Reloading
WinDbg solves the problem for me.

Gary G. Little
Sr. Staff Engineer
Broadband Storage, LLC
xxxxx@broadstor.com
xxxxx@delphieng.com

-----Original Message-----
From: Miguel Monteiro [mailto:xxxxx@criticalsoftware.com]
Sent: Tuesday, March 13, 2001 10:59 AM
To: NT Developers Interest List
Subject: [ntdev] WinDbg quick tips

Hi there. :slight_smile:
These two are quickies (I’m kind of new using WinDbg).

  1. I’ve managed to get WinDbg working quite well. I’m developing a
    kernel-mode driver
    “prototype” and I’ve been using WinDbg (v2.0.0023.0) on a Host-Target
    environment
    running Win2K SP1. Everything seems to work fine, except that
    *sometimes* (I say it
    again: sometimes, not always) I get the below “annoying” message from
    WinDbg. This may
    sound stupid (perhaps it is, sorry), but I dunno why I’m getting it, as
    everything else
    (workspace, source/executable image/symbols loaded and the respective
    paths) is set right.
    I suspect it has something to do with recompiling my driver - which
    doesn’t make great sense,
    as I’m sure the proper .pdb file is there - or the *order* by which I
    start a kernel-mode
    debugging session (usually I start the driver first, then I break into
    it, set breakpoints and
    trace it from there). Does anyone have a clue of what’s going on? (BTW,
    if I exit WinDbg, then
    run WinDbg again and repeat the process, sometimes it starts working
    again… ???)

  2. How do I create .dbg files? I’ve managed to get my drivers compiled
    from VC (through
    a batch file; this is great to locate errors on the source code), but
    ‘build’ simply creates the
    “usual” .obj, .sys and .pdb files (and a .mac file, don’t ask me why).
    I’ve managed to trace through
    my driver code (both source and disassembly) and also through ntdll.dll.
    So… do I *really* need
    .dbg files? Isn’t the (debug) information already available in the .pdb
    file?..

— The infamous “annoying” message from WinDbg… :slight_smile: —

Loading User Symbols
Unable to retrieve the PEB address. This is usually caused
by being in the wrong process context or by paging

Module “MyDriver” was not found in the module list.
Debugger will attempt to load module “MyDriver” by guessing the base
address.

Please provide the full image name, including the extension (i.e.
kernel32.dll) for more reliable results.
************************************************************************
*
***
***
*** Your debugger is not using the correct symbols
***
*** In order for this command to work properly, your symbol path
*** must point to .pdb files that have full type information.
***
*** Certain .pdb files (such as the public OS symbols) do not
*** contain the required information. Contact the group that
*** provided you with these symbols if you need this command to
*** work.
***
***
************************************************************************
*

This is weird, as:

kd> .sympath
Symbol search path is: C:\MyProjects\MyDriver\i386;C:\WINNT\Symbols
kd> .srcpath
Source search path is: C:\MyProjects\MyDriver
kd> .exepath
Executable image search path is: C:\MyProjects\MyDriver\i386

which is perfectly okay!.. Also, .reload works fine for the o.s.
symbols, but not .reload /user !..
I’m in the dark here… Any help would be great (these are easy for you
guys!..).

Miguel Monteiro
xxxxx@criticalsoftware.com
www.criticalsoftware.com

«Humour and love are God’s answers
to Human weaknesses»

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

2

You don’t need .dbg files . .dbg files exist because of a limitation of
the old VC5 toolset. If you use the latest compiler\link to build your
driver, no .dbg file should be created. Just the .sys and .pdb.
For example, in the current windows XP builds, we don’t generate any .dbg
files anymore.

As for the message, I’d be interested in seeing what you typed in the
debugger before you get this message.

The message about the User Loaded Module List being paged out is expected
if you are breaking in the context of a process with no user mode address
space (system process).

The other messages are strange though - looks like the module list got
corrupted or something. If you have some type of repro scenario, or can
generate a dump file of the debugger itself (attach windbg to windbg) and
send us that, that would be great.

-Andre

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

3

Andreva,

As I said, the latest release of WinDbg has an accumulative problem, the
“potty break syndrome”? After a period of time, I have to terminate and
restart WinDbg because suddenly it can no longer resolve symbols. This
happens after hours of work and a multitude of re-boots on the target.

Gary

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@microsoft.com
Sent: Wednesday, March 14, 2001 5:34 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Re (to Gary Little): RE: WinDbg quick tips

You don’t need .dbg files . .dbg files exist because of a limitation of
the old VC5 toolset. If you use the latest compiler\link to build your
driver, no .dbg file should be created. Just the .sys and .pdb.
For example, in the current windows XP builds, we don’t generate any .dbg
files anymore.

As for the message, I’d be interested in seeing what you typed in the
debugger before you get this message.

The message about the User Loaded Module List being paged out is expected
if you are breaking in the context of a process with no user mode address
space (system process).

The other messages are strange though - looks like the module list got
corrupted or something. If you have some type of repro scenario, or can
generate a dump file of the debugger itself (attach windbg to windbg) and
send us that, that would be great.

-Andre

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

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

4

Yup, just kill that instance and restart. I always use PDB files and have no
problems.

Gary

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Miguel Monteiro
Sent: Wednesday, March 14, 2001 2:04 AM
To: NT Developers Interest List
Subject: [ntdev] Re (to Gary Little): RE: WinDbg quick tips

Thank’s, Gary. :slight_smile: I rest my case and peacefully accept it… Oh, and how
about those .dbg files? Do I need them? Isn’t the debug info already
placed in the .pdb?

BTW (off-topic), this reminds me of an old joke where there were 3 guys
(an electrician, a mechanic and a programmer) driving a car in a desert.
Suddenly, the car stops.
The electrician said: -There must be something wrong with the electric
system.
The mechanic said: -Oh, no. Surely, the problem is mechanical.
Then the programmer said: -Naah… Let us just leave the car and got
back inside!!

The old trick still works… exit and run it again, he?.. :)))

Miguel Monteiro
xxxxx@criticalsoftware.com
www.criticalsoftware.com

“Humour and love are God’s answers
to Human weaknesses”

On Tuesday, March 13, 2001 7:26 PM “Gary Little” wrote:

I think WinDbg needs a potty break very now and then.

I have gotten that also, as well as some really bogus symbols when I
have
been actively debugging across many many boots of the target. Reloading
WinDbg solves the problem for me.

Gary G. Little
Sr. Staff Engineer
Broadband Storage, LLC
xxxxx@broadstor.com
xxxxx@delphieng.com

-----Original Message-----
From: Miguel Monteiro [mailto:xxxxx@criticalsoftware.com]
Sent: Tuesday, March 13, 2001 10:59 AM
To: NT Developers Interest List
Subject: [ntdev] WinDbg quick tips

Hi there. :slight_smile:
These two are quickies (I’m kind of new using WinDbg).

  1. I’ve managed to get WinDbg working quite well. I’m developing a
    kernel-mode driver
    “prototype” and I’ve been using WinDbg (v2.0.0023.0) on a Host-Target
    environment
    running Win2K SP1. Everything seems to work fine, except that
    *sometimes* (I say it
    again: sometimes, not always) I get the below “annoying” message from
    WinDbg. This may
    sound stupid (perhaps it is, sorry), but I dunno why I’m getting it, as
    everything else
    (workspace, source/executable image/symbols loaded and the respective
    paths) is set right.
    I suspect it has something to do with recompiling my driver - which
    doesn’t make great sense,
    as I’m sure the proper .pdb file is there - or the *order* by which I
    start a kernel-mode
    debugging session (usually I start the driver first, then I break into
    it, set breakpoints and
    trace it from there). Does anyone have a clue of what’s going on? (BTW,
    if I exit WinDbg, then
    run WinDbg again and repeat the process, sometimes it starts working
    again… ???)

  2. How do I create .dbg files? I’ve managed to get my drivers compiled
    from VC (through
    a batch file; this is great to locate errors on the source code), but
    ‘build’ simply creates the
    “usual” .obj, .sys and .pdb files (and a .mac file, don’t ask me why).
    I’ve managed to trace through
    my driver code (both source and disassembly) and also through ntdll.dll.
    So… do I *really* need
    .dbg files? Isn’t the (debug) information already available in the .pdb
    file?..

— The infamous “annoying” message from WinDbg… :slight_smile: —

Loading User Symbols
Unable to retrieve the PEB address. This is usually caused
by being in the wrong process context or by paging

Module “MyDriver” was not found in the module list.
Debugger will attempt to load module “MyDriver” by guessing the base
address.

Please provide the full image name, including the extension (i.e.
kernel32.dll) for more reliable results.
************************************************************************
*
***
***
*** Your debugger is not using the correct symbols
***
*** In order for this command to work properly, your symbol path
*** must point to .pdb files that have full type information.
***
*** Certain .pdb files (such as the public OS symbols) do not
*** contain the required information. Contact the group that
*** provided you with these symbols if you need this command to
*** work.
***
***
************************************************************************
*

This is weird, as:

kd> .sympath
Symbol search path is: C:\MyProjects\MyDriver\i386;C:\WINNT\Symbols
kd> .srcpath
Source search path is: C:\MyProjects\MyDriver
kd> .exepath
Executable image search path is: C:\MyProjects\MyDriver\i386

which is perfectly okay!.. Also, .reload works fine for the o.s.
symbols, but not .reload /user !..
I’m in the dark here… Any help would be great (these are easy for you
guys!..).

Miguel Monteiro
xxxxx@criticalsoftware.com
www.criticalsoftware.com

“Humour and love are God’s answers
to Human weaknesses”

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

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

5

> The message about the User Loaded Module List being paged out is expected

if you are breaking in the context of a process with no user mode address
space (system process).

Another problem of the last WinDbg:

“Unable to verify Timestamp for xxxx” while loading a symbol file.

It complains on all symbols - NTOSKRNL, HAL, my driver just built etc.

Is it possible to shut if off?

Max

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

6

Max,

I use !reload, or “bp DriveName!breakpoint”. I guess the WinDbg folks think
this is a feature, as this is what they told me to do.

Gary

PS: Generally, a “feature” is nothing more than a bug in drag.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Maxim S. Shatskih
Sent: Saturday, March 17, 2001 11:56 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Re (to Gary Little): RE: WinDbg quick tips

The message about the User Loaded Module List being paged out is expected
if you are breaking in the context of a process with no user mode address
space (system process).

Another problem of the last WinDbg:

“Unable to verify Timestamp for xxxx” while loading a symbol file.

It complains on all symbols - NTOSKRNL, HAL, my driver just built etc.

Is it possible to shut if off?

Max

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

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