Break on first module load

[raj_r]

which is the earliest break possible

cycling through debug -> kernel connection i get two option to break
according to the help file

one is equivalent to commandline switch -b
and another -d

help says -d can break earlier than -b

there is also a /break switch availble in boot.ini

does /break switch enabled in boot.ini break earlier than these both ?

also help file says

*Break on first module load*

whereaes cycling through ctrl+alt+k i see it says
breaks on first symbol module load

which mean all the real modules have been already loaded isnt it ?
and this break will break
at nt!dbgLoadImageSymbols

2. also after i cycle through and select an option

if i issue a .reboot to vpc

i see the existing windbg(kd) closes down

and a new windbg(kd) session starts up

i was thinking it would remain active and catch the break

is this the normal way ?

3. can i force windbg to break even earlier than nt!DebugBreak which is
   where it breaks
   if i use /break switch in boot.ini
   like lets say
   nt!KiSystemStartup

4. how can i break lets say on the address of entry point of bootvid.dll
   (assuming its called)

5)also what happens if i was tracing and i execute nt!KeBugCheckEx() from
windbg

does the windbg as well as target both sit there doing nothing (idling maybe
)

the windbg gui is active the vpc gui is active (in the sense i can minimize
maximize it to taskbar)

but i cant do anything else with both of them (if i reset vpc ) this windbg
remains a zombie
doesnt break again

hope to get a few pointers

thanks and regards

raj_r

[OSR_Community_User]

1. The “breakin on first symbol load” option is the earliest possible
   break for the regular kernel boot. The kernel module load is sent
   immediately after initializing kernel debugging on the target, and with
   an initial-module-load break you’ll stop there.

I can’t answer as to whether /break is even earlier than that. It’s
possible that if the boot loader interprets /break itself and breaks for
boot debugging then you could get a break during the boot loader phase.
However, I’m not sure that’s what you’re interested in. If it’s regular
kernel debugging that you care about, the -d initial module break is the
earliest.

2. When the target reboots the debugger discards all state since you
   could boot up a totally different system. In windbg this will cause a
   workspace change and thus your window state could change.

3. -d is the earliest regular kernel debugging break. You can’t break
   on KiSystemStartup as kd isn’t initialized and usable then. If you’re
   doing boot debugging you can watch the kernel load and catch the
   transition from the boot loader to the kernel.

4. You can only catch breaks on boot-loader-time drivers if you’re doing
   boot debugging.

5. How far did you go in KeBugCheckEx? Did you step in or over? It’s
   normal code and can be stepped into right up to the point when it resets
   the box.

---

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Friday, October 20, 2006 12:46 PM
To: Kernel Debugging Interest List
Subject: [windbg] Break on first module load

which is the earliest break possible

cycling through debug -> kernel connection i get two option to break
according to the help file

one is equivalent to commandline switch -b
and another -d

help says -d can break earlier than -b

there is also a /break switch availble in boot.ini

does /break switch enabled in boot.ini break earlier than these both ?

also help file says

Break on first module load

whereaes cycling through ctrl+alt+k i see it says
breaks on first symbol module load

which mean all the real modules have been already loaded isnt it ?
and this break will break
at nt!dbgLoadImageSymbols

2. also after i cycle through and select an option

if i issue a .reboot to vpc

i see the existing windbg(kd) closes down

and a new windbg(kd) session starts up

i was thinking it would remain active and catch the break

is this the normal way ?

3. can i force windbg to break even earlier than nt!DebugBreak which is
   where it breaks
   if i use /break switch in boot.ini
   like lets say
   nt!KiSystemStartup

4. how can i break lets say on the address of entry point of bootvid.dll

(assuming its called)

5)also what happens if i was tracing and i execute nt!KeBugCheckEx()
from windbg

does the windbg as well as target both sit there doing nothing (idling
maybe )

the windbg gui is active the vpc gui is active (in the sense i can
minimize maximize it to taskbar)

but i cant do anything else with both of them (if i reset vpc ) this
windbg remains a zombie
doesnt break again

hope to get a few pointers

thanks and regards

raj_r

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

[raj_r]

On 10/21/06, Drew Bliss wrote:

> 1. The “breakin on first symbol load” option is the earliest possible
> break for the regular kernel boot. The kernel module load is sent
> immediately after initializing kernel debugging on the target, and with an
> initial-module-load break you’ll stop there.
>
> I can’t answer as to whether /break is even earlier than that. It’s
> possible that if the boot loader interprets /break itself and breaks for
> boot debugging then you could get a break during the boot loader phase.
> However, I’m not sure that’s what you’re interested in. If it’s regular
> kernel debugging that you care about, the -d initial module break is the
> earliest.
>

/break breaks in nt!dbgBreak after it calls IMP_HAL_SOMEFUNCTION

while -d breaks in the embedded int3 after
nt!DebugService
after it returns from int 2d which looks like it breaks later than
/break

on both of the breaks if i do a .reload /f immediately on breaking
i see about 10~15 drivers already loaded and probably initialised
as well

i was looking if i could break even earlier that is before even any of the
drivers like acpi.sys ,bootvid.dll , dmio.sys, mup.sys, etc are loaded

the bitmap that says windows is loading isn’t being shown yet while wile
windbg breaks but the progress bar is at its end

so if that’s called breaking on boot loader phase would kd help me catch
them

>
> 2. When the target reboots the debugger discards all state since you could
> boot up a totally different system. In windbg this will cause a workspace
> change and thus your window state could change.
>

so that’s normal way thanks

>
> 3. -d is the earliest regular kernel debugging break. You can’t break on
> KiSystemStartup as kd isn’t initialized and usable then. If you’re doing
> boot debugging you can watch the kernel load and catch the transition from
> the boot loader to the kernel.
>
4. You can only catch breaks on boot-loader-time drivers if you’re doing
> boot debugging.
>

i have got to read up what boot debugging is and if i can use kd there
someway so this topic is still pending

> 5. How far did you go in KeBugCheckEx? Did you step in or over? It’s
> normal code and can be stepped into right up to the point when it resets the
> box.
>

i f10’nned it twice and f5’ed it thrice haven’t f8’ed yet
that is i stepped over it twice and ran it thrice haven’t yet stepped in yet

so assuming i stepped in what happen after it resets the box ?
does both the target and windbg both become Zombies ?

bugcheck 5c with no params after apparent failure of
imp_hal_somefunction

the windbg says
fatal error occurred
exception break point 0x80000003
kernel debugger entered on first try
some callbacks haven’t been called yet
shows the first two or three lines of the
!analyze output (doesn’t end with the normal output which should probably
end with use !analyze -v for detailed information )

and that’s it the prompt turns busy and it starts literally sleeping
or probably stays in rem state (rapid eye movement state where one hasn’t
yet slept but dreaming chewing cud ) i’ve left it stay in that state for
half an hour once after which i simply end tasked it from task manager and
reset the vpc from its menu

doesn’t respond to ctrl+break , ctrl+alt+r , ctrl+c nothing
only thing i can do is minimize and maximize windbg
and the behaviour seems to be persistent for all the five times i
observed it

6) a new question

how do i switch to exported symbols only
does that entail deleting the _NT_SYMBOL_PATH variable
and starting kd without -y “symsrv path”

i can set a bm foo!* and windbg happily accepts it
but if i try doing bm nt!*
it says matching code symbols not found
if you are using public symbols please switch to either full symbols
or exported symbols

obviously i cant switch to full symbols so i wish to switch to
exported symbols how do i proceed

and after i use exported symbol could i get back the public symbols
with either .reload /i /f “path” or may be with ld (load symbols) at a later
stage when i have cleared the break point list

[OSR_Community_User]

The boot loader is the piece of code which loads initial drivers for
booting the OS. It does offer a debugging connection via kd (serial
only).

The biggest risk of stepping over KeBugCheck is that, since it’s a
no-return function, that you’re going to have a breakpoint on whatever
piece of code follows KeBugCheck. Breakpoints on some system functions
aren’t supported since the code is used by kd itself, thus they can be
dangerous. The bugcheck with STATUS_BREAKPOINT looks suspiciously like
this kind of thing. If !analyze doesn’t complete it may be looking for
something else; if it doesn’t complete in an hour or so you can capture
a full dump of the windbg process and send that to
xxxxx@microsoft.com.

The key thing to look for is the “shutdown occurred” message, which
means that kd.exe was notified that the target is rebooting. If you
don’t get that message then kd is still waiting for a normal response
from the target. If the target is also stuck it’s most likely dead.

You can force exported symbols by setting your symbol path to something
where symbols don’t exist and then doing a reload. Note that bm nt!*
isn’t going to work even if you have valid symbols. The target kernel
only supports 32 breakpoints and there are many routines in the kernel
that it isn’t safe to set breakpoints on, so a blanket bm nt!* is not a
good thing to try.

---

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Saturday, October 21, 2006 12:41 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Break on first module load

On 10/21/06, Drew Bliss wrote:

1. The “breakin on first symbol load” option is the earliest
possible break for the regular kernel boot. The kernel module load is
sent immediately after initializing kernel debugging on the target, and
with an initial-module-load break you’ll stop there.

I can’t answer as to whether /break is even earlier than that.
It’s possible that if the boot loader interprets /break itself and
breaks for boot debugging then you could get a break during the boot
loader phase. However, I’m not sure that’s what you’re interested in.
If it’s regular kernel debugging that you care about, the -d initial
module break is the earliest.

/break breaks in nt!dbgBreak after it calls IMP_HAL_SOMEFUNCTION

while -d breaks in the embedded int3 after
nt!DebugService
after it returns from int 2d which looks like it breaks later than
/break

on both of the breaks if i do a .reload /f immediately on breaking
i see about 10~15 drivers already loaded and probably initialised
as well

i was looking if i could break even earlier that is before even any of
the drivers like acpi.sys ,bootvid.dll , dmio.sys, mup.sys, etc are
loaded

the bitmap that says windows is loading isn’t being shown yet while
wile windbg breaks but the progress bar is at its end

so if that’s called breaking on boot loader phase would kd help me catch
them

2. When the target reboots the debugger discards all state since
you could boot up a totally different system. In windbg this will cause
a workspace change and thus your window state could change.

so that’s normal way thanks

3. -d is the earliest regular kernel debugging break. You can’t
break on KiSystemStartup as kd isn’t initialized and usable then. If
you’re doing boot debugging you can watch the kernel load and catch the
transition from the boot loader to the kernel.

4. You can only catch breaks on boot-loader-time drivers if
you’re doing boot debugging.

i have got to read up what boot debugging is and if i can use kd there
someway so this topic is still pending

5. How far did you go in KeBugCheckEx? Did you step in or over?
It’s normal code and can be stepped into right up to the point when it
resets the box.

i f10’nned it twice and f5’ed it thrice haven’t f8’ed yet
that is i stepped over it twice and ran it thrice haven’t yet stepped in
yet
so assuming i stepped in what happen after it resets the box ?
does both the target and windbg both become Zombies ?

bugcheck 5c with no params after apparent failure of
imp_hal_somefunction

the windbg says
fatal error occurred
exception break point 0x80000003
kernel debugger entered on first try
some callbacks haven’t been called yet
shows the first two or three lines of the
!analyze output (doesn’t end with the normal output which should
probably end with use !analyze -v for detailed information )

and that’s it the prompt turns busy and it starts literally sleeping
or probably stays in rem state (rapid eye movement state where one
hasn’t yet slept but dreaming chewing cud ) i’ve left it stay in that
state for half an hour once after which i simply end tasked it from task
manager and reset the vpc from its menu

doesn’t respond to ctrl+break , ctrl+alt+r , ctrl+c nothing
only thing i can do is minimize and maximize windbg
and the behaviour seems to be persistent for all the five times i
observed it

6) a new question

how do i switch to exported symbols only
does that entail deleting the _NT_SYMBOL_PATH variable
and starting kd without -y “symsrv path”

i can set a bm foo!* and windbg happily accepts it
but if i try doing bm nt!*
it says matching code symbols not found
if you are using public symbols please switch to either full symbols
or exported symbols

obviously i cant switch to full symbols so i wish to switch to
exported symbols how do i proceed

and after i use exported symbol could i get back the public symbols
with either .reload /i /f “path” or may be with ld (load symbols) at a
later stage when i have cleared the break point list

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

[raj_r]

On 10/23/06, Drew Bliss wrote:
>
> The boot loader is the piece of code which loads initial drivers for
> booting the OS. It does offer a debugging connection via kd (serial only).
>

Thanks for the information ill have to gather more information before i
could try and ask a few sensible questions i just have one dumb question at
this moment you emphasize serial only so does that mean
i cant check with my present way of working ?
viz windbg -k com:pipe,port=\.\pipe\debugPipe,resets=0,reconnect

> The biggest risk of stepping over KeBugCheck is that, since it’s a
> no-return function, that you’re going to have a breakpoint on whatever piece
> of code follows KeBugCheck. Breakpoints on some system functions aren’t
> supported since the code is used by kd itself, thus they can be dangerous.
> The bugcheck with STATUS_BREAKPOINT looks suspiciously like this kind of
> thing. If !analyze doesn’t complete it may be looking for something else;
> if it doesn’t complete in an hour or so you can capture a full dump of the
> windbg process and send that to xxxxx@microsoft.com.
>
> The key thing to look for is the “shutdown occurred” message, which means
> that kd.exe was notified that the target is rebooting. If you don’t get
> that message then kd is still waiting for a normal response from the
> target. If the target is also stuck it’s most likely dead.
>
>

i dont recall seeing the shutdown occured
all symbols are being flushed
error dos rtnl_somecrap
<--------snip------------ from my memory quotes>
waiting to reconnect

messages

i think it abrupty went into fatal system error occured messages and
stayed busy there

ill check it again and if it didnt respond within an hour or so ill try to
capture the process

btw if you could possibly explain how i can dump the entire memory
does it mean i crash my host somehow and create a full kernel memory dump in
my host pc ? that would be helpfull

You can force exported symbols by setting your symbol path to something
> where symbols don’t exist and then doing a reload. Note that bm nt!* isn’t
> going to work even if you have valid symbols. The target kernel only
> supports 32 breakpoints and there are many routines in the kernel that it
> isn’t safe to set breakpoints on, so a blanket bm nt!* is not a good thing
> to try.
>

i see i asked the question after i tried it that way
here is an output i erased the _nt_symbol_path in
mycomp->properties->environ
removed the -y in my bat file
and started
windbg -k com:pipe,port=\.\pipe\debugPipe,resets=0,reconnect

paste follows

Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \.\pipe\debugPipe <file:>
Waiting to reconnect…
Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: Invalid

Symbol loading may be unreliable without a symbol search path.
Use .symfix to have the debugger choose a symbol path.
After setting your symbol path, use .reload to refresh symbol locations.

Executable search path is:

Symbols can not be loaded because symbol path is not initialized.

The Symbol Path can be set by:
using the _NT_SYMBOL_PATH environment variable.
using the -y <symbol_path> argument when starting the debugger.
using .sympath and .sympath+

*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntoskrnl.exe -
Windows 2000 Kernel Version 2195 UP Free x86 compatible
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e1b8
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
8045647c cc int 3
kd> bm nt!*
2: 80400683 @!“nt!ExInterlockedAddLargeStatistic”
3: 8040068b @!“nt!ExfInterlockedAddUlong”
4: 80400698 @!“nt!ExfInterlockedInsertHeadList”
5: 804006b0 @!“nt!ExfInterlockedInsertTailList”
6: 804006cc @!“nt!ExfInterlockedRemoveHeadList”
7: 804006e4 @!“nt!ExfInterlockedPopEntryList”
8: 804006f8 @!“nt!ExfInterlockedPushEntryList”
9: 80400704 @!“nt!ExInterlockedPopEntrySList”
10: 80400728 @!“nt!ExInterlockedPushEntrySList”
11: 8040074c @!“nt!ExInterlockedFlushSList”
12: 804007ac @!“nt!Exfi386InterlockedIncrementLong”
13: 804007b8 @!“nt!Exfi386InterlockedDecrementLong”
14: 804007c4 @!“nt!InterlockedExchange”
breakpoint 14 redefined
14: 804007c4 @!“nt!Exfi386InterlockedExchangeUlong”
15: 804007cc @!“nt!InterlockedIncrement”
<---------------------snipped all the function displayed in between
---------->

1196: 805112a0 @!“nt!SeRegisterLogonSessionTerminatedRoutine”
1197: 80511337 @!“nt!SeUnregisterLogonSessionTerminatedRoutine”
1198: 805113ce @!“nt!SeMarkLogonSessionForTerminationNotification”
1199: 805116b2 @!“nt!SeTokenIsAdmin”
1200: 80512dae @!“nt!NtVdmControl”
1201: 80515326 @!“nt!IoWMIRegistrationControl”
1202: 80515440 @!“nt!IoWMIAllocateInstanceIds”
1203: 80515548 @!“nt!IoWMISuggestInstanceName”
1204: 805507a4 @!“nt!IoReportHalResourceUsage”
1205: 805594ec @!“nt!KeFindConfigurationEntry”
1206: 8055950e @!“nt!KeFindConfigurationNextEntry”
kd> bl
0 e 8045647c 0001 (0001) nt!DbgBreakPoint
2 e 80400683 0001 (0001) nt!ExInterlockedAddLargeStatistic
3 e 8040068b 0001 (0001) nt!ExfInterlockedAddUlong
4 e 80400698 0001 (0001) nt!ExfInterlockedInsertHeadList
5 e 804006b0 0001 (0001) nt!ExfInterlockedInsertTailList
6 e 804006cc 0001 (0001) nt!ExfInterlockedRemoveHeadList
7 e 804006e4 0001 (0001) nt!ExfInterlockedPopEntryList
8 e 804006f8 0001 (0001) nt!ExfInterlockedPushEntryList
9 e 80400704 0001 (0001) nt!ExInterlockedPopEntrySList
10 e 80400728 0001 (0001) nt!ExInterlockedPushEntrySList
11 e 8040074c 0001 (0001) nt!ExInterlockedFlushSList
12 e 804007ac 0001 (0001) nt!Exfi386InterlockedIncrementLong
13 e 804007b8 0001 (0001) nt!Exfi386InterlockedDecrementLong
14 e 804007c4 0001 (0001) nt!Exfi386InterlockedExchangeUlong

1196 e 805112a0 0001 (0001) nt!SeRegisterLogonSessionTerminatedRoutine
1197 e 80511337 0001 (0001) nt!SeUnregisterLogonSessionTerminatedRoutine
1198 e 805113ce 0001 (0001)
nt!SeMarkLogonSessionForTerminationNotification
1199 e 805116b2 0001 (0001) nt!SeTokenIsAdmin
1200 e 80512dae 0001 (0001) nt!NtVdmControl
1201 e 80515326 0001 (0001) nt!IoWMIRegistrationControl
1202 e 80515440 0001 (0001) nt!IoWMIAllocateInstanceIds
1203 e 80515548 0001 (0001) nt!IoWMISuggestInstanceName
1204 e 805507a4 0001 (0001) nt!IoReportHalResourceUsage
1205 e 805594ec 0001 (0001) nt!KeFindConfigurationEntry
1206 e 8055950e 0001 (0001) nt!KeFindConfigurationNextEntry

tracing with so many unresolved break points ended up being horribly slow
so when i traced i used bd * and when i ran i did be *

i dont know if there were only 32 break points supported then probably i
missed many of the breaks

i saw bp 4 ,8 ,26 hit in my dumb experiments lasting a few hours
this one i recall breaking
9: 80400704 @!“nt!ExInterlockedPopEntrySList”

regards

raj_r</symbol_path></file:>

[raj_r]

On 10/23/06, Drew Bliss wrote:
>
>
> The key thing to look for is the “shutdown occurred” message, which means
> that kd.exe was notified that the target is rebooting. If you don’t get
> that message then kd is still waiting for a normal response from the
> target. If the target is also stuck it’s most likely dead.
>

i managed to find a log of one occurance of it

here is the details like i said in my previous post there arent any
shutdown occured messages

kd> k
ChildEBP RetAddr
80473af0 80559935 nt!ExpInitializeExecutive+0xf0
80473b4c 80558cc5 nt!Ki386EnableCurrentLargePageEnd+0x398
00000000 00000000 nt!KiSystemStartup+0x369
kd> p
nt!ExpInitializeExecutive+0xf2:
8054ef6e 7507 jne nt!ExpInitializeExecutive+0xfb (8054ef77)
kd> p
nt!ExpInitializeExecutive+0xf4:
8054ef70 6a5c push 5Ch
kd> p
nt!ExpInitializeExecutive+0xf6:
8054ef72 e8fdd3edff call nt!KeBugCheck (8042c374)
kd> p

Fatal System Error: 0x0000005c
(0x00000000,0x00000000,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
…
Loading User Symbols

************************************************************************


Bugcheck
Analysis


*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 5C, {0, 0, 0, 0}

thats it it becomes busy after this and stays busy

regards

raj_r

[OSR_Community_User]

You have to modify settings on the target to enable boot debugging. For
examaple, on Vista you’d need to ask for boot debugging with bcdedit.
In the past you also needed a special loader, but I’m not sure about
Vista.

The dump I was asking about was a dump of windbg once it got stuck. We
can then determine why it’s stuck and if there’s anything we can do
about it.

When using bm nt!* you’ll only actually get breakpoints on the first 32
routines.

---

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Monday, October 23, 2006 11:12 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Break on first module load

On 10/23/06, Drew Bliss wrote:

The boot loader is the piece of code which loads initial drivers
for booting the OS. It does offer a debugging connection via kd (serial
only).

Thanks for the information ill have to gather more information before i
could try and ask a few sensible questions i just have one dumb question
at this moment you emphasize serial only so does that mean
i cant check with my present way of working ?
viz windbg -k com:pipe,port=\.\pipe\debugPipe,resets=0,reconnect

The biggest risk of stepping over KeBugCheck is that, since it’s
a no-return function, that you’re going to have a breakpoint on whatever
piece of code follows KeBugCheck. Breakpoints on some system functions
aren’t supported since the code is used by kd itself, thus they can be
dangerous. The bugcheck with STATUS_BREAKPOINT looks suspiciously like
this kind of thing. If !analyze doesn’t complete it may be looking for
something else; if it doesn’t complete in an hour or so you can capture
a full dump of the windbg process and send that to
xxxxx@microsoft.com.

The key thing to look for is the “shutdown occurred” message,
which means that kd.exe was notified that the target is rebooting. If
you don’t get that message then kd is still waiting for a normal
response from the target. If the target is also stuck it’s most likely
dead.

i dont recall seeing the shutdown occured
all symbols are being flushed
error dos rtnl_somecrap
<--------snip------------ from my memory quotes>
waiting to reconnect

messages

i think it abrupty went into fatal system error occured messages and
stayed busy there

ill check it again and if it didnt respond within an hour or so ill try
to capture the process

btw if you could possibly explain how i can dump the entire memory
does it mean i crash my host somehow and create a full kernel memory
dump in my host pc ? that would be helpfull

You can force exported symbols by setting your symbol path to
something where symbols don’t exist and then doing a reload. Note that
bm nt!* isn’t going to work even if you have valid symbols. The target
kernel only supports 32 breakpoints and there are many routines in the
kernel that it isn’t safe to set breakpoints on, so a blanket bm nt!* is
not a good thing to try.

i see i asked the question after i tried it that way
here is an output i erased the _nt_symbol_path in
mycomp->properties->environ
removed the -y in my bat file
and started
windbg -k com:pipe,port=\.\pipe\debugPipe,resets=0,reconnect

paste follows

Microsoft (R) Windows Debugger Version 6.6.0007.5
Copyright (c) Microsoft Corporation. All rights reserved.

Opened \.\pipe\debugPipe <file:>
Waiting to reconnect…
Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: Invalid
***************************************************************

Symbol loading may be unreliable without a symbol search path.

Use .symfix to have the debugger choose a symbol path.

After setting your symbol path, use .reload to refresh symbol
locations. *
***************************************************************

Executable search path is:

Symbols can not be loaded because symbol path is not initialized.

The Symbol Path can be set by:
using the _NT_SYMBOL_PATH environment variable.
using the -y <symbol_path> argument when starting the debugger.
using .sympath and .sympath+ *

ERROR: Symbol file could not be found. Defaulted to export symbols
for ntoskrnl.exe -
Windows 2000 Kernel Version 2195 UP Free x86 compatible
Kernel base = 0x80400000 PsLoadedModuleList = 0x8046e1b8
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
8045647c cc int 3
kd> bm nt!
2: 80400683 @!“nt!ExInterlockedAddLargeStatistic”
3: 8040068b @!“nt!ExfInterlockedAddUlong”
4: 80400698 @!“nt!ExfInterlockedInsertHeadList”
5: 804006b0 @!“nt!ExfInterlockedInsertTailList”
6: 804006cc @!“nt!ExfInterlockedRemoveHeadList”
7: 804006e4 @!“nt!ExfInterlockedPopEntryList”
8: 804006f8 @!“nt!ExfInterlockedPushEntryList”
9: 80400704 @!“nt!ExInterlockedPopEntrySList”
10: 80400728 @!“nt!ExInterlockedPushEntrySList”
11: 8040074c @!“nt!ExInterlockedFlushSList”
12: 804007ac @!“nt!Exfi386InterlockedIncrementLong”
13: 804007b8 @!“nt!Exfi386InterlockedDecrementLong”
14: 804007c4 @!“nt!InterlockedExchange”
breakpoint 14 redefined
14: 804007c4 @!“nt!Exfi386InterlockedExchangeUlong”
15: 804007cc @!“nt!InterlockedIncrement”
<---------------------snipped all the function displayed in between
---------->

1196: 805112a0 @!“nt!SeRegisterLogonSessionTerminatedRoutine”
1197: 80511337 @!“nt!SeUnregisterLogonSessionTerminatedRoutine”
1198: 805113ce @!“nt!SeMarkLogonSessionForTerminationNotification”
1199: 805116b2 @!“nt!SeTokenIsAdmin”
1200: 80512dae @!“nt!NtVdmControl”
1201: 80515326 @!“nt!IoWMIRegistrationControl”
1202: 80515440 @!“nt!IoWMIAllocateInstanceIds”
1203: 80515548 @!“nt!IoWMISuggestInstanceName”
1204: 805507a4 @!“nt!IoReportHalResourceUsage”
1205: 805594ec @!“nt!KeFindConfigurationEntry”
1206: 8055950e @!“nt!KeFindConfigurationNextEntry”
kd> bl
0 e 8045647c 0001 (0001) nt!DbgBreakPoint
2 e 80400683 0001 (0001) nt!ExInterlockedAddLargeStatistic
3 e 8040068b 0001 (0001) nt!ExfInterlockedAddUlong
4 e 80400698 0001 (0001) nt!ExfInterlockedInsertHeadList
5 e 804006b0 0001 (0001) nt!ExfInterlockedInsertTailList
6 e 804006cc 0001 (0001) nt!ExfInterlockedRemoveHeadList
7 e 804006e4 0001 (0001) nt!ExfInterlockedPopEntryList
8 e 804006f8 0001 (0001) nt!ExfInterlockedPushEntryList
9 e 80400704 0001 (0001) nt!ExInterlockedPopEntrySList
10 e 80400728 0001 (0001) nt!ExInterlockedPushEntrySList
11 e 8040074c 0001 (0001) nt!ExInterlockedFlushSList
12 e 804007ac 0001 (0001) nt!Exfi386InterlockedIncrementLong
13 e 804007b8 0001 (0001) nt!Exfi386InterlockedDecrementLong
14 e 804007c4 0001 (0001) nt!Exfi386InterlockedExchangeUlong

1196 e 805112a0 0001 (0001)
nt!SeRegisterLogonSessionTerminatedRoutine
1197 e 80511337 0001 (0001)
nt!SeUnregisterLogonSessionTerminatedRoutine
1198 e 805113ce 0001 (0001)
nt!SeMarkLogonSessionForTerminationNotification
1199 e 805116b2 0001 (0001) nt!SeTokenIsAdmin
1200 e 80512dae 0001 (0001) nt!NtVdmControl
1201 e 80515326 0001 (0001) nt!IoWMIRegistrationControl
1202 e 80515440 0001 (0001) nt!IoWMIAllocateInstanceIds
1203 e 80515548 0001 (0001) nt!IoWMISuggestInstanceName
1204 e 805507a4 0001 (0001) nt!IoReportHalResourceUsage
1205 e 805594ec 0001 (0001) nt!KeFindConfigurationEntry
1206 e 8055950e 0001 (0001) nt!KeFindConfigurationNextEntry

tracing with so many unresolved break points ended up being horribly
slow
so when i traced i used bd * and when i ran i did be *

i dont know if there were only 32 break points supported then probably i
missed many of the breaks

i saw bp 4 ,8 ,26 hit in my dumb experiments lasting a few hours
this one i recall breaking
9: 80400704 @!“nt!ExInterlockedPopEntrySList”

regards

raj_r

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

[OSR_Community_User]

The behavior below is expected up to where !analyze sticks. KeBugCheck
generates new debug events, so it’s normal that the debugger will break
in for the bugcheck. !analyze then runs automatically to try and
diagnose the bugcheck. It shouldn’t hang indefinitely; if you can send
a dump of windbg when !analyze is busy we can check it out.

---

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Monday, October 23, 2006 12:50 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Break on first module load

On 10/23/06, Drew Bliss wrote:

The key thing to look for is the “shutdown occurred” message,
which means that kd.exe was notified that the target is rebooting. If
you don’t get that message then kd is still waiting for a normal
response from the target. If the target is also stuck it’s most likely
dead.

i managed to find a log of one occurance of it

here is the details like i said in my previous post there arent any
shutdown occured messages

kd> k
ChildEBP RetAddr
80473af0 80559935 nt!ExpInitializeExecutive+0xf0
80473b4c 80558cc5 nt!Ki386EnableCurrentLargePageEnd+0x398
00000000 00000000 nt!KiSystemStartup+0x369
kd> p
nt!ExpInitializeExecutive+0xf2:
8054ef6e 7507 jne nt!ExpInitializeExecutive+0xfb
(8054ef77)
kd> p
nt!ExpInitializeExecutive+0xf4:
8054ef70 6a5c push 5Ch
kd> p
nt!ExpInitializeExecutive+0xf6:
8054ef72 e8fdd3edff call nt!KeBugCheck (8042c374)
kd> p

Fatal System Error: 0x0000005c
(0x00000000,0x00000000,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
…
Loading User Symbols





Bugcheck Analysis



**
*******

Use !analyze -v to get detailed debugging information.

BugCheck 5C, {0, 0, 0, 0}

thats it it becomes busy after this and stays busy

regards

raj_r

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

[raj_r]

On 10/24/06, Drew Bliss wrote:
>
> The behavior below is expected up to where !analyze sticks. KeBugCheck
> generates new debug events, so it’s normal that the debugger will break in
> for the bugcheck. !analyze then runs automatically to try and diagnose the
> bugcheck. It shouldn’t hang indefinitely; if you can send a dump of windbg
> when !analyze is busy we can check it out
>

i dont have the same setup today and i havent done what i did that day

but just to confirm i simply changed the zero flag on the check to see
if i could reproduce it without having to go through all the troubles

but i cant reproduce the behaviour now kd simply gets back to work
normally in 10 seconds today )

so i think i ll have run through the hoops again if i am to find that queer
behaviour

any way for future referance could you please tell me how i dump the hanged
windbg process in host so that if i encounter it again ill produce a dump
that i can send it to the mail address in previous post

regards

raj_r

ps i am pasting todays succesfull return just for referance purposes

kd> p
nt!ExpInitializeExecutive+0xf0:
8054ef6c 84c0 test al,al
kd> p
Breakpoint 0 hit
nt!ExpInitializeExecutive+0xf2:
8054ef6e 7507 jne nt!ExpInitializeExecutive+0xfb (8054ef77)
kd> zf =1
kd> zf = 0
kd> r zf =1
kd> t
nt!ExpInitializeExecutive+0xf4:
8054ef70 6a5c push 5Ch
kd> t
nt!ExpInitializeExecutive+0xf6:
8054ef72 e8fdd3edff call nt!KeBugCheck (8042c374)
kd> p

Fatal System Error: 0x0000005c
(0x00000000,0x00000000,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
…
Loading User Symbols




Bugcheck
Analysis




Use !analyze -v to get detailed debugging information.

BugCheck 5C, {0, 0, 0, 0}

Probably caused by : ntoskrnl.exe ( nt!ExpInitializeExecutive+fb )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
80456488 cc int 3
kd> !analyze -v
********************************************************************


Bugcheck
Analysis


*******************************************************************************

HAL_INITIALIZATION_FAILED (5c)
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x5C

LAST_CONTROL_TRANSFER: from 8042c507 to 80456488

STACK_TEXT:
804734c8 8042c507 00000003 80473510 00000000
nt!RtlpBreakWithStatusInstruction
804734f8 8042c8cb 00000003 8001f218 80477a00 nt!KiBugCheckDebugBreak+0x31
80473884 8042c383 0000005c 00000000 00000000 nt!KeBugCheckEx+0x390
8047389c 8054ef77 0000005c 8046fbc0 ffdff120 nt!KeBugCheck+0xf
80473af0 80559935 00000000 80087000 80036c00 nt!ExpInitializeExecutive+0xfb
80473b4c 80558cc5 8046f930 8046fbc0 80473e10
nt!Ki386EnableCurrentLargePageEnd+0x398
00000000 00000000 00000000 00000000 00000000 nt!KiSystemStartup+0x369

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ExpInitializeExecutive+fb
8054ef77 6a01 push 1

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!ExpInitializeExecutive+fb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3ee6c002

FAILURE_BUCKET_ID: 0x5C_nt!ExpInitializeExecutive+fb

BUCKET_ID: 0x5C_nt!ExpInitializeExecutive+fb

Followup: MachineOwner
---------

kd> bl
0 e 8054ef6e 0001 (0001) nt!ExpInitializeExecutive+0xf2

[OSR_Community_User]

In order to create a dump of windbg on the host do this:

<debuggers_dir>\ntsd -pv -pn windbg.exe -c “.dump /ma
<local_file_name>;q”

That will attach an ntsd to the windbg instance (assuming you only have
one running), capture a dump of it and then quit.

________________________________

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Tuesday, October 24, 2006 10:49 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] Break on first module load

On 10/24/06, Drew Bliss wrote:

The behavior below is expected up to where !analyze sticks.
KeBugCheck generates new debug events, so it’s normal that the debugger
will break in for the bugcheck. !analyze then runs automatically to try
and diagnose the bugcheck. It shouldn’t hang indefinitely; if you can
send a dump of windbg when !analyze is busy we can check it out

i dont have the same setup today and i havent done what i did that day

but just to confirm i simply changed the zero flag on the check to see
if i could reproduce it without having to go through all the troubles

but i cant reproduce the behaviour now kd simply gets back to work
normally in 10 seconds today )

so i think i ll have run through the hoops again if i am to find that
queer
behaviour

any way for future referance could you please tell me how i dump the
hanged windbg process in host so that if i encounter it again ill
produce a dump that i can send it to the mail address in previous post

regards

raj_r

ps i am pasting todays succesfull return just for referance purposes

kd> p
nt!ExpInitializeExecutive+0xf0:
8054ef6c 84c0 test al,al
kd> p
Breakpoint 0 hit
nt!ExpInitializeExecutive+0xf2:
8054ef6e 7507 jne nt!ExpInitializeExecutive+0xfb
(8054ef77)
kd> zf =1
kd> zf = 0
kd> r zf =1
kd> t
nt!ExpInitializeExecutive+0xf4:
8054ef70 6a5c push 5Ch
kd> t
nt!ExpInitializeExecutive+0xf6:
8054ef72 e8fdd3edff call nt!KeBugCheck (8042c374)
kd> p

Fatal System Error: 0x0000005c
(0x00000000,0x00000000,0x00000000,0x00000000)

Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols
…
Loading User Symbols





Bugcheck Analysis



**


Use !analyze -v to get detailed debugging information.

BugCheck 5C, {0, 0, 0, 0}

Probably caused by : ntoskrnl.exe ( nt!ExpInitializeExecutive+fb )

Followup: MachineOwner
---------

nt!RtlpBreakWithStatusInstruction:
80456488 cc int 3
kd> !analyze -v




Bugcheck Analysis



******
*******

HAL_INITIALIZATION_FAILED (5c)
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:
------------------

DEFAULT_BUCKET_ID: INTEL_CPU_MICROCODE_ZERO

BUGCHECK_STR: 0x5C

LAST_CONTROL_TRANSFER: from 8042c507 to 80456488

STACK_TEXT:
804734c8 8042c507 00000003 80473510 00000000
nt!RtlpBreakWithStatusInstruction
804734f8 8042c8cb 00000003 8001f218 80477a00
nt!KiBugCheckDebugBreak+0x31
80473884 8042c383 0000005c 00000000 00000000 nt!KeBugCheckEx+0x390
8047389c 8054ef77 0000005c 8046fbc0 ffdff120 nt!KeBugCheck+0xf
80473af0 80559935 00000000 80087000 80036c00
nt!ExpInitializeExecutive+0xfb
80473b4c 80558cc5 8046f930 8046fbc0 80473e10
nt!Ki386EnableCurrentLargePageEnd+0x398
00000000 00000000 00000000 00000000 00000000 nt!KiSystemStartup+0x369

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ExpInitializeExecutive+fb
8054ef77 6a01 push 1

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!ExpInitializeExecutive+fb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3ee6c002

FAILURE_BUCKET_ID: 0x5C_nt!ExpInitializeExecutive+fb

BUCKET_ID: 0x5C_nt!ExpInitializeExecutive+fb

Followup: MachineOwner
---------

kd> bl
0 e 8054ef6e 0001 (0001) nt!ExpInitializeExecutive+0xf2

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

[raj_r]

On 10/25/06, Drew Bliss wrote:
>
> In order to create a dump of windbg on the host do this:
>
> <debuggers_dir>\ntsd -pv -pn windbg.exe -c “.dump /ma
> <local_file_name>;q”
>
> That will attach an ntsd to the windbg instance (assuming you only have
> one running), capture a dump of it and then quit
>

Thanks a Lot

I have one more busy sequence which i havent tried to reproduce yet
so may be its a dud behaviour so sorry if its waste of your time reading
this post

i set a ba r 4 break on nt!KdDebuggerNotPresent

it seems kd itself is using it

so kd broke twice here i cleared the break point and then ran
and the cursor again turned busy

in one of the thread i saw you advisng some one to do ctrl+alt+d to see if
there are any resend spews and i tried to see if ctrl+alt+d displays
anything in this sequnce

and i see the output below

7 e 80475ab0 r 4 0001 (0001) nt!KdDebuggerNotPresent
8 e 80475ab4 r 4 0001 (0001) nt!KdDebuggerEnabled

kd> g
Breakpoint 7 hit
nt!KdpReceivePacketLeader+0x9a:
80538134 a0d402dfff mov al,byte ptr ds:[FFDF02D4h]
kd> g
Breakpoint 7 hit
nt!KdpReceivePacketLeader+0x9a:
80538134 a0d402dfff mov al,byte ptr ds:[FFDF02D4h]
kd> bc 7
kd> g
READ: Checksum error.
READ: Ask for resend (ackable).
PacketType=3, ByteCount=37, PacketId=80800000,
READ: Checksum error.
READ: Ask for resend (ackable).
PacketType=3, ByteCount=37, PacketId=80800000,
READ: Checksum error.
READ: Ask for resend (ackable).
PacketType=3, ByteCount=37, PacketId=80800000,
READ: Checksum error.
READ: Ask for resend (ackable).

its same output

ctrl+alt+r or ctrl+break doesnt respond

the prompt was busy but this time ctrl+alt+d started spewing this
i couldnt dump the process due to some problems
it stayed busy for about 8 minutes before i reset vpc from its menu
and the same kd became normal again</local_file_name></debuggers_dir>