!process 0 7 and WOW64

WINDBG
1

Hey all,

A large portion of memory dumps I look at are manually initiated in
order to diagnose application hangs and system hangs and usually the
first thing I do is run a script that more or less does a !process 0 7
(however reloads user symbols for each process). Lately I have had the
need to debug 32 bit processes in 64 bit memory dumps and am having some
real problems with the WOW64 user stack decodes since they are not yet
supported by !process/!thread. Hey MSFT guys are there any plans for
this anytime soon? =)

!wow64exts.k chokes on kd 6.6 which I have heard are known issues with
.cxr /f but kd 6.5 seems to work ok when manually using !k however in
the context of a script it seems to always think that the usermode stack
has an esp of 0 and then takes a crap and forgets to set the context
back to amd64 and busts any references to a pseudo register (hence the
.effmach amd64 below).

Walking 32-bit Stack…
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be
wrong.
00000000 00000000 0x0
!k output>

Anyway the below is an attempted hack to get a !process 0 7 type output
with WOW64 usermode stack support.

Any help or comments with this would be greatly appreciated. It has been
pretty frustrating to say the least. =)

Thank in advance,
Chris

************************************ KD SCRIPT
*****************************

$$
$$ Dump entire list of thread stacks
$$

r $t0 = nt!PsActiveProcessHead

.for( r $t1 = poi @$t0; @$t1 != @$t0; r $t1 = poi @$t1 )
{
r? $t2 = #CONTAINING_RECORD(@$t1, nt!_EPROCESS, ActiveProcessLinks)

.process @$t2
.reload /user

r? @$t9 = @$t2->Wow64Process

.if( @$t9 == 0 )
{
!process @$t2 7
}
.else
{
r? $t5 = &@$t2->Pcb.ThreadListHead

!process @$t2 1

.for( r $t6 = poi @$t5; @$t6 != @$t5; r $t6 = poi @$t6 )
{
r? $t7 = #CONTAINING_RECORD(@$t6, nt!_KTHREAD,
ThreadListEntry)

!thread @$t7 2
.printf “Owning Process %p Image:
%16ma\n”, @$t2, @@c++(@$t2->ImageFileName)
.printf “Wait Start TickCount (%05ul ticks) \n”,
@@c++(@$t7->WaitTime)
.printf “Context Switch Count %ul\n”,
@@c++(@$t7->ContextSwitches)
.printf “UserTime (%05ul)\n”,
@@c++(@$t7->UserTime)
.printf “KernelTime (%05ul)\n”,
@@c++(@$t7->KernelTime)

.thread @$t7
!wow64exts.k
.effmach amd64
}
}
}

******************************** END KD SCRIPT
*****************************

2

The answer I got from the WOW team was to use !wow64exts.sw to switch to
32-bit mode to get stacks.

I’m not aware of any plans to have !process/!thread auto-switch the
current machine mode.

Also, do you need to work with 64-bit kernel dumps for application
hangs? If you can get user-mode dumps from a 32-bit tool you’ll only
have to look at the 32-bit state and it’ll be like debugging a regular
x86 system (i.e. much more straightforward).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chris W. Carr
Sent: Thursday, April 06, 2006 6:49 PM
To: Kernel Debugging Interest List
Subject: [windbg] !process 0 7 and WOW64

Hey all,

A large portion of memory dumps I look at are manually initiated in
order to diagnose application hangs and system hangs and usually the
first thing I do is run a script that more or less does a !process 0 7
(however reloads user symbols for each process). Lately I have had the
need to debug 32 bit processes in 64 bit memory dumps and am having some
real problems with the WOW64 user stack decodes since they are not yet
supported by !process/!thread. Hey MSFT guys are there any plans for
this anytime soon? =)

!wow64exts.k chokes on kd 6.6 which I have heard are known issues with
.cxr /f but kd 6.5 seems to work ok when manually using !k however in
the context of a script it seems to always think that the usermode stack
has an esp of 0 and then takes a crap and forgets to set the context
back to amd64 and busts any references to a pseudo register (hence the
.effmach amd64 below).

Walking 32-bit Stack…
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be
wrong.
00000000 00000000 0x0
!k output>

Anyway the below is an attempted hack to get a !process 0 7 type output
with WOW64 usermode stack support.

Any help or comments with this would be greatly appreciated. It has been
pretty frustrating to say the least. =)

Thank in advance,
Chris

************************************ KD SCRIPT
*****************************

$$
$$ Dump entire list of thread stacks
$$

r $t0 = nt!PsActiveProcessHead

.for( r $t1 = poi @$t0; @$t1 != @$t0; r $t1 = poi @$t1 ) {
r? $t2 = #CONTAINING_RECORD(@$t1, nt!_EPROCESS, ActiveProcessLinks)

.process @$t2
.reload /user

r? @$t9 = @$t2->Wow64Process

.if( @$t9 == 0 )
{
!process @$t2 7
}
.else
{
r? $t5 = &@$t2->Pcb.ThreadListHead

!process @$t2 1

.for( r $t6 = poi @$t5; @$t6 != @$t5; r $t6 = poi @$t6 )
{
r? $t7 = #CONTAINING_RECORD(@$t6, nt!_KTHREAD,
ThreadListEntry)

!thread @$t7 2
.printf “Owning Process %p Image:
%16ma\n”, @$t2, @@c++(@$t2->ImageFileName)
.printf “Wait Start TickCount (%05ul ticks) \n”,
@@c++(@$t7->WaitTime)
.printf “Context Switch Count %ul\n”,
@@c++(@$t7->ContextSwitches)
.printf “UserTime (%05ul)\n”,
@@c++(@$t7->UserTime)
.printf “KernelTime (%05ul)\n”,
@@c++(@$t7->KernelTime)

.thread @$t7
!wow64exts.k
.effmach amd64
}
}
}

******************************** END KD SCRIPT
*****************************

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

I seem to have the same issues with !sw as !k with it not switching back
from 32 to 64 bit. I do a !sw once to switch to 32bit mode, extensions
seem to believe esp is 0 and a !sw fails to switch back to 64bit mode so
I need to do a .effmach to get back.

As for the hangs, generally they are system hangs and not app hangs and
even then are usually inter-process so the full dumps are useful for
matching up threads doing LPC and WaitTime are pretty useful too. =)

Its fairly general practice here for QA to issue a
ctrl+scrolllock+scrolllock when they are in an unrecoverable hang
situation and file a bug. I am not sure if that’s the best way to go
about diagnosing issues like this but it seems to be the most effective
for us.

Thanks,
Chris

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, April 07, 2006 11:04 AM
To: Kernel Debugging Interest List
Subject: RE: [windbg] !process 0 7 and WOW64

The answer I got from the WOW team was to use !wow64exts.sw to switch to
32-bit mode to get stacks.

I’m not aware of any plans to have !process/!thread auto-switch the
current machine mode.

Also, do you need to work with 64-bit kernel dumps for application
hangs? If you can get user-mode dumps from a 32-bit tool you’ll only
have to look at the 32-bit state and it’ll be like debugging a regular
x86 system (i.e. much more straightforward).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chris W. Carr
Sent: Thursday, April 06, 2006 6:49 PM
To: Kernel Debugging Interest List
Subject: [windbg] !process 0 7 and WOW64

Hey all,

A large portion of memory dumps I look at are manually initiated in
order to diagnose application hangs and system hangs and usually the
first thing I do is run a script that more or less does a !process 0 7
(however reloads user symbols for each process). Lately I have had the
need to debug 32 bit processes in 64 bit memory dumps and am having some
real problems with the WOW64 user stack decodes since they are not yet
supported by !process/!thread. Hey MSFT guys are there any plans for
this anytime soon? =)

!wow64exts.k chokes on kd 6.6 which I have heard are known issues with
.cxr /f but kd 6.5 seems to work ok when manually using !k however in
the context of a script it seems to always think that the usermode stack
has an esp of 0 and then takes a crap and forgets to set the context
back to amd64 and busts any references to a pseudo register (hence the
.effmach amd64 below).

Walking 32-bit Stack…
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be
wrong.
00000000 00000000 0x0
!k output>

Anyway the below is an attempted hack to get a !process 0 7 type output
with WOW64 usermode stack support.

Any help or comments with this would be greatly appreciated. It has been
pretty frustrating to say the least. =)

Thank in advance,
Chris

************************************ KD SCRIPT
*****************************

$$
$$ Dump entire list of thread stacks
$$

r $t0 = nt!PsActiveProcessHead

.for( r $t1 = poi @$t0; @$t1 != @$t0; r $t1 = poi @$t1 ) {
r? $t2 = #CONTAINING_RECORD(@$t1, nt!_EPROCESS, ActiveProcessLinks)

.process @$t2
.reload /user

r? @$t9 = @$t2->Wow64Process

.if( @$t9 == 0 )
{
!process @$t2 7
}
.else
{
r? $t5 = &@$t2->Pcb.ThreadListHead

!process @$t2 1

.for( r $t6 = poi @$t5; @$t6 != @$t5; r $t6 = poi @$t6 )
{
r? $t7 = #CONTAINING_RECORD(@$t6, nt!_KTHREAD,
ThreadListEntry)

!thread @$t7 2
.printf “Owning Process %p Image:
%16ma\n”, @$t2, @@c++(@$t2->ImageFileName)
.printf “Wait Start TickCount (%05ul ticks) \n”,
@@c++(@$t7->WaitTime)
.printf “Context Switch Count %ul\n”,
@@c++(@$t7->ContextSwitches)
.printf “UserTime (%05ul)\n”,
@@c++(@$t7->UserTime)
.printf “KernelTime (%05ul)\n”,
@@c++(@$t7->KernelTime)

.thread @$t7
!wow64exts.k
.effmach amd64
}
}
}

******************************** END KD SCRIPT
*****************************

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com