Searching for the correct stack frame.

WINDBG
1

Hi All,

I am debugging Kernel-mode drivers. I have a situation where a thread in a
sys file calls another sys file, which calls a function in another sys
file. The stack actually gets pretty “Deep” at this point, and somehow
the thread is stuck in a “running” state.

Whenever I do a !thread on it, I can see that it is running state
(0x0000500). However, the stack for that thread notes that the stack frame
may be invalid. And, the only 2 things I see on the stack is the
“DbgBreakPoint” and “KeUpdateSystemTime”. I know there must be at least
10+ function calls on the stack, so I assume hopping from driver to driver,
may get the debugger confused (?).

Anyway, is there a way to search for the stack manually, or see what the
last instruction that executed in that thread was, so I can see where the
deadloop is? I tried to look into the “Current” stack location given by
the !thread command, but it does not seem to be accurate for the thread (?)

Thanks!

2

You can manually provide the EBP, EIP and ESP to the “kv” command in WinDBG
(funny thing is that I had to show people how to do this last week in debug
class because we had a stack with a driver where they did not have symbols.)

You can also use the “!kdex2x86.stack” command (on NT 4.0 and W2K) and it
will provide you with every possible stack frame that it can find on the
stack - but realize it may show you garbage as well, since the stack is
re-used. However, it can be an excellent tool for finding a clean stack
frame that you can use to then feed into the “kv” command.

My technique for doing this is to attempt to find a call instruction (so I
know the EIP) because I can identify the return address (on the stack) and
the EBP (IF the function I called starts with push EBP, which is sometimes
the case). This gives me the EBP (the value following the return address)
the ESP (the address where the return address is stored) and the EIP (the
instruction BEFORE the return address, which is going to be a call).

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@conexant.com [mailto:xxxxx@conexant.com]
Sent: Friday, August 09, 2002 6:06 PM
To: Kernel Debugging Interest List
Subject: [windbg] Searching for the correct stack frame.

Hi All,

I am debugging Kernel-mode drivers. I have a situation where a thread in a
sys file calls another sys file, which calls a function in another sys
file. The stack actually gets pretty “Deep” at this point, and somehow
the thread is stuck in a “running” state.

Whenever I do a !thread on it, I can see that it is running state
(0x0000500). However, the stack for that thread notes that the stack frame
may be invalid. And, the only 2 things I see on the stack is the
“DbgBreakPoint” and “KeUpdateSystemTime”. I know there must be at least
10+ function calls on the stack, so I assume hopping from driver to driver,
may get the debugger confused (?).

Anyway, is there a way to search for the stack manually, or see what the
last instruction that executed in that thread was, so I can see where the
deadloop is? I tried to look into the “Current” stack location given by
the !thread command, but it does not seem to be accurate for the thread (?)

Thanks!

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

3

Correct symbols are also required to do an accurate stack walk on x86
code. That is probably what “the stack for that thread notes that the
stack frame may be invalid.” means.

See http://www.microsoft.com/ddk/debugging on how to get OS symbols.

As Tony pointed out the k* commands can take parameters to use to start
a stack walk. That can be useful to skip sections of the stack that are
corrupted or skip a section with bad symbols.

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Friday, August 09, 2002 4:15 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Searching for the correct stack frame.

You can manually provide the EBP, EIP and ESP to the “kv” command in
WinDBG (funny thing is that I had to show people how to do this last
week in debug class because we had a stack with a driver where they did
not have symbols.)

You can also use the “!kdex2x86.stack” command (on NT 4.0 and W2K) and
it will provide you with every possible stack frame that it can find on
the stack - but realize it may show you garbage as well, since the stack
is re-used. However, it can be an excellent tool for finding a clean
stack frame that you can use to then feed into the “kv” command.

My technique for doing this is to attempt to find a call instruction (so
I know the EIP) because I can identify the return address (on the stack)
and the EBP (IF the function I called starts with push EBP, which is
sometimes the case). This gives me the EBP (the value following the
return address) the ESP (the address where the return address is stored)
and the EIP (the instruction BEFORE the return address, which is going
to be a call).

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@conexant.com [mailto:xxxxx@conexant.com]
Sent: Friday, August 09, 2002 6:06 PM
To: Kernel Debugging Interest List
Subject: [windbg] Searching for the correct stack frame.

Hi All,

I am debugging Kernel-mode drivers. I have a situation where a thread
in a sys file calls another sys file, which calls a function in another
sys
file. The stack actually gets pretty “Deep” at this point, and somehow
the thread is stuck in a “running” state.

Whenever I do a !thread on it, I can see that it is running state
(0x0000500). However, the stack for that thread notes that the stack
frame may be invalid. And, the only 2 things I see on the stack is the
“DbgBreakPoint” and “KeUpdateSystemTime”. I know there must be at
least
10+ function calls on the stack, so I assume hopping from driver to
10+ driver,
may get the debugger confused (?).

Anyway, is there a way to search for the stack manually, or see what the
last instruction that executed in that thread was, so I can see where
the
deadloop is? I tried to look into the “Current” stack location given
by
the !thread command, but it does not seem to be accurate for the thread
(?)

Thanks!

You are currently subscribed to windbg as: xxxxx@osr.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%%

4

Nathan,

Why are correct symbols required for an accurate stack walk? I
understand that using incorrect symbols leads to misinformation in the
symbol column of a stack trace, but I expect the stack frames
themselves to be ok. I guess I just don’t understand the link between
symbols and a valid stack trace. For example, I would expect that if
there is a command to dump the stack without trying to resolve symbols,
I could get a stack trace that does not have the “stack unwind below
this point may be incorrect” messages.

Thanks,
Dave

Nathan Nesbit wrote:

Correct symbols are also required to do an accurate stack walk on x86
code. That is probably what “the stack for that thread notes that the
stack frame may be invalid.” means.

See http://www.microsoft.com/ddk/debugging on how to get OS symbols.

As Tony pointed out the k* commands can take parameters to use to start
a stack walk. That can be useful to skip sections of the stack that are
corrupted or skip a section with bad symbols.

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Friday, August 09, 2002 4:15 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Searching for the correct stack frame.

You can manually provide the EBP, EIP and ESP to the “kv” command in
WinDBG (funny thing is that I had to show people how to do this last
week in debug class because we had a stack with a driver where they did
not have symbols.)

You can also use the “!kdex2x86.stack” command (on NT 4.0 and W2K) and
it will provide you with every possible stack frame that it can find on
the stack - but realize it may show you garbage as well, since the stack
is re-used. However, it can be an excellent tool for finding a clean
stack frame that you can use to then feed into the “kv” command.

My technique for doing this is to attempt to find a call instruction (so
I know the EIP) because I can identify the return address (on the stack)
and the EBP (IF the function I called starts with push EBP, which is
sometimes the case). This gives me the EBP (the value following the
return address) the ESP (the address where the return address is stored)
and the EIP (the instruction BEFORE the return address, which is going
to be a call).

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@conexant.com [mailto:xxxxx@conexant.com]
Sent: Friday, August 09, 2002 6:06 PM
To: Kernel Debugging Interest List
Subject: [windbg] Searching for the correct stack frame.

Hi All,

I am debugging Kernel-mode drivers. I have a situation where a thread
in a sys file calls another sys file, which calls a function in another
sys
file. The stack actually gets pretty “Deep” at this point, and somehow
the thread is stuck in a “running” state.

Whenever I do a !thread on it, I can see that it is running state
(0x0000500). However, the stack for that thread notes that the stack
frame may be invalid. And, the only 2 things I see on the stack is the
“DbgBreakPoint” and “KeUpdateSystemTime”. I know there must be at
least
10+ function calls on the stack, so I assume hopping from driver to
10+ driver,
may get the debugger confused (?).

Anyway, is there a way to search for the stack manually, or see what the
last instruction that executed in that thread was, so I can see where
the
deadloop is? I tried to look into the “Current” stack location given
by
the !thread command, but it does not seem to be accurate for the thread
(?)

Thanks!

You are currently subscribed to windbg as: xxxxx@osr.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@okena.com
To unsubscribe send a blank email to %%email.unsub%%

5

I’ll jump in here (since I talk about this in the debug class, having become
well-versed in this from discussions and talks with Andre).

The problem is that on the X86 there is this little thing called “frame
pointer optimization”. In a normal ‘C’ convention calling sequence we see:

call

Which has the effect of pushing EIP onto the stack and then loading the
address of the routine into EIP. The next instruction would (in this
standard convention) then be (in this new routine):

push EBP
mov EBP, ESP

This establishes a new value for the “base pointer”. What this allows is
easy exit from this function (a “mov esp, ebp” and then a “pop ebp”). But
this is not the only way this can be done. Some functions omit this
preamble (the EBP push) and simply plow ahead. SOME functions USE the EBP
as an extra register.

The symbols tell the debugger how the function preamble was constructed, how
much stack space was used, etc. This means the debugger can then unwind the
stack. Without that information, the debugger is left guessing - is the
value in EBP valid? If it isn’t, where does it find the old EBP? How does
it know where the previous call came from? Thus, the debugger warns you (if
it uses the standard EBP calling convention, the debugger will actually
unwind the stack properly) and tries to do its best - but in the presence of
full “frame pointer optimization” it can’t unravel where the call frames are
and thus it bails out.

The technique I described is one where you try to find the frame yourself
and THEN tell the debugger to start there. Given an earlier stack frame,
the debugger will merrily dump these earlier frames.

In my business I see this all the time when someone has Symantec’s
Anti-Virus product installed. This code appears to be compiled with maximum
optimization and distributed without symbols. When it REALLY matters about
finding the whole stack frame, I do it manually and climb up over the call
to the Symantec components. Don’t get me wrong - this isn’t a bug or
problem with the Symantec software, but rather it is just a side-effect of
their optimization technique.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Dave McCowan [mailto:xxxxx@okena.com]
Sent: Monday, August 12, 2002 8:31 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Searching for the correct stack frame.

Nathan,

Why are correct symbols required for an accurate stack walk? I
understand that using incorrect symbols leads to misinformation in the
symbol column of a stack trace, but I expect the stack frames
themselves to be ok. I guess I just don’t understand the link between
symbols and a valid stack trace. For example, I would expect that if
there is a command to dump the stack without trying to resolve symbols,
I could get a stack trace that does not have the “stack unwind below
this point may be incorrect” messages.

Thanks,
Dave

Nathan Nesbit wrote:

>Correct symbols are also required to do an accurate stack walk on x86
>code. That is probably what “the stack for that thread notes that the
>stack frame may be invalid.” means.
>
>See http://www.microsoft.com/ddk/debugging on how to get OS symbols.
>
>As Tony pointed out the k* commands can take parameters to use to start
>a stack walk. That can be useful to skip sections of the stack that are
>corrupted or skip a section with bad symbols.
>
>-----Original Message-----
>From: Tony Mason [mailto:xxxxx@osr.com]
>Sent: Friday, August 09, 2002 4:15 PM
>To: Kernel Debugging Interest List
>Subject: [windbg] RE: Searching for the correct stack frame.
>
>
>You can manually provide the EBP, EIP and ESP to the “kv” command in
>WinDBG (funny thing is that I had to show people how to do this last
>week in debug class because we had a stack with a driver where they did
>not have symbols.)
>
>You can also use the “!kdex2x86.stack” command (on NT 4.0 and W2K) and
>it will provide you with every possible stack frame that it can find on
>the stack - but realize it may show you garbage as well, since the stack
>is re-used. However, it can be an excellent tool for finding a clean
>stack frame that you can use to then feed into the “kv” command.
>
>My technique for doing this is to attempt to find a call instruction (so
>I know the EIP) because I can identify the return address (on the stack)
>and the EBP (IF the function I called starts with push EBP, which is
>sometimes the case). This gives me the EBP (the value following the
>return address) the ESP (the address where the return address is stored)
>and the EIP (the instruction BEFORE the return address, which is going
>to be a call).
>
>Regards,
>
>Tony
>
>Tony Mason
>Consulting Partner
>OSR Open Systems Resources, Inc.
>http://www.osr.com
>
>
>-----Original Message-----
>From: xxxxx@conexant.com [mailto:xxxxx@conexant.com]
>Sent: Friday, August 09, 2002 6:06 PM
>To: Kernel Debugging Interest List
>Subject: [windbg] Searching for the correct stack frame.
>
>Hi All,
>
>I am debugging Kernel-mode drivers. I have a situation where a thread
>in a sys file calls another sys file, which calls a function in another
>sys
>file. The stack actually gets pretty “Deep” at this point, and somehow
>the thread is stuck in a “running” state.
>
>Whenever I do a !thread on it, I can see that it is running state
>(0x0000500). However, the stack for that thread notes that the stack
>frame may be invalid. And, the only 2 things I see on the stack is the
>“DbgBreakPoint” and “KeUpdateSystemTime”. I know there must be at
>least
>10+ function calls on the stack, so I assume hopping from driver to
>10+ driver,
>may get the debugger confused (?).
>
>Anyway, is there a way to search for the stack manually, or see what the
>last instruction that executed in that thread was, so I can see where
>the
>deadloop is? I tried to look into the “Current” stack location given
>by
>the !thread command, but it does not seem to be accurate for the thread
>(?)
>
>Thanks!
>
>
>
>
>—
>You are currently subscribed to windbg as: xxxxx@osr.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@okena.com
>To unsubscribe send a blank email to %%email.unsub%%
>
>
>

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

6

Great description of the issue. Thanks

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Monday, August 12, 2002 7:00 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Searching for the correct stack frame.

I’ll jump in here (since I talk about this in the debug class, having
become well-versed in this from discussions and talks with Andre).

The problem is that on the X86 there is this little thing called “frame
pointer optimization”. In a normal ‘C’ convention calling sequence we
see:

call

Which has the effect of pushing EIP onto the stack and then loading the
address of the routine into EIP. The next instruction would (in this
standard convention) then be (in this new routine):

push EBP
mov EBP, ESP

This establishes a new value for the “base pointer”. What this allows
is easy exit from this function (a “mov esp, ebp” and then a “pop ebp”).
But this is not the only way this can be done. Some functions omit this
preamble (the EBP push) and simply plow ahead. SOME functions USE the
EBP as an extra register.

The symbols tell the debugger how the function preamble was constructed,
how much stack space was used, etc. This means the debugger can then
unwind the stack. Without that information, the debugger is left
guessing - is the value in EBP valid? If it isn’t, where does it find
the old EBP? How does it know where the previous call came from? Thus,
the debugger warns you (if it uses the standard EBP calling convention,
the debugger will actually unwind the stack properly) and tries to do
its best - but in the presence of full “frame pointer optimization” it
can’t unravel where the call frames are and thus it bails out.

The technique I described is one where you try to find the frame
yourself and THEN tell the debugger to start there. Given an earlier
stack frame, the debugger will merrily dump these earlier frames.

In my business I see this all the time when someone has Symantec’s
Anti-Virus product installed. This code appears to be compiled with
maximum optimization and distributed without symbols. When it REALLY
matters about finding the whole stack frame, I do it manually and climb
up over the call to the Symantec components. Don’t get me wrong - this
isn’t a bug or problem with the Symantec software, but rather it is just
a side-effect of their optimization technique.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: Dave McCowan [mailto:xxxxx@okena.com]
Sent: Monday, August 12, 2002 8:31 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Searching for the correct stack frame.

Nathan,

Why are correct symbols required for an accurate stack walk? I
understand that using incorrect symbols leads to misinformation in the
symbol column of a stack trace, but I expect the stack frames
themselves to be ok. I guess I just don’t understand the link between
symbols and a valid stack trace. For example, I would expect that if
there is a command to dump the stack without trying to resolve symbols,
I could get a stack trace that does not have the “stack unwind below
this point may be incorrect” messages.

Thanks,
Dave

Nathan Nesbit wrote:

>Correct symbols are also required to do an accurate stack walk on x86
>code. That is probably what “the stack for that thread notes that the
>stack frame may be invalid.” means.
>
>See http://www.microsoft.com/ddk/debugging on how to get OS symbols.
>
>As Tony pointed out the k* commands can take parameters to use to start

>a stack walk. That can be useful to skip sections of the stack that
>are corrupted or skip a section with bad symbols.
>
>-----Original Message-----
>From: Tony Mason [mailto:xxxxx@osr.com]
>Sent: Friday, August 09, 2002 4:15 PM
>To: Kernel Debugging Interest List
>Subject: [windbg] RE: Searching for the correct stack frame.
>
>
>You can manually provide the EBP, EIP and ESP to the “kv” command in
>WinDBG (funny thing is that I had to show people how to do this last
>week in debug class because we had a stack with a driver where they did

>not have symbols.)
>
>You can also use the “!kdex2x86.stack” command (on NT 4.0 and W2K) and
>it will provide you with every possible stack frame that it can find on

>the stack - but realize it may show you garbage as well, since the
>stack is re-used. However, it can be an excellent tool for finding a
>clean stack frame that you can use to then feed into the “kv” command.
>
>My technique for doing this is to attempt to find a call instruction
>(so I know the EIP) because I can identify the return address (on the
>stack) and the EBP (IF the function I called starts with push EBP,
>which is sometimes the case). This gives me the EBP (the value
>following the return address) the ESP (the address where the return
>address is stored) and the EIP (the instruction BEFORE the return
>address, which is going to be a call).
>
>Regards,
>
>Tony
>
>Tony Mason
>Consulting Partner
>OSR Open Systems Resources, Inc.
>http://www.osr.com
>
>
>-----Original Message-----
>From: xxxxx@conexant.com [mailto:xxxxx@conexant.com]
>Sent: Friday, August 09, 2002 6:06 PM
>To: Kernel Debugging Interest List
>Subject: [windbg] Searching for the correct stack frame.
>
>Hi All,
>
>I am debugging Kernel-mode drivers. I have a situation where a thread
>in a sys file calls another sys file, which calls a function in another

>sys
>file. The stack actually gets pretty “Deep” at this point, and
somehow
>the thread is stuck in a “running” state.
>
>Whenever I do a !thread on it, I can see that it is running state
>(0x0000500). However, the stack for that thread notes that the stack
>frame may be invalid. And, the only 2 things I see on the stack is the
>“DbgBreakPoint” and “KeUpdateSystemTime”. I know there must be at
>least
>10+ function calls on the stack, so I assume hopping from driver to
>10+ driver,
>may get the debugger confused (?).
>
>Anyway, is there a way to search for the stack manually, or see what
>the last instruction that executed in that thread was, so I can see
>where the
>deadloop is? I tried to look into the “Current” stack location given
>by
>the !thread command, but it does not seem to be accurate for the thread
>(?)
>
>Thanks!
>
>
>
>
>—
>You are currently subscribed to windbg as: xxxxx@osr.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@okena.com
>To unsubscribe send a blank email to %%email.unsub%%
>
>
>

—
You are currently subscribed to windbg as: xxxxx@osr.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%%

7

> But this is not the only way this can be done. Some functions omit this

preamble (the EBP push) and simply plow ahead. SOME functions USE the
EBP as an extra register.

SOME compilers don’t even clear up the stack after each function call,
instead waiting until the return of the function (or end of a loop) to
do that. Makes it even MORE interesting to walk the stack. Although
some of that cruft might be a useful historical record for those really
tough bugs :slight_smile:

Sometimes I really wish there was a simple scripting language built-in,
because I know what proper stack frames look like, but I can’t
describe it to the debugger in an automated way. Thus, I have to page
through the stack of some function that allocates an array[300] of
pointers, and pick out the actual frame start. Very tedious.

Cheers,

/ h+

PS: As far as small, fast, light-weight extension languages go, LUA is
hard to beat. If anyone working on a debugger happens to be reading :slight_smile:

8

>Sometimes I really wish there was a simple scripting language built-in,

because I know what proper stack frames look like, but I can’t
describe it to the debugger in an automated way. Thus, I have to page
through the stack of some function that allocates an array[300] of
pointers, and pick out the actual frame start. Very tedious.

The debugger already has a very simple “scripting language”. Not quite
up to this type of task, but useful in some scenerios. See the docs for
the commands “j” and “z” and pseudo-registers.

You can also write you own extension DLLs and have all the processing
power that you can handle in C++. Install the “SDK” option when you
install the debugger to get the .h, .lib and sample code. There is a
little bit of a learning curve, but it’s really not that hard once you
get the hang of it.

-----Original Message-----
From: WinDbg [mailto:xxxxx@mindcontrol.org]
Sent: Monday, August 12, 2002 4:26 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Searching for the correct stack frame.

But this is not the only way this can be done. Some functions omit
this preamble (the EBP push) and simply plow ahead. SOME functions
USE the EBP as an extra register.

SOME compilers don’t even clear up the stack after each function call,
instead waiting until the return of the function (or end of a loop) to
do that. Makes it even MORE interesting to walk the stack. Although
some of that cruft might be a useful historical record for those really
tough bugs :slight_smile:

Sometimes I really wish there was a simple scripting language built-in,
because I know what proper stack frames look like, but I can’t
describe it to the debugger in an automated way. Thus, I have to page
through the stack of some function that allocates an array[300] of
pointers, and pick out the actual frame start. Very tedious.

Cheers,

/ h+

PS: As far as small, fast, light-weight extension languages go, LUA is
hard to beat. If anyone working on a debugger happens to be reading :slight_smile:

You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%

9

Hi all,

Does anyone have Windows XP Service Pack 1 Beta 1 or a link to it? I
tried to get FireWire Debugging working on a Windows XP host but there
was no connection possible. On a Windows .Net Standard server it did
work properly and I hope SP1 under WinXP can help me with this since
.Net is sort of the same as SP1.

Best regards,
Marco.

10

The fix in .Net server won’t make it into WinXP SP1. The Microsoft tech
who was handling my bug report for SP1 said that anyone needing the fix
should file a product support case and have it escalated, requesting a
QFE update. My guess is that a machine manufacturer would have the best
chance of getting the QFE approved.

The problem will be seen by anyone using a newer machine that has no
legacy support such as the new Toshiba Satellite I bought for use a
target debug machine. The problem is the result of the 1394 chipset not
being previously enabled by the ROMBIOS before the HAL loads.

It might be possible to place a boot sector on a floppy disk that has
code to enable the 1394 chip and then load MBR from the hard drive. I
don’t have any specs on the chipset used in my Toshiba so I’m not sure
if it would be feasible or not. This might be especially difficult if
the I/O port for the chip is not in the real-mode address range.

Please keep the group informed if you find additional information. This
problem will be showing up more and more as machines lose legacy
support.

…John

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Marco van
Nieuwenhoven
Sent: Thursday, August 15, 2002 8:22 AM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Searching for the correct stack frame.

Hi all,

Does anyone have Windows XP Service Pack 1 Beta 1 or a link to it? I
tried to get FireWire Debugging working on a Windows XP host but there
was no connection possible. On a Windows .Net Standard server it did
work properly and I hope SP1 under WinXP can help me with this since
.Net is sort of the same as SP1.

Best regards,
Marco.

You are currently subscribed to windbg as: xxxxx@msn.com
To unsubscribe send a blank email to %%email.unsub%%