uf PsCreateProcess failing to disassemble in lkd

WINDBG
1

i was trying to unassemble PspCreateProcess via
file -> kernel->local
and doing an uf nt!PspCreateProcess

version 6.6.3.5 was failing with an error unable to access memory
so i downloded the latest version
viz 6.6.7.5

this also errs with a different message
code not found aborting

while the same could be disassembled with
u nt!PspCreateProcess or u nt!PspCreateProcess L200

u 8058###

os == xp-sp2

I can do uf on other Funcions like
uf nt!MmCreateProcessAddressSpace
and they seem to work well

i have disassembled this function earlier in w2k using livekd (ex
sysinternals) without problems
can some one point out what could be the problem

2

I am able to do this on XPSP2. What does the disassembly look like when
you just use ‘u’?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of blufferisme isme
Sent: Thursday, July 20, 2006 12:38 AM
To: Kernel Debugging Interest List
Subject: [windbg] uf PsCreateProcess failing to disassemble in lkd

i was trying to unassemble PspCreateProcess via
file -> kernel->local
and doing an uf nt!PspCreateProcess

version 6.6.3.5 was failing with an error unable to access memory
so i downloded the latest version
viz 6.6.7.5

this also errs with a different message
code not found aborting

while the same could be disassembled with
u nt!PspCreateProcess or u nt!PspCreateProcess L200

u 8058###

os == xp-sp2

I can do uf on other Funcions like
uf nt!MmCreateProcessAddressSpace
and they seem to work well

i have disassembled this function earlier in w2k using livekd (ex
sysinternals) without problems
can some one point out what could be the problem
— You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Strange. The OP posters e-mail was flagged as possible phishing attempt in
OutLook 2007 Beta 2. It might be a quirk of a Beta but then anyone logging
into this type of forum with a name of “blufferisme isme” is . shy a brick
or two. I’d normally discount this type of warning on this forum, but given
the lack of judgment in the choice of the nickname used does give me pause.

The personal opinion of

Gary G. Little

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Thursday, July 20, 2006 4:15 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] uf PsCreateProcess failing to disassemble in lkd

I am able to do this on XPSP2. What does the disassembly look like when you
just use ‘u’?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of blufferisme isme
Sent: Thursday, July 20, 2006 12:38 AM
To: Kernel Debugging Interest List
Subject: [windbg] uf PsCreateProcess failing to disassemble in lkd

i was trying to unassemble PspCreateProcess via

file -> kernel->local

and doing an uf nt!PspCreateProcess

version 6.6.3.5 was failing with an error unable to access memory

so i downloded the latest version

viz 6.6.7.5

this also errs with a different message

code not found aborting

while the same could be disassembled with

u nt!PspCreateProcess or u nt!PspCreateProcess L200

u 8058###

os == xp-sp2

I can do uf on other Funcions like

uf nt!MmCreateProcessAddressSpace

and they seem to work well

i have disassembled this function earlier in w2k using livekd (ex
sysinternals) without problems

can some one point out what could be the problem

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

__________ NOD32 1.1668 (20060719) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

4

I suspect the phishing alert was triggered by the version numbers that
look like IP addresses (and poorly formed URLs). But the IP addresses
don’t appear to be valid targets…

…dave

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Thursday, July 20, 2006 6:17 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] uf PsCreateProcess failing to disassemble in lkd

Strange. The OP posters e-mail was flagged as possible phishing attempt
in OutLook 2007 Beta 2. It might be a quirk of a Beta but then anyone
logging into this type of forum with a name of “blufferisme isme” is …
shy a brick or two. I’d normally discount this type of warning on this
forum, but given the lack of judgment in the choice of the nickname used
does give me pause.

The personal opinion of

Gary G. Little

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Thursday, July 20, 2006 4:15 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] uf PsCreateProcess failing to disassemble in lkd

I am able to do this on XPSP2. What does the disassembly look like when
you just use ‘u’?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of blufferisme isme
Sent: Thursday, July 20, 2006 12:38 AM
To: Kernel Debugging Interest List
Subject: [windbg] uf PsCreateProcess failing to disassemble in lkd

i was trying to unassemble PspCreateProcess via

file -> kernel->local

and doing an uf nt!PspCreateProcess

version 6.6.3.5 was failing with an error unable to access memory

so i downloded the latest version

viz 6.6.7.5

this also errs with a different message

code not found aborting

while the same could be disassembled with

u nt!PspCreateProcess or u nt!PspCreateProcess L200

u 8058###

os == xp-sp2

I can do uf on other Funcions like

uf nt!MmCreateProcessAddressSpace

and they seem to work well

i have disassembled this function earlier in w2k using livekd (ex
sysinternals) without problems

can some one point out what could be the problem

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

__________ NOD32 1.1668 (20060719) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com

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

5

when i use u nt!PsPCreateProcess

or u 80580817

it disassembles right with push 0x11c

dd 0x80580817

provides me with the 68 1c010000

only uf nt!pspcreateprocess seems to fail

On 7/20/06, Drew Bliss wrote:
>
> I am able to do this on XPSP2. What does the disassembly look like when
> you just use ‘u’?
>
> ------------------------------
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *blufferisme isme
> Sent: Thursday, July 20, 2006 12:38 AM
> To: Kernel Debugging Interest List
> Subject: [windbg] uf PsCreateProcess failing to disassemble in lkd
>
>
> i was trying to unassemble PspCreateProcess via
> file -> kernel->local
> and doing an uf nt!PspCreateProcess
>
> version 6.6.3.5 was failing with an error unable to access memory
> so i downloded the latest version
> viz 6.6.7.5
>
> this also errs with a different message
> code not found aborting
>
> while the same could be disassembled with
> u nt!PspCreateProcess or u nt!PspCreateProcess L200
>
> u 8058###
>
> os == xp-sp2
>
> I can do uf on other Funcions like
> uf nt!MmCreateProcessAddressSpace
> and they seem to work well
>
> i have disassembled this function earlier in w2k using livekd (ex
> sysinternals) without problems
> can some one point out what could be the problem
> — You are currently subscribed to windbg as: xxxxx@winse.microsoft.comTo 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
>

6

cant edit earlier post i wasnt on same pc where i had this windbg earlier so
sorry for back to back posting

here are the details

lkd> x nt!pspcreateprocess
80580817 nt!PspCreateProcess =
lkd> uf nt!pspcreateprocess
No code found, aborting
lkd> u nt!pspcreateprocess
nt!PspCreateProcess:
80580817 681c010000 push 11Ch
8058081c 68a00c5080 push offset nt!ObWatchHandles+0x664 (80500ca0)
80580821 e8151cf6ff call nt!_SEH_prolog (804e243b)
80580826 64a124010000 mov eax,dword ptr fs:[00000124h]
8058082c 89857cffffff mov dword ptr [ebp-84h],eax
80580832 8a8840010000 mov cl,byte ptr [eax+140h]
80580838 884ddf mov byte ptr [ebp-21h],cl
8058083b 8b4044 mov eax,dword ptr [eax+44h]
lkd> dd nt!pspcreateprocess
80580817 00011c68 0ca06800 15e88050 64fff61c
80580827 000124a1 7c858900 8affffff 00014088
80580837 df4d8800 8944408b f633a845 00e345c6
80580847 89b87589 45f7bc75 fffff018 3b850fff
80580857 3900078d 840f1475 00046ba3 80458d56
80580867 df75ff50 05d835ff 80688056 ff000000
80580877 eae81475 8bfffe34 4d89804d 0fc63be4
80580887 00044d8c 28753900 8cef850f 418b0007

7

raj_r wrote:

cant edit earlier post i wasnt on same pc where i had this windbg
earlier so sorry for back to back posting

here are the details

lkd> x nt!pspcreateprocess
80580817 nt!PspCreateProcess =
> lkd> uf nt!pspcreateprocess
> No code found, aborting
> lkd> u nt!pspcreateprocess
> nt!PspCreateProcess:
> 80580817 681c010000 push 11Ch

This is not really too much of a surprise, is it? In order to implement
“uf”, the debugger must know where the function begins AND ends. When
you compile your own drivers with full debugging information, the pdb
contains that information. For the operating system DLLs, it probably
does not. It just knows where PspCreateProcess starts.

Are you getting symbols from the Microsoft symbol server?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

The disassembly looks fine, so I’m not sure why it would work for me but
not for you (I’m using public symbols also). Can you do an lml and a
version and send the output?

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Friday, July 21, 2006 9:01 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] uf PsCreateProcess failing to disassemble in lkd

cant edit earlier post i wasnt on same pc where i had this windbg
earlier so sorry for back to back posting

here are the details

lkd> x nt!pspcreateprocess
80580817 nt!PspCreateProcess =
lkd> uf nt!pspcreateprocess
No code found, aborting
lkd> u nt!pspcreateprocess
nt!PspCreateProcess:
80580817 681c010000 push 11Ch
8058081c 68a00c5080 push offset nt!ObWatchHandles+0x664
(80500ca0)
80580821 e8151cf6ff call nt!_SEH_prolog (804e243b)
80580826 64a124010000 mov eax,dword ptr fs:[00000124h]
8058082c 89857cffffff mov dword ptr [ebp-84h],eax
80580832 8a8840010000 mov cl,byte ptr [eax+140h]
80580838 884ddf mov byte ptr [ebp-21h],cl
8058083b 8b4044 mov eax,dword ptr [eax+44h]
lkd> dd nt!pspcreateprocess
80580817 00011c68 0ca06800 15e88050 64fff61c
80580827 000124a1 7c858900 8affffff 00014088
80580837 df4d8800 8944408b f633a845 00e345c6
80580847 89b87589 45f7bc75 fffff018 3b850fff
80580857 3900078d 840f1475 00046ba3 80458d56
80580867 df75ff50 05d835ff 80688056 ff000000
80580877 eae81475 8bfffe34 4d89804d 0fc63be4
80580887 00044d8c 28753900 8cef850f 418b0007

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

9

Actually uf only needs a starting address, it doesn’t need an ending
address. All further analysis is done based on tracking code flow via
disassembly. It should work fine with public symbols.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, July 21, 2006 9:17 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] uf PsCreateProcess failing to disassemble in lkd

raj_r wrote:

cant edit earlier post i wasnt on same pc where i had this windbg
earlier so sorry for back to back posting

here are the details

lkd> x nt!pspcreateprocess
80580817 nt!PspCreateProcess =
> lkd> uf nt!pspcreateprocess
> No code found, aborting
> lkd> u nt!pspcreateprocess
> nt!PspCreateProcess:
> 80580817 681c010000 push 11Ch

This is not really too much of a surprise, is it? In order to implement
“uf”, the debugger must know where the function begins AND ends. When
you compile your own drivers with full debugging information, the pdb
contains that information. For the operating system DLLs, it probably
does not. It just knows where PspCreateProcess starts.

Are you getting symbols from the Microsoft symbol server?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

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

10

here is the output as requested

lkd> version
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420
Debug session time: Fri Jul 21 23:04:40.375 2006 (GMT+6)
System Uptime: 0 days 2:35:08.967
Local KD
command line: '“C:\Program Files\Debugging Tools for Windows\windbg.exe” ’
Debugger Process 0x388
dbgeng: image 6.6.0007.5, built Sun Jul 09 01:42:40 2006
[path: C:\Program Files\Debugging Tools for Windows\dbgeng.dll]
dbghelp: image 6.6.0007.5, built Sun Jul 09 01:41:32 2006
[path: C:\Program Files\Debugging Tools for Windows\dbghelp.dll]
DIA version: 60516
Extension DLL search Path:
C:\Program Files\Debugging Tools for Windows\winext;C:\Program
Files\Debugging Tools for Windows\winext\arcade;C:\Program Files\Debugging
Tools for Windows\WINXP;C:\Program Files\Debugging Tools for
Windows\pri;C:\Program Files\Debugging Tools for Windows;C:\Program
Files\Debugging Tools for
Windows\winext\arcade;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Extension DLL chain:
dbghelp: image 6.6.0007.5, API 6.0.6, built Sun Jul 09 01:41:32 2006
[path: C:\Program Files\Debugging Tools for Windows\dbghelp.dll]
ext: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 01:40:52 2006
[path: C:\Program Files\Debugging Tools for Windows\winext\ext.dll]
exts: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 01:40:48 2006
[path: C:\Program Files\Debugging Tools for Windows\WINXP\exts.dll]
kext: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 01:41:01 2006
[path: C:\Program Files\Debugging Tools for Windows\winext\kext.dll]
kdexts: image 6.0.5457.0, API 1.0.0, built Sun Jul 09 02:01:08 2006
[path: C:\Program Files\Debugging Tools for
Windows\WINXP\kdexts.dll]
lkd> lml
start end module name
804d7000 806eb100 nt (pdb symbols)
D:\Borland\odbg110\symbols\ntoskrnl.pdb\32962337F0F646388B39535CD8DD70E82\ntoskrnl.pdb

On 7/21/06, Drew Bliss wrote:
>
> The disassembly looks fine, so I’m not sure why it would work for me but
> not for you (I’m using public symbols also). Can you do an lml and a
> version and send the output?
>
>
>

11

That all looks fine, I have no idea why it doesn’t work for you. We’ll
try and repro here.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Friday, July 21, 2006 10:43 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] uf PsCreateProcess failing to disassemble in lkd

here is the output as requested

lkd> version
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420
Debug session time: Fri Jul 21 23:04:40.375 2006 (GMT+6)
System Uptime: 0 days 2:35:08.967
Local KD
command line: '“C:\Program Files\Debugging Tools for Windows\windbg.exe”
’ Debugger Process 0x388
dbgeng: image 6.6.0007.5, built Sun Jul 09 01:42:40 2006
[path: C:\Program Files\Debugging Tools for Windows\dbgeng.dll]
dbghelp: image 6.6.0007.5 , built Sun Jul 09 01:41:32 2006
[path: C:\Program Files\Debugging Tools for Windows\dbghelp.dll]
DIA version: 60516
Extension DLL search Path:
C:\Program Files\Debugging Tools for Windows\winext;C:\Program
Files\Debugging Tools for Windows\winext\arcade;C:\Program
Files\Debugging Tools for Windows\WINXP;C:\Program Files\Debugging Tools
for Windows\pri;C:\Program Files\Debugging Tools for Windows;C:\Program
Files\Debugging Tools for
Windows\winext\arcade;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32
\Wbem
Extension DLL chain:
dbghelp: image 6.6.0007.5, API 6.0.6, built Sun Jul 09 01:41:32 2006
[path: C:\Program Files\Debugging Tools for Windows\dbghelp.dll]
ext: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 01:40:52 2006
[path: C:\Program Files\Debugging Tools for
Windows\winext\ext.dll]
exts: image 6.6.0007.5 , API 1.0.0, built Sun Jul 09 01:40:48 2006
[path: C:\Program Files\Debugging Tools for
Windows\WINXP\exts.dll]
kext: image 6.6.0007.5, API 1.0.0, built Sun Jul 09 01:41:01 2006
[path: C:\Program Files\Debugging Tools for
Windows\winext\kext.dll]
kdexts: image 6.0.5457.0, API 1.0.0, built Sun Jul 09 02:01:08 2006
[path: C:\Program Files\Debugging Tools for
Windows\WINXP\kdexts.dll]
lkd> lml
start end module name
804d7000 806eb100 nt (pdb symbols)
D:\Borland\odbg110\symbols\ntoskrnl.pdb\32962337F0F646388B39535CD8DD70E8
2\ntoskrnl.pdb

On 7/21/06, Drew Bliss wrote:

The disassembly looks fine, so I’m not sure why it would work
for me but not for you (I’m using public symbols also). Can you do an
lml and a version and send the output?

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

12

i was poking around and i see it can find flow upto this

Log data
Address Message
0216E9DA COND: 8058081C
0216E9DA COND: 80580821
0216E9DA COND: 80580826
0216E9DA COND: 8058082C
0216E9DA COND: 80580832
0216E9DA COND: 80580838
0216E9DA COND: 8058083B
0216E9DA COND: 8058083E
0216E9DA COND: 80580841
0216E9DA COND: 80580843
0216E9DA COND: 80580847
0216E9DA COND: 8058084A
0216E9DA COND: 8058084D
0216E9DA COND: 80580854
0216E9DA COND: 805F959A
0216E9DA COND: 80580CDE
0216E9DA COND: 8058085D
0216E9DA COND: 80580864
0216E9DA COND: 80580867
0216E9DA COND: 80580868
0216E9DA COND: 8058086B
0216E9DA COND: 80580871
0216E9DA COND: 80580876
0216E9DA COND: 80580879
0216E9DA COND: 8058087E
0216E9DA COND: 80580881
0216E9DA COND: 80580884
0216E9DA COND: 80580886
0216E9DA COND: 8058088F
0216E9DA COND: 805F958A
0216E9DA COND: 80580898
0216E9DA COND: 8058089B
0216E9DA COND: 805808A0
0216E9DA COND: 805808A3
0216E9DA COND: 805808A8
0216E9DA COND: 805808AB
0216E9DA COND: 805808AE
0216E9DA COND: 805808AF
0216E9DA COND: 805808B0
0216E9DA COND: 805808B1
0216E9DA COND: 805808B6
0216E9DA COND: 805808B7
0216E9DA COND: 805808BA
0216E9DA COND: 805808BD
0216E9DA COND: 805808C3
0216E9DA COND: 805808C6
0216E9DA COND: 805808CB
0216E9DA COND: 805808CD
0216E9DA COND: 805808CF
0216E9DA COND: 80580CCE
0216E9DA COND: 80580CD0
0216E9DA COND: 80580CD9
0216E9DA COND: 80580CD7
0216E9DA COND: 805808DA
0216E9DA COND: 805808DC
0216E9DA COND: 805808DF
0216E9DA COND: 805808E1
0216E9DA COND: 805808E3
0216E9DA COND: 805808E9
0216E9DA COND: 805808EC
0216E9DA COND: 805808F2
0216E9DA COND: 805808F5
0216E9DA COND: 805808F7
0216E9DA COND: 805808FA
0216E9DA COND: 805808FB
0216E9DA COND: 80580900
0216E9DA COND: 80580903
0216E9DA COND: 80580904
0216E9DA COND: 80580909
0216E9DA COND: 8058090C
0216E9DA COND: 8058090E
0216E9DA COND: 8058091A
0216E9DA COND: 80580920
0216E9DA COND: 80580926
0216E9DA COND: 8058092C
0216E9DA COND: 8058092F
0216E9DA COND: 80580936
0216E9DA COND: 8058093C
0216E9DA COND: 8058093D
0216E9DA COND: 80580940
0216E9DA COND: 80580946
0216E9DA COND: 80580948
0216E9DA COND: 8058094B
0216E9DA COND: 80580950
0216E9DA COND: 80580956
0216E9DA COND: 80580959
0216E9DA COND: 8058095B
0216E9DA COND: 8058095D
0216E9DA COND: 80580CC6
0216E9DA COND: 80580CCB
0216E9DA COND: 80580966
0216E9DA COND: 80580969
0216E9DA COND: 8058096F
0216E9DA COND: 80580972
0216E9DA COND: 805F95A0
0216E9DA COND: 805F95A3
0216E9DA COND: 805F95A4
0216E9DA COND: 805F95A7
0216E9DA COND: 805F95AD
0216E9DA COND: 805F95AF
0216E9DA COND: 805F95B2
0216E9DA COND: 805F95B7
0216E9DA COND: 805F95B9
0216E9DA COND: 805F95BB
0216E9DA COND: 805F95C4
0216E9DA COND: 805F95CA
0216E9DA COND: 805F95CE
0216E9DA COND: 80580986
0216E9DA COND: 805F9625
0216E9DA COND: 805F9628
0216E9DA COND: 805F9629
0216E9DA COND: 805F962C
0216E9DA COND: 805F9632
0216E9DA COND: 805F9633
0216E9DA COND: 805F9636
0216E9DA COND: 805F963B
0216E9DA COND: 805F963D
0216E9DA COND: 805F963F
0216E9DA COND: 805F9648
0216E9DA COND: 805F964E
0216E9DA COND: 80580996
0216E9DA COND: 80580997
0216E9DA COND: 8058099A
0216E9DA COND: 8058099F
0216E9DA COND: 805809A1
0216E9DA COND: 805809A3
0216E9DA COND: 805809AC
0216E9DA COND: 805809AE
0216E9DA COND: 805D04CC
0216E9DA COND: 805D04D2
0216E9DA COND: 805D04D8
0216E9DA COND: 805D04DB
0216E9DA COND: 805D04DC
0216E9DA COND: 805D04DD
0216E9DA COND: 805D04E2
0216E9DA COND: 805809CE
0216E9DA COND: 805809D4
0216E9DA COND: 805809D7
0216E9DA COND: 805809DA
0216E9DA COND: 805809E0
0216E9DA COND: 805809E2
0216E9DA COND: 805809E8
0216E9DA COND: 805809ED
0216E9DA COND: 805809EE
0216E9DA COND: 805809F1
0216E9DA COND: 805809F2
0216E9DA COND: 805809F5
0216E9DA COND: 805809F7
0216E9DA COND: 805809F8
0216E9DA COND: 805809FD
0216E9DA COND: 80580A02
0216E9DA COND: 80580A05
0216E9DA COND: 80580A0B
0216E9DA COND: 80580A0E
0216E9DA COND: 80580A10
0216E9DA COND: 805D05A8
0216E9DA COND: 805D05AD
0216E9DA COND: 80580A43
0216E9DA COND: 80580A45
0216E9DA COND: 80580A4E
0216E9DA COND: 80580A51
0216E9DA COND: 80580A5D
0216E9DA COND: 80580A5E
0216E9DA COND: 80580A61
0216E9DA COND: 80580A62
0216E9DA COND: 80580A63
0216E9DA COND: 80580A68
0216E9DA COND: 80580A6A
0216E9DA COND: 80580A6C
0216E9DA COND: 80580A75
0216E9DA COND: 80580A76
0216E9DA COND: 80580A77
0216E9DA COND: 80580A7C
0216E9DA COND: 80580A7E
0216E9DA COND: 80580A80
0216E9DA COND: 80580A8A
0216E9DA COND: 80580A90
0216E9DA COND: 80580A93
0216E9DA COND: 80580A94
0216E9DA COND: 80580A99
0216E9DA COND: 80580A9A
0216E9DA COND: 80580A9B
0216E9DA COND: 80580AA0
0216E9DA COND: 80580AA3
0216E9DA COND: 80580AA6
0216E9DA COND: 80580AA9
0216E9DA COND: 80580AAA
0216E9DA COND: 80580AB0
0216E9DA COND: 80580AB5
0216E9DA COND: 80580ABB
0216E9DA COND: 80580ABD
0216E9DA COND: 805F971E
0216E9DA COND: 80580AC9
0216E9DA COND: 80580ACC
0216E9DA COND: 80580ACE
0216E9DA COND: 80580AD3
0216E9DA COND: 80580AD5
0216E9DA COND: 805F9724
0216E9DA COND: 805F9729
0216E9DA COND: 80580ADE
0216E9DA COND: 80580AE0
0216E9DA COND: 80580AF3
0216E9DA COND: 80580B2F
0216E9DA COND: 80580B35
0216E9DA COND: 80580B3A
0216E9DA COND: 80580B3F
0216E9DA COND: 80580B45
0216E9DA COND: 80580B4B
0216E9DA COND: 80580B51
0216E9DA COND: 80580B54
0216E9DA COND: 80580B56
0216E9DA COND: 80580B5B
0216E9DA COND: 80580B60
0216E9DA COND: 80580B65
0216E9DA COND: 80580B6B
0216E9DA COND: 80580B7B
0216E9DA COND: 80580B8A
0216E9DA COND: 80580B90
0216E9DA COND: 80580B93
0216E9DA COND: 80580B94
0216E9DA COND: 80580B97
0216E9DA COND: 80580B9D
0216E9DA COND: 80580B9E
0216E9DA COND: 80580BA4
0216E9DA COND: 80580BA5
0216E9DA COND: 80580BA6
0216E9DA COND: 80580BA7
0216E9DA COND: 80580BAC
0216E9DA COND: 80580BAE
0216E9DA COND: 80580BB0
0216E9DA COND: 80580BB9
0216E9DA COND: 80580BBA
0216E9DA COND: 80580BBB
0216E9DA COND: 80580BBD
0216E9DA COND: 80580BC0
0216E9DA COND: 80580BC6
0216E9DA COND: 80580BC7
0216E9DA COND: 80580BC8
0216E9DA COND: 80580BCD
0216E9DA COND: 80580BCF
0216E9DA COND: 80580BD2
0216E9DA COND: 80580BD8
0216E9DA COND: 80580BD9
0216E9DA COND: 80580BDE
0216E9DA COND: 80580BE0
0216E9DA COND: 80580BF0
0216E9DA COND: 80580BF1
0216E9DA COND: 80580BF2
0216E9DA COND: 80580BF7
0216E9DA COND: 80580BFA
0216E9DA COND: 80580C03
0216E9DA COND: 80580C09
0216E9DA COND: 80580C12
0216E9DA COND: 80580C13
0216E9DA COND: 80580C16
0216E9DA COND: 80580C17
0216E9DA COND: 80580C18
0216E9DA COND: 80580C1D
0216E9DA COND: 80580C1F
0216E9DA COND: 80580C22
0216E9DA COND: 80580C24
0216E9DA COND: 805F9818
0216E9DA COND: 805F981B
0216E9DA COND: 805F9820
0216E9DA COND: 80580C30
0216E9DA COND: 80580C31
0216E9DA COND: 80580C36
0216E9DA COND: 80580C3C
0216E9DA COND: 80580C42
0216E9DA COND: 80580C45
0216E9DA COND: 80580C46
0216E9DA COND: 80580C4C
0216E9DA COND: 80580C4D
0216E9DA COND: 80580C50
0216E9DA COND: 80580C55
0216E9DA COND: 80580C58
0216E9DA COND: 80580C59
0216E9DA COND: 80580C5A
0216E9DA COND: 80580C5B
0216E9DA COND: 80580C60
0216E9DA COND: 80580C61
0216E9DA COND: 80580C67
0216E9DA COND: 80580C68
0216E9DA COND: 80580C6B
0216E9DA COND: 80580C70
0216E9DA COND: 80580C73
0216E9DA COND: 80580C79
0216E9DA COND: 80580C7F
0216E9DA COND: 80580C84
0216E9DA COND: 80580C87
0216E9DA COND: 80580C8A
0216E9DA COND: 80580C8F
0216E9DA COND: 80580C93
0216E9DA COND: 805F982B
0216E9DA COND: 80580CA3
0216E9DA COND: 80580CA6
0216E9DA COND: 80580CA7
0216E9DA COND: 80580CAC
0216E9DA COND: 80580CAF
0216E9DA COND: 80580CB2
0216E9DA COND: 80580CB5
0216E9DA COND: 80580CB7
0216E9DA COND: 80580CBB
0216E9DA COND: 80580CBE
0216E9DA COND: 805F9855
0216E9DA COND: 80580B82
0216E9DA COND: 80580B85
0216E9DA COND: 80580B70
0216E9DA COND: 80580B72
0216E9DA COND: 805F9808
0216E9DA COND: 805F980A
0216E9DA COND: 805F9810
0216E9DA COND: 80580AF9
0216E9DA COND: 80580AFD
0216E9DA COND: 80580B00
0216E9DA COND: 80580B01
0216E9DA COND: 80580B05
0216E9DA COND: 80580B08
0216E9DA COND: 805F97D8
0216E9DA COND: 805F97DB
0216E9DA COND: 805F97E1
0216E9DA COND: 805F97E7
0216E9DA COND: 805F97ED
0216E9DA COND: 805F97EE
0216E9DA COND: 805F97EF
0216E9DA COND: 805F97F1
0216E9DA COND: 805F97F2
0216E9DA COND: 805F97F3
0216E9DA COND: 805F97F6
0216E9DA COND: 805F97F7
0216E9DA COND: 805F97FA
0216E9DA COND: 805F97FF
0216E9DA COND: 80580B14
0216E9DA COND: 80580B15
0216E9DA COND: 80580B18
0216E9DA COND: 80580B19
0216E9DA COND: 80580B1A
0216E9DA COND: 80580B1F
0216E9DA COND: 80580B21
0216E9DA COND: 80580B23
0216E9DA COND: 805F97CF
0216E9DA COND: 80580AE8
0216E9DA COND: 80580AEA
0216E9DA COND: 805F9734
0216E9DA COND: 805F973A
0216E9DA COND: 805F9744
0216E9DA COND: 805F9767
0216E9DA COND: 805F9768
0216E9DA COND: 805F976B
0216E9DA COND: 805F976C
0216E9DA COND: 805F9771
0216E9DA COND: 805F9773
0216E9DA COND: 805F9775
0216E9DA COND: 805F9781
0216E9DA COND: 805F9784
0216E9DA COND: 805F9785
0216E9DA COND: 805F9786
0216E9DA COND: 805F978B
0216E9DA COND: 805F978D
0216E9DA COND: 805F9790
0216E9DA COND: 805F9796
0216E9DA COND: 805F9798
0216E9DA COND: 805D05BB
0216E9DA COND: 805F979F
0216E9DA COND: 805F97A2
0216E9DA COND: 805F97A3
0216E9DA COND: 805F97A4
0216E9DA COND: 805F97A9
0216E9DA COND: 805F97AB
0216E9DA COND: 805F97AD
0216E9DA COND: 805F97B6
0216E9DA COND: 805F97B7
0216E9DA COND: 805F97BC
0216E9DA COND: 805F97BF
0216E9DA COND: 805F97C4
0216E9DA COND: 805F974C
0216E9DA COND: 805F974E
0216E9DA COND: 805F9750
0216E9DA COND: 805F9756
0216E9DA COND: 805F975C
0216E9DA COND: 80580A1C
0216E9DA COND: 80580A1F
0216E9DA COND: 805D05B4
0216E9DA COND: 80580A2F
0216E9DA COND: 80580A32
0216E9DA COND: 80580A34
0216E9DA COND: 80580A36
0216E9DA COND: 80580A38
0216E9DA COND: 80580A3B
0216E9DA COND: 80580A3C
0216E9DA COND: 80580A41
0216E9DA COND: 80580A28
0216E9DA COND: 805809B7
0216E9DA COND: 805809B8
0216E9DA COND: 805809B9
0216E9DA COND: 805809BC
0216E9DA COND: 805809C1
0216E9DA COND: 805809C3
0216E9DA COND: 805F95D6
0216E9DA COND: 805F95D7
0216E9DA COND: 805F95DD
0216E9DA COND: 805F95E0
0216E9DA COND: 8058097A
0216E9DA COND: 8058097D
0216E9DA COND: 8058097E
0216E9DA COND: 80580983
0216E9DA COND: 805F9595
0216E9FA Breakpoint at dbgeng.0216E9FA

and this buffer delete still takes place
Stack SS:[00A0D600]=00000001
Jumps from MachineInfo::BuildFlowGraph+0E6, MachineInfo::BuildFlowGraph+103,
MachineInfo::BuildFlowGraph+151, MachineInfo::BuildFlowGraph+233,
MachineInfo::BuildFlowGraph+391, MachineInfo::BuildFlowGraph+42D,
MachineInfo::BuildFlowGraph+538
dbgeng.MachineInfo::BuildFlowGraph+566

and it is failing this

0216AE33 CALL dbgeng.DbsDynamicArray
machineinfo::flownode::GetEltsUsed
0216AE38 TEST EAX, EAX
0216AE3A JNZ SHORT dbgeng.0216AE78
0216AE3C PUSH dbgeng.0202BED8 ; /Arg1 = 0202BED8
0216AE41 CALL dbgeng.ErrOut ; \ErrOut

0202BED8=dbgeng.0202BED8 (UNICODE “No code found, aborting
”)
dbgeng.UnassembleFunction+1AC

if i dont let the buffer to be deleted

0216E9FA JE SHORT dbgeng.0216EA09
0216E9FC MOV ECX, DWORD PTR SS:[EBP+14]
0216E9FF CALL dbgeng.DbsDynamicBuffer::Delete <-------
0216EA04 JMP dbgeng.0216EA92

i get a warnout saying flow analysis may be incomplete and it can

display almost complete disassembly

lkd> uf nt!pspcreateprocess
No code found, aborting
lkd> uf nt!pspcreateprocess
Flow analysis was incomplete, some code may be missing <----------
nt!PspCreateProcess:
80580817 681c010000 push 11Ch
8058081c 68a00c5080 push offset nt!ObWatchHandles+0x664 (80500ca0)
80580821 e8151cf6ff call nt!_SEH_prolog (804e243b)
80580826 64a124010000 mov eax,dword ptr fs:[00000124h]

snippppp=====================>

nt!PspCreateProcess+0x709:
805f9825 89b3a4010000 mov dword ptr [ebx+1A4h],esi
805f982b e96974f8ff jmp nt!PspCreateProcess+0x70f (80580c99)

nt!PspCreateProcess+0x757:
805f9852 8b7dcc mov edi,dword ptr [ebp-34h]
805f9855 e96a74f8ff jmp nt!PspCreateProcess+0x75a (80580cc4)

dont know whats wrong :slight_smile:

On 7/21/06, Drew Bliss wrote:
>
> That all looks fine, I have no idea why it doesn’t work for you. We’ll
> try and repro here.
>
>
></machineinfo::flownode>

13

seems like some post lines limit exists the post was cut of from here
in the forum

0216E9DA COND: 80580A1C
0216E9DA COND: 80580A1F
0216E9DA COND: 805D05B4
0216E9DA COND: 80580A2F
0216E9DA COND: 80580A32
0216E9DA COND: 80580A34
0216E9DA COND: 80580A36
0216E9DA COND: 80580A38
0216E9DA COND: 80580A3B
0216E9DA COND: 80580A3C
0216E9DA COND: 80580A41
0216E9DA COND: 80580A28
0216E9DA COND: 805809B7
0216E9DA COND: 805809B8
0216E9DA COND: 805809B9
0216E9DA COND: 805809BC
0216E9DA COND: 805809C1
0216E9DA COND: 805809C3
0216E9DA COND: 805F95D6
0216E9DA COND: 805F95D7
0216E9DA COND: 805F95DD
0216E9DA COND: 805F95E0
0216E9DA COND: 8058097A
0216E9DA COND: 8058097D
0216E9DA COND: 8058097E
0216E9DA COND: 80580983
0216E9DA COND: 805F9595
0216E9FA Breakpoint at dbgeng.0216E9FA

and this buffer delete still takes place
Stack SS:[00A0D600]=00000001
Jumps from MachineInfo::BuildFlowGraph+0E6, MachineInfo::BuildFlowGraph+103,
MachineInfo::BuildFlowGraph+151, MachineInfo::BuildFlowGraph+233,
MachineInfo::BuildFlowGraph+391, MachineInfo::BuildFlowGraph+42D,
MachineInfo::BuildFlowGraph+538
dbgeng.MachineInfo::BuildFlowGraph+566

and it is failing this

0216AE33 CALL dbgeng.DbsDynamicArray
machineinfo::flownode::GetEltsUsed
0216AE38 TEST EAX, EAX
0216AE3A JNZ SHORT dbgeng.0216AE78
0216AE3C PUSH dbgeng.0202BED8 ; /Arg1 = 0202BED8
0216AE41 CALL dbgeng.ErrOut ; \ErrOut

0202BED8=dbgeng.0202BED8 (UNICODE “No code found, aborting
”)
dbgeng.UnassembleFunction+1AC

if i dont let the buffer to be deleted

0216E9FA JE SHORT dbgeng.0216EA09
0216E9FC MOV ECX, DWORD PTR SS:[EBP+14]
0216E9FF CALL dbgeng.DbsDynamicBuffer::Delete <-------
0216EA04 JMP dbgeng.0216EA92

i get a warnout saying flow analysis may be incomplete and it can

display almost complete disassembly

lkd> uf nt!pspcreateprocess
No code found, aborting
lkd> uf nt!pspcreateprocess
Flow analysis was incomplete, some code may be missing <----------

nt!PspCreateProcess:
80580817 681c010000 push 11Ch
8058081c 68a00c5080 push offset nt!ObWatchHandles+0x664 (80500ca0)
80580821 e8151cf6ff call nt!_SEH_prolog (804e243b)
80580826 64a124010000 mov eax,dword ptr fs:[00000124h]

snippppp=====================>

nt!PspCreateProcess+0x709:
805f9825 89b3a4010000 mov dword ptr [ebx+1A4h],esi
805f982b e96974f8ff jmp nt!PspCreateProcess+0x70f (80580c99)

nt!PspCreateProcess+0x757:
805f9852 8b7dcc mov edi,dword ptr [ebp-34h]
805f9855 e96a74f8ff jmp nt!PspCreateProcess+0x75a (80580cc4)

dont know whats wrong :)</machineinfo::flownode>

14

Thanks, this information was enough for me to track down the issue. As
you’ve found, BuildFlowGraph is deleting the result array in a situation
when it shouldn’t be (when there’s uncertainty about the flow due to
things like unresolvable indirect jumps). It should let things work but
with the partial-analysis warning. We’ll fix this for the next drop.

There isn’t any easy workaround, but this should only affect a small
percentage of routines.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of raj_r
Sent: Friday, July 21, 2006 11:20 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] uf PsCreateProcess failing to disassemble in lkd

seems like some post lines limit exists the post was cut of from here
in the forum

0216E9DA COND: 80580A1C
0216E9DA COND: 80580A1F
0216E9DA COND: 805D05B4
0216E9DA COND: 80580A2F
0216E9DA COND: 80580A32
0216E9DA COND: 80580A34
0216E9DA COND: 80580A36
0216E9DA COND: 80580A38
0216E9DA COND: 80580A3B
0216E9DA COND: 80580A3C
0216E9DA COND: 80580A41
0216E9DA COND: 80580A28
0216E9DA COND: 805809B7
0216E9DA COND: 805809B8
0216E9DA COND: 805809B9
0216E9DA COND: 805809BC
0216E9DA COND: 805809C1
0216E9DA COND: 805809C3
0216E9DA COND: 805F95D6
0216E9DA COND: 805F95D7
0216E9DA COND: 805F95DD
0216E9DA COND: 805F95E0
0216E9DA COND: 8058097A
0216E9DA COND: 8058097D
0216E9DA COND: 8058097E
0216E9DA COND: 80580983
0216E9DA COND: 805F9595
0216E9FA Breakpoint at dbgeng.0216E9FA

and this buffer delete still takes place
Stack SS:[00A0D600]=00000001
Jumps from MachineInfo::BuildFlowGraph+0E6,
MachineInfo::BuildFlowGraph+103, MachineInfo::BuildFlowGraph+151,
MachineInfo::BuildFlowGraph+233, MachineInfo::BuildFlowGraph+391,
MachineInfo::BuildFlowGraph+42D, MachineInfo::BuildFlowGraph+538
dbgeng.MachineInfo::BuildFlowGraph+566

and it is failing this

0216AE33 CALL
dbgeng.DbsDynamicArraymachineinfo::flownode::GetEltsUsed
0216AE38 TEST EAX, EAX
0216AE3A JNZ SHORT dbgeng.0216AE78
0216AE3C PUSH dbgeng.0202BED8 ; /Arg1 = 0202BED8
0216AE41 CALL dbgeng.ErrOut ; \ErrOut

0202BED8=dbgeng.0202BED8 (UNICODE “No code found, aborting
”)
dbgeng.UnassembleFunction+1AC

if i dont let the buffer to be deleted

0216E9FA JE SHORT dbgeng.0216EA09
0216E9FC MOV ECX, DWORD PTR SS:[EBP+14]
0216E9FF CALL dbgeng.DbsDynamicBuffer::Delete <-------
0216EA04 JMP dbgeng.0216EA92

i get a warnout saying flow analysis may be incomplete and it can

display almost complete disassembly

lkd> uf nt!pspcreateprocess
No code found, aborting

lkd> uf nt!pspcreateprocess
Flow analysis was incomplete, some code may be missing <----------

nt!PspCreateProcess:
80580817 681c010000 push 11Ch

8058081c 68a00c5080 push offset nt!ObWatchHandles+0x664
(80500ca0)
80580821 e8151cf6ff call nt!_SEH_prolog (804e243b)
80580826 64a124010000 mov eax,dword ptr fs:[00000124h]

snippppp=====================>

nt!PspCreateProcess+0x709:
805f9825 89b3a4010000 mov dword ptr [ebx+1A4h],esi
805f982b e96974f8ff jmp nt!PspCreateProcess+0x70f (80580c99)

nt!PspCreateProcess+0x757:
805f9852 8b7dcc mov edi,dword ptr [ebp-34h]
805f9855 e96a74f8ff jmp nt!PspCreateProcess+0x75a (80580cc4)

dont know whats wrong :slight_smile:

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

15

Drew Bliss,

thanks for the feedback

i was interseted in finding out why windbg -hd doesnt work like documented
in help
but running cmd.exe and doing a set _NO_DEBUG_HEAP=1
and running a windbg from that prompt does work without
DebugHeap being allocated

thats when i stumbled upon this queer phenomenon

also it seems gflags -k +sls -htc -hpc from command prompt
doesnt seem to have any effect while
running !gflags from within windbg seems to set those GlobalFlags

though setting of these inside windbg also doesnt alter any of the new heaps
allocated to be standard heaps but they continue to be
DebugHeaps RtlAllocateDebugHeap is called coz it is depenedent of the
Flags and ForceFlags in the heap thats allocated first
!heap -v 1

any feedbacks pointers to this effect also would be usefull

thanks once again for prompt and excellent answers

hope to see more interaction in future

On 7/21/06, Drew Bliss wrote:
>
> Thanks, this information was enough for me to track down the issue. As
> you’ve found, BuildFlowGraph is deleting the result array in a situation
> when it shouldn’t be (when there’s uncertainty about the flow due to things
> like unresolvable indirect jumps). It should let things work but with the
> partial-analysis warning. We’ll fix this for the next drop.
>
> There isn’t any easy workaround, but this should only affect a small
> percentage of routines.
>
> ------------------------------
>

16

raj_r wrote:

Drew Bliss,

also it seems gflags -k +sls -htc -hpc from command prompt
doesnt seem to have any effect while
running !gflags from within windbg seems to set those GlobalFlags

That would be because the valid GFLAG mask changed in XP in the Native
API call responsible for setting global flags, so some of the flags it’s
sending are getting ignored.

Best regards,
Alex Ionescu

17

Drew,

It also would be nice to have ‘uf’ for x64 code. Are there plans for that?

Dmitriy Budko
VMware

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, July 21, 2006 1:46 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] uf PsCreateProcess failing to disassemble in lkd

Thanks, this information was enough for me to track down the issue. As
you’ve found, BuildFlowGraph is deleting the result array in a situation when
it shouldn’t be (when there’s uncertainty about the flow due to things like
unresolvable indirect jumps). It should let things work but with the
partial-analysis warning. We’ll fix this for the next drop.

There isn’t any easy workaround, but this should only affect a small
percentage of routines.

18

uf works for x64 in the latest public release (6.6.07).

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dmitriy Budko
Sent: Monday, July 24, 2006 4:16 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] uf PsCreateProcess failing to disassemble in lkd

Drew,

It also would be nice to have ‘uf’ for x64 code. Are there plans for
that?

Dmitriy Budko
VMware

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Drew Bliss
Sent: Friday, July 21, 2006 1:46 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] uf PsCreateProcess failing to disassemble in lkd

Thanks, this information was enough for me to track down the issue. As
you’ve found, BuildFlowGraph is deleting the result array in a situation
when it shouldn’t be (when there’s uncertainty about the flow due to
things like unresolvable indirect jumps). It should let things work but
with the partial-analysis warning. We’ll fix this for the next drop.

There isn’t any easy workaround, but this should only affect a small
percentage of routines.

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