Prev: Hooking exit process
Next: Writing good articles that have much better chance to be seen by o
From: fufu on 16 Jan 2010 17:26
Hi. I trying to find out which files can't be opened by system on boot,
so i tried this:
bp nt!NtOpenFile "g poi(esp);j(eax==0)'gc';''" (yes, i know status other
than 0(eax==0) might actually be a success too,cause it's NTSTATUS)
and caught this:

f7bfd1ec 804dd4a1 badb0d00 f7bfd264 00000000 nt!KiFastCallEntry+0xf8
f7bfd25c 8058b3f5 80000080 f7bfd288 00000001 nt!ZwQueryValueKey+0x11
f7bfd294 805aba3c 80000080 805abc3c f7bfd350 nt!IopGetRegistryValue+0x52
f7bfd360 805abcd3 00000000 00000000 f7bfd5f8 nt!PipCallDriverAddDevice+0x77
f7bfd5bc 805a98c9 82fb1588 00000000 00000000 nt!PipProcessDevNodeTree+0x1a4
f7bfd5f0 80506516 00000003 00000006 82fed130 nt!PiProcessReenumeration+0x60
f7bfd618 8050fcb0 00000000 00000000 e12acbc8 nt!PipDeviceActionWorker+0x166
f7bfd630 806aa0f8 00000000 00000006 00000000 nt!PipRequestDeviceAction+0x107
f7bfd694 806a075f 80087000 f7bfd6b0 00034000
nt!IopInitializeBootDrivers+0x37a
f7bfd83c 806a1aec 80087000 00000000 82fca788 nt!IoInitSystem+0x712
f7bfddac 8057c9ca 80087000 00000000 00000000 nt!Phase1Initialization+0x9b5
f7bfdddc 804f88ea 806a137a 80087000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

and that's ok. But then i rebooted target trying to find wchich file OS
thried to load ,as i understand stack above esp is broken to find out
parameters for nt!NtOpenFile. So i tried this:

bp nt!NtOpenFile

but it's not catching for above scenario, OS loading passed far more
then when it catches first situation, why is that?

target runs on Virtual PC if that matters

thanks and regards
From: Ivan Brugiolo [MSFT] on 17 Jan 2010 14:21
I'm not sure if you are trying to ask a debugger question, such as:
Q:
how do I set-up a breakpoint, inspect the return value,
print the stack trace, and continue.
or if you are asking a system question.

For the `Q:` above:
-1-
you should be using `g @$ra` to go to the return address of a function.
That is way more portable.
-2-
Setting a breakpoint on a system service will get you to return
at the system-service-dispatch thunk code.
Since kernel-mode component can use a direct call or a system-service call
(see the difference between ZwCreateFile and NtCreateFile), the results
of your debugger printout may vary.
-3-
jumping to the return code of a function is expensive.
You should set a breakpoint at the end of the function, just
before `ret` is issued

3: kd> uf nt!NtCreateFile
nt!NtCreateFile:
// omissins
fffff800`02f89193 e83861ffff call nt!IopCreateFile
(fffff800`02f7f2d0)
fffff800`02f89198 4881c488000000 add rsp,88h <<<<<< set a breakpoint
here
fffff800`02f8919f c3 ret

Then, you may have files that are opened by issuing a IRP_MJ_CREATE,
or other internal mechanisms involving navigating symbolic links.

What are you really trying to debug ?

--

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"fufu" <fufus(a)poczta.fm> wrote in message
news:#JxtqrvlKHA.6096(a)TK2MSFTNGP02.phx.gbl...
> Hi. I trying to find out which files can't be opened by system on boot, so
> i tried this:
> bp nt!NtOpenFile "g poi(esp);j(eax==0)'gc';''" (yes, i know status other
> than 0(eax==0) might actually be a success too,cause it's NTSTATUS)
> and caught this:
>
> f7bfd1ec 804dd4a1 badb0d00 f7bfd264 00000000 nt!KiFastCallEntry+0xf8
> f7bfd25c 8058b3f5 80000080 f7bfd288 00000001 nt!ZwQueryValueKey+0x11
> f7bfd294 805aba3c 80000080 805abc3c f7bfd350 nt!IopGetRegistryValue+0x52
> f7bfd360 805abcd3 00000000 00000000 f7bfd5f8
> nt!PipCallDriverAddDevice+0x77
> f7bfd5bc 805a98c9 82fb1588 00000000 00000000
> nt!PipProcessDevNodeTree+0x1a4
> f7bfd5f0 80506516 00000003 00000006 82fed130
> nt!PiProcessReenumeration+0x60
> f7bfd618 8050fcb0 00000000 00000000 e12acbc8
> nt!PipDeviceActionWorker+0x166
> f7bfd630 806aa0f8 00000000 00000006 00000000
> nt!PipRequestDeviceAction+0x107
> f7bfd694 806a075f 80087000 f7bfd6b0 00034000
> nt!IopInitializeBootDrivers+0x37a
> f7bfd83c 806a1aec 80087000 00000000 82fca788 nt!IoInitSystem+0x712
> f7bfddac 8057c9ca 80087000 00000000 00000000 nt!Phase1Initialization+0x9b5
> f7bfdddc 804f88ea 806a137a 80087000 00000000
> nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> and that's ok. But then i rebooted target trying to find wchich file OS
> thried to load ,as i understand stack above esp is broken to find out
> parameters for nt!NtOpenFile. So i tried this:
>
> bp nt!NtOpenFile
>
> but it's not catching for above scenario, OS loading passed far more then
> when it catches first situation, why is that?
>
> target runs on Virtual PC if that matters
>
> thanks and regards

From: fufu on 18 Jan 2010 08:39
Hi. My mistake. Thing was i got catch from
bp nt!NtOpenFile "g poi(esp);j(eax==0)'gc';''" with stack from
nt!ZwQueryValueKey+0x11 but newer got stack with nt!ZwQueryValueKey+0x11
when i set bp nt!NtOpenFile itself.
I realized that first breakpoint is setting one shot breakpoint(as i
understand g(go command) at nt!KiFastCallEntry+0xf8(return from
nt!NtOpenfile) and was hit by completly different call not related to
nt!NtOpenfile, call to nt!ZwQueryValueKey+0x11 which after calling
service returns to nt!KiFastCallEntry+0xf8 as every call does, but how
did that happen?. First thougth it was like that:
breakpoint hit at nt!NtOpenFile
debugger set one shot at nt!KiFastCallEntry+0xf8
sheduler swapped out nt!NtOpenFile thread
other thread hit one shot nt!KiFastCallEntry+0xf8(ment for the first
one) returning from nt!NtQueryValueKey
i wrongly concluded nt!ZwQueryValueKey called nt!NtOpenFile

that would be fine IF there was some thread with nt!NtOpenFile at the
stack while i it got hit in nt!ZwQueryValueKey I've checked all SYSTEM
process(only one existing so far) threads.




W dniu 2010-01-17 20:21, Ivan Brugiolo [MSFT] pisze:
> I'm not sure if you are trying to ask a debugger question, such as:
> Q:
> how do I set-up a breakpoint, inspect the return value,
> print the stack trace, and continue.
> or if you are asking a system question.
>
> For the `Q:` above:
> -1-
> you should be using `g @$ra` to go to the return address of a function.
> That is way more portable.
> -2-
> Setting a breakpoint on a system service will get you to return
> at the system-service-dispatch thunk code.
> Since kernel-mode component can use a direct call or a system-service call
> (see the difference between ZwCreateFile and NtCreateFile), the results
> of your debugger printout may vary.
> -3-
> jumping to the return code of a function is expensive.
> You should set a breakpoint at the end of the function, just
> before `ret` is issued
>
> 3: kd> uf nt!NtCreateFile
> nt!NtCreateFile:
> // omissins
> fffff800`02f89193 e83861ffff call nt!IopCreateFile (fffff800`02f7f2d0)
> fffff800`02f89198 4881c488000000 add rsp,88h <<<<<< set a breakpoint here
> fffff800`02f8919f c3 ret
>
> Then, you may have files that are opened by issuing a IRP_MJ_CREATE,
> or other internal mechanisms involving navigating symbolic links.
>
> What are you really trying to debug ?
>

 | 
Pages: 1
Prev: Hooking exit process
Next: Writing good articles that have much better chance to be seen by o