PsCreateProcessNotifyRoutine and ZwTerminateProcess conflict!

OSR_Community_User · June 21, 2016, 8:07am

Hello everyone, i experienced something weird while developing a new feature for my driver (Currently Tested only on Windows XP!!!).

In my driver i am hooking several functions through the ssdt, one of which is ZwTerminateProcess.

One of the abilities i implemented in my driver requires me to use PsCreateProcessNotifyRoutine to monitor the process creation (and both process termination)

in my PsCreateProcessNotifyRoutine CallBack i am implementing some logic to edit the page tables of a specific process, and when terminating it, i want to restore the physical pages to be as they were before i changed them (Just for a clean cleanup procedure)

Now i have experienced some weird behavior.
On process termination there is a weird thing going on.
When ZwTerminateProcess is hooked, i am experiencing an exception when the function is called, here is the callstack from windbg:

ChildEBP RetAddr Args to Child
f41c1780 804f8afd 00000003 f41c1adc 00000000 nt!RtlpBreakWithStatusInstruction
f41c17cc 804f96e8 00000003 c03fb780 80f346e4 nt!KiBugCheckDebugBreak+0x19
f41c1bac 804f9c37 0000004e 00000099 00006826 nt!KeBugCheck2+0x574
f41c1bcc 80510b92 0000004e 00000099 00006826 nt!KeBugCheckEx+0x1b
f41c1c04 805aec1b 7f6f0019 862cc4b0 007ffff8 nt!MiDeleteValidAddress+0x156
f41c1c24 80512655 862cc4b0 862cc5e8 862cc4b0 nt!MiDeleteAddressesInWorkingSet+0x65
f41c1c58 805d0ed7 002cc4b0 85802da8 85802ff0 nt!MmCleanProcessAddressSpace+0x193
f41c1ce0 805d109a c000013a 85802da8 00000000 nt!PspExitThread+0x621
f41c1d00 805d1275 85802da8 c000013a f41c1d64 nt!PspTerminateThreadByPointer+0x52
f41c1d2c f41248e3 00000000 c000013a 80538aa0 nt!NtTerminateProcess+0x105
f41c1d54 8054060c ffffffff c000013a 00a0ff04 MyXpDriver!XpDriver_NtTerminateProcess+0x43
f41c1d54 7c90eb94 ffffffff c000013a 00a0ff04 nt!KiFastCallEntry+0xfc

Now when i stop monitoring that ZwTerminateProcess i have no problem, no exception the process is exiting as expected, and everything is working properly…

Now i dont fully understand what is the problem here, or what is causing my driver to crash…
Can anyone give me any hints? \ Anyone knows what exactly is going on that is making the program crash?

Facts:

My code that is changing the physical pages is working perfectly. i tested it without the ZwTerminateProcess and it shows no problem. Debugged the physical addresses and everything is going as expected
Without the PsCreateProcessNotifyRoutine callback, i experience no problem hooking ZwTerminateProcess
The thing i do in my ZwTerminateProcess function, is calling the ‘old one’ and then doing a logic of my own… the old function never finishes on this scenario

Maxim_S_Shatskih · June 21, 2016, 8:48am

You cannot hook functions in more-or-less modern Windows, at least 64bit ones.

And yes, Device Guard in Win10+Srv2016 makes this even more prohibitive.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hello everyone, i experienced something weird while developing a new feature for my driver (Currently Tested only on Windows XP!!!).
>
> In my driver i am hooking several functions through the ssdt, one of which is ZwTerminateProcess.
>
> One of the abilities i implemented in my driver requires me to use PsCreateProcessNotifyRoutine to monitor the process creation (and both process termination)
>
> in my PsCreateProcessNotifyRoutine CallBack i am implementing some logic to edit the page tables of a specific process, and when terminating it, i want to restore the physical pages to be as they were before i changed them (Just for a clean cleanup procedure)
>
> Now i have experienced some weird behavior.
> On process termination there is a weird thing going on.
> When ZwTerminateProcess is hooked, i am experiencing an exception when the function is called, here is the callstack from windbg:
>
> ChildEBP RetAddr Args to Child
> f41c1780 804f8afd 00000003 f41c1adc 00000000 nt!RtlpBreakWithStatusInstruction
> f41c17cc 804f96e8 00000003 c03fb780 80f346e4 nt!KiBugCheckDebugBreak+0x19
> f41c1bac 804f9c37 0000004e 00000099 00006826 nt!KeBugCheck2+0x574
> f41c1bcc 80510b92 0000004e 00000099 00006826 nt!KeBugCheckEx+0x1b
> f41c1c04 805aec1b 7f6f0019 862cc4b0 007ffff8 nt!MiDeleteValidAddress+0x156
> f41c1c24 80512655 862cc4b0 862cc5e8 862cc4b0 nt!MiDeleteAddressesInWorkingSet+0x65
> f41c1c58 805d0ed7 002cc4b0 85802da8 85802ff0 nt!MmCleanProcessAddressSpace+0x193
> f41c1ce0 805d109a c000013a 85802da8 00000000 nt!PspExitThread+0x621
> f41c1d00 805d1275 85802da8 c000013a f41c1d64 nt!PspTerminateThreadByPointer+0x52
> f41c1d2c f41248e3 00000000 c000013a 80538aa0 nt!NtTerminateProcess+0x105
> f41c1d54 8054060c ffffffff c000013a 00a0ff04 MyXpDriver!XpDriver_NtTerminateProcess+0x43
> f41c1d54 7c90eb94 ffffffff c000013a 00a0ff04 nt!KiFastCallEntry+0xfc
>
> Now when i stop monitoring that ZwTerminateProcess i have no problem, no exception the process is exiting as expected, and everything is working properly…
>
> Now i dont fully understand what is the problem here, or what is causing my driver to crash…
> Can anyone give me any hints? \ Anyone knows what exactly is going on that is making the program crash?
>
>
> Facts:
> 1. My code that is changing the physical pages is working perfectly. i tested it without the ZwTerminateProcess and it shows no problem. Debugged the physical addresses and everything is going as expected
> 2. Without the PsCreateProcessNotifyRoutine callback, i experience no problem hooking ZwTerminateProcess
> 3. The thing i do in my ZwTerminateProcess function, is calling the ‘old one’ and then doing a logic of my own… the old function never finishes on this scenario
>

OSR_Community_User · June 21, 2016, 9:19am

ok thanks, but i was talking specifically about *windows XP*, and about my
scenario here only. i am not asking about other modern windows systems.

On Tue, Jun 21, 2016 at 3:48 PM, Maxim S. Shatskih
wrote:

> You cannot hook functions in more-or-less modern Windows, at least
> 64bit ones.
>
> And yes, Device Guard in Win10+Srv2016 makes this even more
> prohibitive.
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> wrote in message news:xxxxx@ntdev…
> > Hello everyone, i experienced something weird while developing a new
> feature for my driver (Currently Tested only on Windows XP!!!).
> >
> > In my driver i am hooking several functions through the ssdt, one of
> which is ZwTerminateProcess.
> >
> > One of the abilities i implemented in my driver requires me to use
> PsCreateProcessNotifyRoutine to monitor the process creation (and both
> process termination)
> >
> > in my PsCreateProcessNotifyRoutine CallBack i am implementing some
> logic to edit the page tables of a specific process, and when terminating
> it, i want to restore the physical pages to be as they were before i
> changed them (Just for a clean cleanup procedure)
> >
> > Now i have experienced some weird behavior.
> > On process termination there is a weird thing going on.
> > When ZwTerminateProcess is hooked, i am experiencing an exception when
> the function is called, here is the callstack from windbg:
> >
> > ChildEBP RetAddr Args to Child
> > f41c1780 804f8afd 00000003 f41c1adc 00000000
> nt!RtlpBreakWithStatusInstruction
> > f41c17cc 804f96e8 00000003 c03fb780 80f346e4 nt!KiBugCheckDebugBreak+0x19
> > f41c1bac 804f9c37 0000004e 00000099 00006826 nt!KeBugCheck2+0x574
> > f41c1bcc 80510b92 0000004e 00000099 00006826 nt!KeBugCheckEx+0x1b
> > f41c1c04 805aec1b 7f6f0019 862cc4b0 007ffff8
> nt!MiDeleteValidAddress+0x156
> > f41c1c24 80512655 862cc4b0 862cc5e8 862cc4b0
> nt!MiDeleteAddressesInWorkingSet+0x65
> > f41c1c58 805d0ed7 002cc4b0 85802da8 85802ff0
> nt!MmCleanProcessAddressSpace+0x193
> > f41c1ce0 805d109a c000013a 85802da8 00000000 nt!PspExitThread+0x621
> > f41c1d00 805d1275 85802da8 c000013a f41c1d64
> nt!PspTerminateThreadByPointer+0x52
> > f41c1d2c f41248e3 00000000 c000013a 80538aa0 nt!NtTerminateProcess+0x105
> > f41c1d54 8054060c ffffffff c000013a 00a0ff04
> MyXpDriver!XpDriver_NtTerminateProcess+0x43
> > f41c1d54 7c90eb94 ffffffff c000013a 00a0ff04 nt!KiFastCallEntry+0xfc
> >
> > Now when i stop monitoring that ZwTerminateProcess i have no problem,
> no exception the process is exiting as expected, and everything is working
> properly…
> >
> > Now i dont fully understand what is the problem here, or what is causing
> my driver to crash…
> > Can anyone give me any hints? \ Anyone knows what exactly is going on
> that is making the program crash?
> >
> >
> > Facts:
> > 1. My code that is changing the physical pages is working perfectly. i
> tested it without the ZwTerminateProcess and it shows no problem. Debugged
> the physical addresses and everything is going as expected
> > 2. Without the PsCreateProcessNotifyRoutine callback, i experience no
> problem hooking ZwTerminateProcess
> > 3. The thing i do in my ZwTerminateProcess function, is calling the ‘old
> one’ and then doing a logic of my own… the old function never finishes on
> this scenario
> >
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>

anton_bassov · June 21, 2016, 9:39am

> Can anyone give me any hints? \ Anyone knows what exactly is going on that is

making the program crash?

Well, taking into consideration the fact that you modify page tables (i.e. the resources that you don’t own and, hence, have no means of synchronising an access to), the most likely scenario here is that your hooking code and a callback routine just get at odds with one another whille trying to modify the same resource that neither of them owns, effectively leaving it in inconsistent state . Simple,ugh…

Anton Bassov

OSR_Community_User · June 21, 2016, 9:41am

any idea how to overcome this issue? I had the same idea in my mind

On Tue, Jun 21, 2016 at 4:39 PM, wrote:

> > Can anyone give me any hints? \ Anyone knows what exactly is going on
> that is
> > making the program crash?
>
> Well, taking into consideration the fact that you modify page tables (i.e.
> the resources that you don’t own and, hence, have no means of synchronising
> an access to), the most likely scenario here is that your hooking code and
> a callback routine just get at odds with one another whille trying to
> modify the same resource that neither of them owns, effectively leaving it
> in inconsistent state . Simple,ugh…
>
>
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>

Don_Burn · June 21, 2016, 9:48am

ZwTerminateThread was one of the nastiest calls to hook properly back in the days hooking was acceptable. When I did it for NT4, Windows 2000 and Windows XP for a product we ended up with a significant number of test cases that had to be run on every OS, since each OS treated things differently and depending on the state of things code that seemed to be fine would crash for a different case.

As Max said, the answer now is don’t hook, you won’t be able to make it work on a supported version of Windows. For your playing all I can say is check the stack, ZwTerminateThread does a number of non-standard returns.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ariel Koren
Sent: Tuesday, June 21, 2016 9:41 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] PsCreateProcessNotifyRoutine and ZwTerminateProcess conflict!

any idea how to overcome this issue? I had the same idea in my mind

On Tue, Jun 21, 2016 at 4:39 PM, > wrote:

> Can anyone give me any hints? \ Anyone knows what exactly is going on that is
> making the program crash?

Well, taking into consideration the fact that you modify page tables (i.e. the resources that you don’t own and, hence, have no means of synchronising an access to), the most likely scenario here is that your hooking code and a callback routine just get at odds with one another whille trying to modify the same resource that neither of them owns, effectively leaving it in inconsistent state . Simple,ugh…

Anton Bassov

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:

— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:>

OSR_Community_User · June 21, 2016, 9:53am

so DonBurn, you suggest i should reverse nt!PspTerminateThreadByPointer
and follow leads from there… well i suppose there is no other choice if no
one experienced those kind of scenarios before

On Tue, Jun 21, 2016 at 4:47 PM, Don Burn wrote:

> ZwTerminateThread was one of the nastiest calls to hook properly back in
> the days hooking was acceptable. When I did it for NT4, Windows 2000 and
> Windows XP for a product we ended up with a significant number of test
> cases that had to be run on every OS, since each OS treated things
> differently and depending on the state of things code that seemed to be
> fine would crash for a different case.
>
> As Max said, the answer now is don’t hook, you won’t be able to make it
> work on a supported version of Windows. For your playing all I can say is
> check the stack, ZwTerminateThread does a number of non-standard returns.
>
>
> Don Burn
> Windows Driver Consulting
> Website: http://www.windrvr.com
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of Ariel Koren
> Sent: Tuesday, June 21, 2016 9:41 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] PsCreateProcessNotifyRoutine and ZwTerminateProcess
> conflict!
>
> any idea how to overcome this issue? I had the same idea in my mind
>
> On Tue, Jun 21, 2016 at 4:39 PM, > xxxxx@hotmail.com> > wrote:
>
>
> > Can anyone give me any hints? \ Anyone knows what exactly is
> going on that is
> > making the program crash?
>
> Well, taking into consideration the fact that you modify page
> tables (i.e. the resources that you don’t own and, hence, have no means of
> synchronising an access to), the most likely scenario here is that your
> hooking code and a callback routine just get at odds with one another
> whille trying to modify the same resource that neither of them owns,
> effectively leaving it in inconsistent state . Simple,ugh…
>
>
>
> Anton Bassov
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals
> and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
>
>
>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>

dhananjay_kr · June 21, 2016, 10:28am

Can you please share the !analyze -v output as well?

On Tue, Jun 21, 2016 at 7:22 PM, Ariel Koren
wrote:

> so DonBurn, you suggest i should reverse nt!PspTerminateThreadByPointer
> and follow leads from there… well i suppose there is no other choice if no
> one experienced those kind of scenarios before
>
> On Tue, Jun 21, 2016 at 4:47 PM, Don Burn wrote:
>
>> ZwTerminateThread was one of the nastiest calls to hook properly back in
>> the days hooking was acceptable. When I did it for NT4, Windows 2000 and
>> Windows XP for a product we ended up with a significant number of test
>> cases that had to be run on every OS, since each OS treated things
>> differently and depending on the state of things code that seemed to be
>> fine would crash for a different case.
>>
>> As Max said, the answer now is don’t hook, you won’t be able to make it
>> work on a supported version of Windows. For your playing all I can say is
>> check the stack, ZwTerminateThread does a number of non-standard returns.
>>
>>
>> Don Burn
>> Windows Driver Consulting
>> Website: http://www.windrvr.com
>>
>>
>>
>> -----Original Message-----
>> From: xxxxx@lists.osr.com [mailto:
>> xxxxx@lists.osr.com] On Behalf Of Ariel Koren
>> Sent: Tuesday, June 21, 2016 9:41 AM
>> To: Windows System Software Devs Interest List
>> Subject: Re: [ntdev] PsCreateProcessNotifyRoutine and ZwTerminateProcess
>> conflict!
>>
>> any idea how to overcome this issue? I had the same idea in my mind
>>
>> On Tue, Jun 21, 2016 at 4:39 PM, >> xxxxx@hotmail.com> > wrote:
>>
>>
>> > Can anyone give me any hints? \ Anyone knows what exactly is
>> going on that is
>> > making the program crash?
>>
>> Well, taking into consideration the fact that you modify page
>> tables (i.e. the resources that you don’t own and, hence, have no means of
>> synchronising an access to), the most likely scenario here is that your
>> hooking code and a callback routine just get at odds with one another
>> whille trying to modify the same resource that neither of them owns,
>> effectively leaving it in inconsistent state . Simple,ugh…
>>
>>
>>
>> Anton Bassov
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list online at: <
>> http://www.osronline.com/showlists.cfm?list=ntdev>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals
>> and software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer>
>>
>>
>>
>> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
>> on crash dump analysis, WDF, Windows internals and software drivers!
>> Details at To unsubscribe, visit the List Server section of OSR Online at
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list online at: <
>> http://www.osronline.com/showlists.cfm?list=ntdev>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer>
>>
>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on crash dump analysis, WDF, Windows internals and software drivers!
> Details at To unsubscribe, visit the List Server section of OSR Online at
></http:></http:>

OSR_Community_User · June 21, 2016, 11:32am

Anton is rigth, the PFN database is obviously something your driver doesn’t own. You don’t even tell us if you are using the PFN database lock which is not a documented thing anyway.

Now because MiDeleteAddressesInWorkingSet is present in the stack, I think your driver is involved is sone conflict with the paging system.

That is the main conflict.

OSR_Community_User · June 21, 2016, 1:31pm

But it still doesnt explain why it is only occurring when i am hooking
‘ZwTerminateProcess’!!!
like if the function would work “as usual” i will get no problem at all!

Maybe its because of PreviousMode issue? like if i am running from
KernelMode or UserMode?
What are the differences internally when calling ZwTerminateProcess with
each of those states?

here is the analyze -v

kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling
MmUnlockPages twice with the same list, etc). If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 00000099, A PTE or PFN is corrupt
Arg2: 00006824, page frame number
Arg3: 00000000, current page state
Arg4: 00000000, 0

Debugging Details:

BUGCHECK_STR: 0x4E_99

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: calc.exe

ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre

LAST_CONTROL_TRANSFER: from 804f8afd to 8052a5d8

STACK_TEXT:
f4201780 804f8afd 00000003 f4201adc 00000000
nt!RtlpBreakWithStatusInstruction
f42017cc 804f96e8 00000003 c03fb780 80f2f07c nt!KiBugCheckDebugBreak+0x19
f4201bac 804f9c37 0000004e 00000099 00006824 nt!KeBugCheck2+0x574
f4201bcc 80510b92 0000004e 00000099 00006824 nt!KeBugCheckEx+0x1b
f4201c04 805aec1b 7f6f0119 857d1ce0 007ffff8 nt!MiDeleteValidAddress+0x156
f4201c24 80512655 857d1ce0 857d1e18 857d1ce0
nt!MiDeleteAddressesInWorkingSet+0x65
f4201c58 805d0ed7 007d1ce0 86437020 86437268
nt!MmCleanProcessAddressSpace+0x193
f4201ce0 805d109a 00000000 86437020 00000000 nt!PspExitThread+0x621
f4201d00 805d1275 86437020 00000000 f4201d64
nt!PspTerminateThreadByPointer+0x52
f4201d2c f41248e3 00000000 00000000 000001d8 nt!NtTerminateProcess+0x105
*f4201d54 8054060c ffffffff 00000000 0007fee4
MyDriverXp!My_NtTerminateProcess+0x43 *
f4201d54 7c90eb94 ffffffff 00000000 0007fee4 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0007fee4 00000000 00000000 00000000 00000000 0x7c90eb94

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!MiDeleteValidAddress+156
80510b92 8b5808 mov ebx,dword ptr [eax+8]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!MiDeleteValidAddress+156

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b0d

IMAGE_VERSION: 5.1.2600.2180

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: 0x4E_99_nt!MiDeleteValidAddress+156

BUCKET_ID: 0x4E_99_nt!MiDeleteValidAddress+156

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x4e_99_nt!mideletevalidaddress+156

FAILURE_ID_HASH: {275a6ae7-3547-e621-1982-0de035d268ff}

Followup: MachineOwner

On Tue, Jun 21, 2016 at 6:31 PM, wrote:

> Anton is rigth, the PFN database is obviously something your driver
> doesn’t own. You don’t even tell us if you are using the PFN database lock
> which is not a documented thing anyway.
>
> Now because MiDeleteAddressesInWorkingSet is present in the stack, I think
> your driver is involved is sone conflict with the paging system.
>
> That is the main conflict.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>

Don_Burn · June 21, 2016, 1:41pm

I haven’t worked on this stuff for over 10 years, since basically it has been that long since it was legal for all systems. When I did there were cases where basically, any change to the stack could cause potential crashes. You could not call the original ZwTerminateThread from your code in a normal manner, but instead had to do all kinds of weird stack games to get it to work. My solution is owned by my client, but I remember it was quite a bit of work (at least a man-month to make things totally stable), and it needed refreshes when a new service pack occurred.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ariel Koren
Sent: Tuesday, June 21, 2016 1:31 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] PsCreateProcessNotifyRoutine and ZwTerminateProcess conflict!

But it still doesnt explain why it is only occurring when i am hooking ‘ZwTerminateProcess’!!!
like if the function would work “as usual” i will get no problem at all!

Maybe its because of PreviousMode issue? like if i am running from KernelMode or UserMode?
What are the differences internally when calling ZwTerminateProcess with each of those states?

here is the analyze -v

kd> !analyze -v

Bugcheck Analysis

PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling MmUnlockPages twice with the same list, etc). If a kernel debugger is available get the stack trace.
Arguments:
Arg1: 00000099, A PTE or PFN is corrupt
Arg2: 00006824, page frame number
Arg3: 00000000, current page state
Arg4: 00000000, 0

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

BUGCHECK_STR: 0x4E_99

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: calc.exe

ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre

LAST_CONTROL_TRANSFER: from 804f8afd to 8052a5d8

STACK_TEXT:
f4201780 804f8afd 00000003 f4201adc 00000000 nt!RtlpBreakWithStatusInstruction f42017cc 804f96e8 00000003 c03fb780 80f2f07c nt!KiBugCheckDebugBreak+0x19 f4201bac 804f9c37 0000004e 00000099 00006824 nt!KeBugCheck2+0x574 f4201bcc 80510b92 0000004e 00000099 00006824 nt!KeBugCheckEx+0x1b
f4201c04 805aec1b 7f6f0119 857d1ce0 007ffff8 nt!MiDeleteValidAddress+0x156
f4201c24 80512655 857d1ce0 857d1e18 857d1ce0 nt!MiDeleteAddressesInWorkingSet+0x65
f4201c58 805d0ed7 007d1ce0 86437020 86437268 nt!MmCleanProcessAddressSpace+0x193
f4201ce0 805d109a 00000000 86437020 00000000 nt!PspExitThread+0x621
f4201d00 805d1275 86437020 00000000 f4201d64 nt!PspTerminateThreadByPointer+0x52
f4201d2c f41248e3 00000000 00000000 000001d8 nt!NtTerminateProcess+0x105
f4201d54 8054060c ffffffff 00000000 0007fee4 MyDriverXp!My_NtTerminateProcess+0x43
f4201d54 7c90eb94 ffffffff 00000000 0007fee4 nt!KiFastCallEntry+0xfc
WARNING: Frame IP not in any known module. Following frames may be wrong.
0007fee4 00000000 00000000 00000000 00000000 0x7c90eb94

STACK_COMMAND: kb

FOLLOWUP_IP:
nt!MiDeleteValidAddress+156
80510b92 8b5808 mov ebx,dword ptr [eax+8]

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: nt!MiDeleteValidAddress+156

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b0d

IMAGE_VERSION: 5.1.2600.2180

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: 0x4E_99_nt!MiDeleteValidAddress+156

BUCKET_ID: 0x4E_99_nt!MiDeleteValidAddress+156

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x4e_99_nt!mideletevalidaddress+156

FAILURE_ID_HASH: {275a6ae7-3547-e621-1982-0de035d268ff}

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

On Tue, Jun 21, 2016 at 6:31 PM, > wrote:

Anton is rigth, the PFN database is obviously something your driver doesn’t own. You don’t even tell us if you are using the PFN database lock which is not a documented thing anyway.

Now because MiDeleteAddressesInWorkingSet is present in the stack, I think your driver is involved is sone conflict with the paging system.

That is the main conflict.

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:

— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:>

anton_bassov · June 21, 2016, 2:26pm

> But it still doesnt explain why it is only occurring when i am hooking ‘ZwTerminateProcess’!!!

like if the function would work “as usual” i will get no problem at all!

Simply because sometimes “it takes two to tango”…

As long as you modify the resource that you don’t own only on a single code path in context of a single thread, and its legitimate owner does not modify it THAT often, you may get away with the whole thing for quite a while, because the chances of a conflict that may leave your target resource in inconsistent state are fairly low. It does not mean that your code is safe - the only thing it means is that its flaws and fallacies are yet to reveal themselves. This is the reason why testing your code on a busy multiprocessor system under heavy load happens to be one of the most efficient ways of detecting bugs that may otherwise go unnoticed for quite a while under more “peaceful” execuion scenarios.

However, the more code paths attempt to modify this resource without acquiring a synch construct that protects it, the higher the chance of leaving it in inconsistent state. You code falls into “broken by design” class, and the more code paths execute it simultaneosly, the more obvious its logical fallacy becomes. Is it so difficult to understand???

Anton Bassov

OSR_Community_User · June 21, 2016, 6:27pm

>in my PsCreateProcessNotifyRoutine CallBack i am implementing some logic to edit the page tables of a specific process, and when terminating it, i want to restore the physical pages to be as they were before i changed them (Just for a clean cleanup procedure)

This is not possible as a physical page can be attributed to another process by the memory manager’s paging system while the process is running and no longer be owned by that process when it is exiting.

My guess is that your driver is “reattributing” a physical page to a process when it terminates, but that process is no longuer the owner of the physical page because the memory manager’s paging system has attributed the page to another process.

Does your work take the paging system in consideration ?

OSR_Community_User · June 22, 2016, 2:56am

My guess is that your driver is “reattributing” a physical page to a
process when it terminates, but that process is no longuer the owner of the
physical page because the memory manager’s paging system has attributed the
page to another process.

Does your work take the paging system in consideration ?

well… i am basically changing a page which is mapped from another process
it is not the Original’s process allocated page… it is a mapped page from
CSRSS (CsrSrvSharedSectionBase). The only thing that is related to me,
after the process exists, the reference counter is decreased. i am aware of
that.

@xxxxx@hotmail.com
However, the more code paths attempt to modify this resource without
acquiring a synch construct that protects it, the higher the chance of
leaving it in inconsistent state. You code falls into “broken by design”
class, and the more code paths execute it simultaneosly, the more obvious
its logical fallacy becomes. Is it so difficult to understand???

its not difficult to understand, i just want to know exactly what happens
internally… what you are saying is like “CreateProcess” wont work because
you give it a dll path, i want to know what is the difference between a dll
and an exe file… i want to know why it wont work!!! what happens
internally… how can you expect me to accept that something is not supposed
to work just because you say its obvious? its not obvious for me and i want
to know.

Also there is always a way to make it work once you understand it good
enough… so this is where i am aiming and this is what im trying to achieve
asking this question in this forums… have i gone to the wrong place?

On Wed, Jun 22, 2016 at 1:27 AM, wrote:

> >in my PsCreateProcessNotifyRoutine CallBack i am implementing some
> logic to edit the page tables of a specific process, and when terminating
> it, i want to restore the physical pages to be as they were before i
> changed them (Just for a clean cleanup procedure)
>
> This is not possible as a physical page can be attributed to another
> process by the memory manager’s paging system while the process is running
> and no longer be owned by that process when it is exiting.
>
> My guess is that your driver is “reattributing” a physical page to a
> process when it terminates, but that process is no longuer the owner of the
> physical page because the memory manager’s paging system has attributed the
> page to another process.
>
> Does your work take the paging system in consideration ?
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>

MBond · June 22, 2016, 7:33am

The whole point of this discussion is that there can never exist a way to do this and the more you understand about the problem the more obvious that becomes

That is not to say that there is no way to achieve your true objective, just that modifying page tables is not a valid method to do anything except cause crashes

This in fact has nothing to do with Windows KM programming per se, but elementary multi-thread programming: any resource that is not owned completely or currently (appropriate lock acquired etc.) must not be modified and can be read for indicative purposes only

Sent from Mailhttps: for Windows 10

From: Ariel Korenmailto:xxxxx
Sent: June 22, 2016 2:56 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] PsCreateProcessNotifyRoutine and ZwTerminateProcess conflict!

My guess is that your driver is “reattributing” a physical page to a process when it terminates, but that process is no longuer the owner of the physical page because the memory manager’s paging system has attributed the page to another process.

Does your work take the paging system in consideration ?

well… i am basically changing a page which is mapped from another process it is not the Original’s process allocated page… it is a mapped page from CSRSS (CsrSrvSharedSectionBase). The only thing that is related to me, after the process exists, the reference counter is decreased. i am aware of that.

@xxxxx@hotmail.commailto:xxxxx
However, the more code paths attempt to modify this resource without acquiring a synch construct that protects it, the higher the chance of leaving it in inconsistent state. You code falls into “broken by design” class, and the more code paths execute it simultaneosly, the more obvious its logical fallacy becomes. Is it so difficult to understand???

its not difficult to understand, i just want to know exactly what happens internally… what you are saying is like “CreateProcess” wont work because you give it a dll path, i want to know what is the difference between a dll and an exe file… i want to know why it wont work!!! what happens internally… how can you expect me to accept that something is not supposed to work just because you say its obvious? its not obvious for me and i want to know.

Also there is always a way to make it work once you understand it good enough… so this is where i am aiming and this is what im trying to achieve asking this question in this forums… have i gone to the wrong place?

On Wed, Jun 22, 2016 at 1:27 AM, > wrote:
>in my PsCreateProcessNotifyRoutine CallBack i am implementing some logic to edit the page tables of a specific process, and when terminating it, i want to restore the physical pages to be as they were before i changed them (Just for a clean cleanup procedure)

This is not possible as a physical page can be attributed to another process by the memory manager’s paging system while the process is running and no longer be owned by that process when it is exiting.

My guess is that your driver is “reattributing” a physical page to a process when it terminates, but that process is no longuer the owner of the physical page because the memory manager’s paging system has attributed the page to another process.

Does your work take the paging system in consideration ?

—
NTDEV is sponsored by OSR

Visit the list online at: http:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:

— NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers! Details at To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></https:>

anton_bassov · June 22, 2016, 7:48am

>how can you expect me to accept that something is not supposed to work just because

you say its obvious? its not obvious for me and i want to know.

Well, if it is not obvious to you that accessing any resource that may possibly be shared requires locking certain semaphores or other synch constructs…well, then I am afraid all bets are off…

Also there is always a way to make it work once you understand it good enough.

Only if you understand the whole thing well enough to accept the idea that your code just cannot be made work fine even in theory, so that you decide to redesign your whole solution, including even the requirements. It has nothing to do with hooking per se - as long as you try to access any shared resource without locking it first, your code is broken by design and cannot be made safe.
Sorry, but this is just one of the most fundemantal principles that an aspiring system-level programmer has to learn…

Anton Bassov