I have a Mini-Filter with a port set up. Frequently, when a call comes into
my port, and then my driver tries to access the registry using ZwOpenKey, I
get a bugchk. Once the registry was corrupted and had to be restored from
backup.
I have looked at the path parameter and it is clean. The attributes struct
also looks clean as far as I can tell. This exact same path is called every
time my driver loads and it has never crashed there.
Has anyone else ever seen ZwOpenKey crash in a user process in a driver?
I’m really stuck on this.
I have tried this with OBJ_KERNEL_HANDLE on and off and it didn’t make any
difference.
----------- code ----------
InitializeObjectAttributes( &attr, &path, OBJ_CASE_INSENSITIVE |
OBJ_KERNEL_HANDLE, NULL, NULL);
status = ZwOpenKey( &key, KEY_READ, &attr);
--------- attr-------------
Length: 0x18
RootDirectory: 0
ObjectName:
\Registry\Machine\System\CurrentControlSet\Services\DeqoCPS\Options
SecurityDescriptor: 0
SecurityQualityOfService: 0
You must be at PASSIVE_LEVEL to call ZwOpenKey. If
that isn’t it, post a !analyze -v.
— Mark Hahn wrote:
> I have a Mini-Filter with a port set up.
> Frequently, when a call comes into
> my port, and then my driver tries to access the
> registry using ZwOpenKey, I
> get a bugchk. Once the registry was corrupted and
> had to be restored from
> backup.
>
> I have looked at the path parameter and it is clean.
> The attributes struct
> also looks clean as far as I can tell. This exact
> same path is called every
> time my driver loads and it has never crashed there.
>
> Has anyone else ever seen ZwOpenKey crash in a user
> process in a driver?
> I’m really stuck on this.
>
> I have tried this with OBJ_KERNEL_HANDLE on and off
> and it didn’t make any
> difference.
>
> ----------- code ----------
> InitializeObjectAttributes( &attr, &path,
> OBJ_CASE_INSENSITIVE |
> OBJ_KERNEL_HANDLE, NULL, NULL);
> status = ZwOpenKey( &key, KEY_READ, &attr);
>
> --------- attr-------------
> Length: 0x18
> RootDirectory: 0
> ObjectName:
>
\Registry\Machine\System\CurrentControlSet\Services\DeqoCPS\Options
> SecurityDescriptor: 0
> SecurityQualityOfService: 0
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
“Randy Cook” wrote in message news:xxxxx@ntfsd…
> You must be at PASSIVE_LEVEL to call ZwOpenKey. If
> that isn’t it, post a !analyze -v.
Isn’t a user process always at passive level? What code can I put at the
call to check if it is passive level or not? In any case, here is my
!analyze -v :
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 8053cdbe, The address that the exception occurred at
Arg3: abbdd588, Exception Record Address
Arg4: abbdd284, Context Record Address
Debugging Details:
------------------
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced
memory at “0x%08lx”. The memory could not be “%s”.
FAULTING_IP:
nt!fputwc+14
8053cdbe 668902 mov [edx],ax
EXCEPTION_PARAMETER1: abbdd588
CONTEXT: abbdd284 – (.cxr ffffffffabbdd284)
Couldn’t resolve error at ‘ffffffffabbdd284’
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x7E
EXCEPTION_RECORD: abbdd588 – (.exr ffffffffabbdd588)
Couldn’t resolve error at ‘ffffffffabbdd588’
LAST_CONTROL_TRANSFER: from 805ce75a to 804f9c37
STACK_TEXT:
abbdd090 805ce75a 0000007e c0000005 8053cdbe nt!KeBugCheckEx+0x1b
abbdd0ac 805ce7ba abbdd0d4 80538b01 abbdd0dc
nt!PspUnhandledExceptionInSystemThread+0x1a
abbddddc 805450ce b9e6f018 00000000 00000000 nt!PspSystemThreadStartup+0x5a
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND: .bugcheck ; kb
FOLLOWUP_IP:
nt!fputwc+14
8053cdbe 668902 mov [edx],ax
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!fputwc+14
MODULE_NAME: nt
IMAGE_NAME: ntkrpamp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1e
FAILURE_BUCKET_ID: 0x7E_nt!fputwc+14
BUCKET_ID: 0x7E_nt!fputwc+14
This really has me baffled. I thought maybe I had stack corruption or some
other problem that was only coincidentally showing up as a bugchk in
ZwOpenKey, but I disabled that single call and now it runs flawlessly.
Does anyone have any idea what I could be doing to cause ZwOpenKey to
bugchk?
“Randy Cook” wrote in message news:xxxxx@ntfsd…
> You must be at PASSIVE_LEVEL to call ZwOpenKey. If
> that isn’t it, post a !analyze -v.
>
> — Mark Hahn wrote:
>
>> I have a Mini-Filter with a port set up.
>> Frequently, when a call comes into
>> my port, and then my driver tries to access the
>> registry using ZwOpenKey, I
>> get a bugchk. Once the registry was corrupted and
>> had to be restored from
>> backup.
>>
>> I have looked at the path parameter and it is clean.
>> The attributes struct
>> also looks clean as far as I can tell. This exact
>> same path is called every
>> time my driver loads and it has never crashed there.
>>
>> Has anyone else ever seen ZwOpenKey crash in a user
>> process in a driver?
>> I’m really stuck on this.
>>
>> I have tried this with OBJ_KERNEL_HANDLE on and off
>> and it didn’t make any
>> difference.
>>
>> ----------- code ----------
>> InitializeObjectAttributes( &attr, &path,
>> OBJ_CASE_INSENSITIVE |
>> OBJ_KERNEL_HANDLE, NULL, NULL);
>> status = ZwOpenKey( &key, KEY_READ, &attr);
>>
>> --------- attr-------------
>> Length: 0x18
>> RootDirectory: 0
>> ObjectName:
>>
> \Registry\Machine\System\CurrentControlSet\Services\DeqoCPS\Options
>> SecurityDescriptor: 0
>> SecurityQualityOfService: 0
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as:
>> xxxxx@yahoo.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
Have you tried with Driver Verifier on?
Where does your memory buffer come from? Do you
allocate it or is it passed to you from user mode?
KeGetCurrentIrql
— Mark Hahn wrote:
> “Randy Cook” wrote in message
> news:xxxxx@ntfsd…
> > You must be at PASSIVE_LEVEL to call ZwOpenKey.
> If
> > that isn’t it, post a !analyze -v.
>
> Isn’t a user process always at passive level? What
> code can I put at the
> call to check if it is passive level or not? In
> any case, here is my
> !analyze -v :
>
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
> This is a very common bugcheck. Usually the
> exception address pinpoints
> the driver/function that caused the problem. Always
> note this address
> as well as the link date of the driver/image that
> contains this address.
> Arguments:
> Arg1: c0000005, The exception code that was not
> handled
> Arg2: 8053cdbe, The address that the exception
> occurred at
> Arg3: abbdd588, Exception Record Address
> Arg4: abbdd284, Context Record Address
> Debugging Details:
> ------------------
>
> ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction
> at “0x%08lx” referenced
> memory at “0x%08lx”. The memory could not be “%s”.
> FAULTING_IP:
> nt!fputwc+14
> 8053cdbe 668902 mov [edx],ax
> EXCEPTION_PARAMETER1: abbdd588
> CONTEXT: abbdd284 – (.cxr ffffffffabbdd284)
> Couldn’t resolve error at ‘ffffffffabbdd284’
> DEFAULT_BUCKET_ID: DRIVER_FAULT
> BUGCHECK_STR: 0x7E
> EXCEPTION_RECORD: abbdd588 – (.exr
> ffffffffabbdd588)
> Couldn’t resolve error at ‘ffffffffabbdd588’
> LAST_CONTROL_TRANSFER: from 805ce75a to 804f9c37
> STACK_TEXT:
> abbdd090 805ce75a 0000007e c0000005 8053cdbe
> nt!KeBugCheckEx+0x1b
> abbdd0ac 805ce7ba abbdd0d4 80538b01 abbdd0dc
> nt!PspUnhandledExceptionInSystemThread+0x1a
> abbddddc 805450ce b9e6f018 00000000 00000000
> nt!PspSystemThreadStartup+0x5a
> 00000000 00000000 00000000 00000000 00000000
> nt!KiThreadStartup+0x16
>
> STACK_COMMAND: .bugcheck ; kb
> FOLLOWUP_IP:
> nt!fputwc+14
> 8053cdbe 668902 mov [edx],ax
> FOLLOWUP_NAME: MachineOwner
> SYMBOL_NAME: nt!fputwc+14
> MODULE_NAME: nt
> IMAGE_NAME: ntkrpamp.exe
> DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1e
> FAILURE_BUCKET_ID: 0x7E_nt!fputwc+14
> BUCKET_ID: 0x7E_nt!fputwc+14
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
Thanks for the input. You’ve given me things to work on.
Have you tried with Driver Verifier on?
I will do that.
Where does your memory buffer come from? Do you
allocate it or is it passed to you from user mode?
I am not sure what memory buffer you are referring to. My ObjectAttributes
are in a buffer I allocate right before the call. There is no other buffer
associated with ZwOpenKey.
My mini-filter is running code called from a user mode port call, so does
that mean my driver is in “user mode”?
“Randy Cook” wrote in message news:xxxxx@ntfsd…
> Have you tried with Driver Verifier on?
>
> Where does your memory buffer come from? Do you
> allocate it or is it passed to you from user mode?
>
> KeGetCurrentIrql
>
> — Mark Hahn wrote:
>
>> “Randy Cook” wrote in message
>> news:xxxxx@ntfsd…
>> > You must be at PASSIVE_LEVEL to call ZwOpenKey.
>> If
>> > that isn’t it, post a !analyze -v.
>>
>> Isn’t a user process always at passive level? What
>> code can I put at the
>> call to check if it is passive level or not? In
>> any case, here is my
>> !analyze -v :
>>
>> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
>> This is a very common bugcheck. Usually the
>> exception address pinpoints
>> the driver/function that caused the problem. Always
>> note this address
>> as well as the link date of the driver/image that
>> contains this address.
>> Arguments:
>> Arg1: c0000005, The exception code that was not
>> handled
>> Arg2: 8053cdbe, The address that the exception
>> occurred at
>> Arg3: abbdd588, Exception Record Address
>> Arg4: abbdd284, Context Record Address
>> Debugging Details:
>> ------------------
>>
>> ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction
>> at “0x%08lx” referenced
>> memory at “0x%08lx”. The memory could not be “%s”.
>> FAULTING_IP:
>> nt!fputwc+14
>> 8053cdbe 668902 mov [edx],ax
>> EXCEPTION_PARAMETER1: abbdd588
>> CONTEXT: abbdd284 – (.cxr ffffffffabbdd284)
>> Couldn’t resolve error at ‘ffffffffabbdd284’
>> DEFAULT_BUCKET_ID: DRIVER_FAULT
>> BUGCHECK_STR: 0x7E
>> EXCEPTION_RECORD: abbdd588 – (.exr
>> ffffffffabbdd588)
>> Couldn’t resolve error at ‘ffffffffabbdd588’
>> LAST_CONTROL_TRANSFER: from 805ce75a to 804f9c37
>> STACK_TEXT:
>> abbdd090 805ce75a 0000007e c0000005 8053cdbe
>> nt!KeBugCheckEx+0x1b
>> abbdd0ac 805ce7ba abbdd0d4 80538b01 abbdd0dc
>> nt!PspUnhandledExceptionInSystemThread+0x1a
>> abbddddc 805450ce b9e6f018 00000000 00000000
>> nt!PspSystemThreadStartup+0x5a
>> 00000000 00000000 00000000 00000000 00000000
>> nt!KiThreadStartup+0x16
>>
>> STACK_COMMAND: .bugcheck ; kb
>> FOLLOWUP_IP:
>> nt!fputwc+14
>> 8053cdbe 668902 mov [edx],ax
>> FOLLOWUP_NAME: MachineOwner
>> SYMBOL_NAME: nt!fputwc+14
>> MODULE_NAME: nt
>> IMAGE_NAME: ntkrpamp.exe
>> DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1e
>> FAILURE_BUCKET_ID: 0x7E_nt!fputwc+14
>> BUCKET_ID: 0x7E_nt!fputwc+14
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as:
>> xxxxx@yahoo.com
>> To unsubscribe send a blank email to
>> xxxxx@lists.osr.com
>>
>
>
Your object attributes structure points to a unicode
string structure which points to a buffer. Do you
allocate all three of those memory locations or are
any passed to you?
The thread stack you posted is not the faulting thread
stack. Usually you can display the proper thread
stack by executing the “.cxr ffffffffabbdd284” that is
displayed, but maybe that’s not working in this case?
The proper call stack would verify for you that your
call to ZwOpenKey is resulting in the fputwc call that
is blowing up. If it is, then it seems to me that you
are either passing bad args or doing it at a time when
it is not safe to make the call.
— Mark Hahn wrote:
> Thanks for the input. You’ve given me things to
> work on.
>
> > Have you tried with Driver Verifier on?
>
> I will do that.
>
> > Where does your memory buffer come from? Do you
> > allocate it or is it passed to you from user mode?
>
> I am not sure what memory buffer you are referring
> to. My ObjectAttributes
> are in a buffer I allocate right before the call.
> There is no other buffer
> associated with ZwOpenKey.
>
> My mini-filter is running code called from a user
> mode port call, so does
> that mean my driver is in “user mode”?
>
>
> “Randy Cook” wrote in message
> news:xxxxx@ntfsd…
> > Have you tried with Driver Verifier on?
> >
> > Where does your memory buffer come from? Do you
> > allocate it or is it passed to you from user mode?
> >
> > KeGetCurrentIrql
> >
> > — Mark Hahn wrote:
> >
> >> “Randy Cook” wrote in
> message
> >> news:xxxxx@ntfsd…
> >> > You must be at PASSIVE_LEVEL to call ZwOpenKey.
> >> If
> >> > that isn’t it, post a !analyze -v.
> >>
> >> Isn’t a user process always at passive level?
> What
> >> code can I put at the
> >> call to check if it is passive level or not? In
> >> any case, here is my
> >> !analyze -v :
> >>
> >> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
> >> This is a very common bugcheck. Usually the
> >> exception address pinpoints
> >> the driver/function that caused the problem.
> Always
> >> note this address
> >> as well as the link date of the driver/image that
> >> contains this address.
> >> Arguments:
> >> Arg1: c0000005, The exception code that was not
> >> handled
> >> Arg2: 8053cdbe, The address that the exception
> >> occurred at
> >> Arg3: abbdd588, Exception Record Address
> >> Arg4: abbdd284, Context Record Address
> >> Debugging Details:
> >> ------------------
> >>
> >> ERROR_CODE: (NTSTATUS) 0xc0000005 - The
> instruction
> >> at “0x%08lx” referenced
> >> memory at “0x%08lx”. The memory could not be
> “%s”.
> >> FAULTING_IP:
> >> nt!fputwc+14
> >> 8053cdbe 668902 mov [edx],ax
> >> EXCEPTION_PARAMETER1: abbdd588
> >> CONTEXT: abbdd284 – (.cxr ffffffffabbdd284)
> >> Couldn’t resolve error at ‘ffffffffabbdd284’
> >> DEFAULT_BUCKET_ID: DRIVER_FAULT
> >> BUGCHECK_STR: 0x7E
> >> EXCEPTION_RECORD: abbdd588 – (.exr
> >> ffffffffabbdd588)
> >> Couldn’t resolve error at ‘ffffffffabbdd588’
> >> LAST_CONTROL_TRANSFER: from 805ce75a to 804f9c37
> >> STACK_TEXT:
> >> abbdd090 805ce75a 0000007e c0000005 8053cdbe
> >> nt!KeBugCheckEx+0x1b
> >> abbdd0ac 805ce7ba abbdd0d4 80538b01 abbdd0dc
> >> nt!PspUnhandledExceptionInSystemThread+0x1a
> >> abbddddc 805450ce b9e6f018 00000000 00000000
> >> nt!PspSystemThreadStartup+0x5a
> >> 00000000 00000000 00000000 00000000 00000000
> >> nt!KiThreadStartup+0x16
> >>
> >> STACK_COMMAND: .bugcheck ; kb
> >> FOLLOWUP_IP:
> >> nt!fputwc+14
> >> 8053cdbe 668902 mov [edx],ax
> >> FOLLOWUP_NAME: MachineOwner
> >> SYMBOL_NAME: nt!fputwc+14
> >> MODULE_NAME: nt
> >> IMAGE_NAME: ntkrpamp.exe
> >> DEBUG_FLR_IMAGE_TIMESTAMP: 42250a1e
> >> FAILURE_BUCKET_ID: 0x7E_nt!fputwc+14
> >> BUCKET_ID: 0x7E_nt!fputwc+14
> >>
> >>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> >> https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as:
> >> xxxxx@yahoo.com
> >> To unsubscribe send a blank email to
> >> xxxxx@lists.osr.com
> >>
> >
> >
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>