system crash with CcFlushCache and MmFlushImageSection.

NTFSD
1

I am writing a mini filter driver.

Earlier I was not using Exclusive locks with CcFlushCache and MmFlushImageSection(with write flag) so Whenever this was called, crash was generating with:
IRQL_NOT_LESS_OR_EQUAL
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(with access denied)

After that I tried to use Resource and Paging Resource lock from FxContext.
But When ExAcquireResourceAcquireLite() is called then I am getting same bug check as above.
I checked in my function that irql is 0. But when crash is generated with IRQL_NOT_LESS_OR_EQUAL after that irql is 2.

In SYSTEM_THREAD_EXCEPTION_NOT_HANDLED bug check irql is still 0.

I am not getting what to do ? why I am getting crash on this ?

::::::::::::::::::::SYSTEM_THREAD_EXCEPTIO_NOT_HANDLED:::::::::::::::::::::::::::
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

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: ffffffffc0000005, The exception code that was not handled
Arg2: fffff8025c0ddc1c, The address that the exception occurred at
Arg3: ffffd00099f16288, Exception Record Address
Arg4: ffffd00099f15a90, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
nt!KxWaitForLockOwnerShipWithIrql+14
fffff802`5c0ddc1c 48890a mov qword ptr [rdx],rcx

EXCEPTION_RECORD: ffffd00099f16288 – (.exr 0xffffd00099f16288)
ExceptionAddress: fffff8025c0ddc1c (nt!KxWaitForLockOwnerShipWithIrql+0x0000000000000014)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000001
Parameter[1]: 000000000007d3e4
Attempt to write to address 000000000007d3e4

CONTEXT: ffffd00099f15a90 – (.cxr 0xffffd00099f15a90;r)
rax=0000000000000000 rbx=0000000000000000 rcx=ffffd00099f16510
rdx=000000000007d3e4 rsi=ffffe001b3692040 rdi=ffffd00099f16510
rip=fffff8025c0ddc1c rsp=ffffd00099f164c0 rbp=0000000000000001
r8=ffffd00099f16560 r9=ffffe001b3692788 r10=0000000000000000
r11=ffffe001b3692788 r12=0000000000000000 r13=0000000000000000
r14=0000000000010001 r15=0000000000000000
iopl=0 nv up di pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010046
nt!KxWaitForLockOwnerShipWithIrql+0x14:
fffff8025c0ddc1c 48890a mov qword ptr [rdx],rcx ds:002b:000000000007d3e4=???
Last set context:
rax=0000000000000000 rbx=0000000000000000 rcx=ffffd00099f16510
rdx=000000000007d3e4 rsi=ffffe001b3692040 rdi=ffffd00099f16510
rip=fffff8025c0ddc1c rsp=ffffd00099f164c0 rbp=0000000000000001
r8=ffffd00099f16560 r9=ffffe001b3692788 r10=0000000000000000
r11=ffffe001b3692788 r12=0000000000000000 r13=0000000000000000
r14=0000000000010001 r15=0000000000000000
iopl=0 nv up di pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010046
nt!KxWaitForLockOwnerShipWithIrql+0x14:
fffff8025c0ddc1c 48890a mov qword ptr [rdx],rcx ds:002b:000000000007d3e4=???
Resetting default scope

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 0000000000000001

EXCEPTION_PARAMETER2: 000000000007d3e4

WRITE_ADDRESS: 000000000007d3e4 Paged pool

FOLLOWUP_IP:
vmmgmt!vm_rdwr_lock+52 [c:\work\6.0_beta\p\fspem\inc\arch_windows.h @ 333]
fffff801`8dc4ea72 0fb6c0 movzx eax,al

BUGCHECK_STR: AV

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

LAST_CONTROL_TRANSFER: from fffff8025c0a5a6c to fffff8025c0ddc1c

STACK_TEXT:
ffffd00099f164c0 fffff8025c0a5a6c : ffffe001b5fe34c0 fffff8018d2aad51 fffffa8000000000 ffffe001b3692001 : nt!KxWaitForLockOwnerShipWithIrql+0x14
ffffd00099f164f0 fffff8025c68b6b9 : ffffe001b3692002 ffffe001b3692040 0000000000000080 ffffe001b5fe34c0 : nt!ExAcquireResourceExclusiveLite+0x21c
ffffd00099f16560 fffff8018dc4ea72 : ffffe001b3692040 ffffcf8082fbaff0 0000000000000010 0000000000010282 : nt!VerifierExAcquireResourceExclusiveLite+0x35
ffffd00099f165a0 fffff8018dceb8db : ffffe001b5fe34c0 ffffe00100000001 ffffe00100000001 fffff80100000001 : vmmgmt!vm_rdwr_lock+0x52 [c:\work\6.0_beta\p\fspem\inc\arch_windows.h @ 333]
ffffd00099f165d0 fffff8018dc4b4fd : ffffe001b5fe3538 ffffc0016d05e720 0000000000000000 fffff80100000001 : vmmgmt!PurgeFile+0x7b [c:\work\6.0_beta\p\fspem\vss\windows\lib\srvc\vsfile.cpp @ 840]
ffffd00099f16620 fffff8018dc3b0dd : ffffe001b39fe070 ffffcf808344aec0 0000000000000000 ffffd00000000001 : vmmgmt!VmOpenedFiles+0x73d [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmopenedfiles.cpp @ 334]
ffffd00099f16720 fffff8018dc3a7ec : ffffe001b39fe070 ffffe001b62bf044 0000000000000001 ffffd00099f167f8 : vmmgmt!VmProtectVolumeDir+0x54d [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguard.cpp @ 269]
ffffd00099f167b0 fffff8018dc3df42 : ffffe001b62bf044 fffff80100000000 ffffe00100000000 0000000000000000 : vmmgmt!VmProtectDirectory+0x2dc [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguard.cpp @ 488]
ffffd00099f16830 fffff8018dc567b5 : ffffe001b62bf044 ffffcf8000001000 0000000000000000 ffffd00000000001 : vmmgmt!VmGuardList+0x192 [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguardlist.cpp @ 140]
ffffd00099f16890 fffff8018dc80a23 : ffffe001b62bf030 ffffcf8000000000 fffff8018dd149d0 ffffcf8083300fe0 : vmmgmt!vm_guard_cfg+0xc5 [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_win_syscfg.c @ 120]
ffffd00099f16910 fffff8018dc81a23 : ffffcf8000000003 ffffd00099f16b40 fffff80100000000 ffffe001b591a3d0 : vmmgmt!vm_do_ussd_cmd+0xd43 [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_cfg_upd.c @ 1293]
ffffd00099f16ab0 fffff8025c0db794 : ffffcf805c178fc0 0b0b0b0b0b0b0b0b 0b0b0b0b0b0b0b0b 0b0b0b0b0b0b0b0b : vmmgmt!vm_guardupdate_thread+0xcf3 [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_cfg_upd.c @ 2036]
ffffd00099f16c00 fffff8025c1665c6 : ffffd00099567180 ffffe001b3692040 ffffd000995732c0 0b0b0b0b0b0b0b0b : nt!PspSystemThreadStartup+0x58
ffffd00099f16c60 0000000000000000 : ffffd00099f17000 ffffd00099f11000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

FAULTING_SOURCE_LINE: c:\work\6.0_beta\p\fspem\inc\arch_windows.h

FAULTING_SOURCE_FILE: c:\work\6.0_beta\p\fspem\inc\arch_windows.h

FAULTING_SOURCE_LINE_NUMBER: 333

FAULTING_SOURCE_CODE:
329: }
330: if(writeaccess == 0){
331: return ExAcquireResourceSharedLite(rwlock, (BOOLEAN) wait);
332: }else{

333: return ExAcquireResourceExclusiveLite(rwlock, (BOOLEAN) wait);
334: }
335: }
336: static void vm_rdwr_unlock(vm_rdwr_t* rwlock, int critical, u_int64_t thread){
337: if(thread){
338: ExReleaseResourceForThreadLite(rwlock, (ERESOURCE_THREAD) thread);

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: vmmgmt!vm_rdwr_lock+52

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: vmmgmt

IMAGE_NAME: vmmgmt.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5433dbc9

STACK_COMMAND: .cxr 0xffffd00099f15a90 ; kb

BUCKET_ID_FUNC_OFFSET: 52

FAILURE_BUCKET_ID: AV_VRF_vmmgmt!vm_rdwr_lock

BUCKET_ID: AV_VRF_vmmgmt!vm_rdwr_lock

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:av_vrf_vmmgmt!vm_rdwr_lock

FAILURE_ID_HASH: {62c43094-d81d-5e36-ec76-670c6adf0533}

Followup: MachineOwner

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::;

::::::::::::::::::::IRQL_NOT_LESS_OR_EQUAL::::::::::::::::::::::::::::::::::::::::::::::
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000000c00d0001, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff8021fece9f9, address which referenced memory

Debugging Details:

WRITE_ADDRESS: 00000000c00d0001 Paged pool

CURRENT_IRQL: 2

FAULTING_IP:
nt!ExpWaitForResource+1c9
fffff802`1fece9f9 f00fba2e07 lock bts dword ptr [rsi],7

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: AV

PROCESS_NAME: System

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

TRAP_FRAME: ffffd000c0d5b2a0 – (.trap 0xffffd000c0d5b2a0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=000000000002c0ef rbx=0000000000000000 rcx=0000000690fe958f
rdx=ffffd000c0d5b3e0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8021fece9f9 rsp=ffffd000c0d5b430 rbp=0000000000000001
r8=0000000000000000 r9=fffff780000003b0 r10=fffff78000000008
r11=ffffd000c0d5b400 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
nt!ExpWaitForResource+0x1c9:
fffff8021fece9f9 f00fba2e07 lock bts dword ptr [rsi],7 ds:0000000000000000=???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80220053a46 to fffff8021ffd0b90

STACK_TEXT:
ffffd000c0d5a9a8 fffff80220053a46 : 0000000000000000 0000000000000000 ffffd000c0d5ab10 fffff8021fec08cc : nt!DbgBreakPointWithStatus
ffffd000c0d5a9b0 fffff80220053357 : 0000000000000003 ffffd000c0d5ab10 fffff8021ffd7f80 000000000000000a : nt!KiBugCheckDebugBreak+0x12
ffffd000c0d5aa10 fffff8021ffca0a4 : ffffe00172bff880 fffff8021ff1f858 0000000000000000 0000000000000000 : nt!KeBugCheck2+0x8ab
ffffd000c0d5b120 fffff8021ffd5ae9 : 000000000000000a 00000000c00d0001 0000000000000002 0000000000000001 : nt!KeBugCheckEx+0x104
ffffd000c0d5b160 fffff8021ffd433a : 0000000000000001 ffffe00172bff880 ffff232091ec9500 ffffd000c0d5b2a0 : nt!KiBugCheckDispatch+0x69
ffffd000c0d5b2a0 fffff8021fece9f9 : ffffd000c0d5b401 ffffe00174bddc60 0000000000000001 00000000c00d0001 : nt!KiPageFault+0x23a
ffffd000c0d5b430 fffff8021ff0fa2e : ffffe00174bddc60 00000000c00d0001 fffffa8000000000 ffffe00100000002 : nt!ExpWaitForResource+0x1c9
ffffd000c0d5b4f0 fffff802204f56b9 : ffffe00172bff802 ffffe00172bff880 0000000000000080 ffffe00174bddc60 : nt!ExAcquireResourceExclusiveLite+0x1de
ffffd000c0d5b560 fffff8007647ea72 : ffffe00172bff880 ffffcf814fa1aff0 0000000000000010 0000000000010282 : nt!VerifierExAcquireResourceExclusiveLite+0x35
ffffd000c0d5b5a0 fffff8007651b8d2 : ffffe00174bddc60 ffffe00100000001 ffffe00100000001 fffff80000000001 : vmmgmt!vm_rdwr_lock+0x52 [c:\work\6.0_beta\p\fspem\inc\arch_windows.h @ 333]
ffffd000c0d5b5d0 fffff8007647b4fd : ffffe00174bddcd8 ffffc001d0a13720 0000000000000000 fffff80000000001 : vmmgmt!PurgeFile+0x72 [c:\work\6.0_beta\p\fspem\vss\windows\lib\srvc\vsfile.cpp @ 839]
ffffd000c0d5b620 fffff8007646b0dd : ffffe001731ff070 ffffcf814df20ec0 0000000000000000 ffffd00000000001 : vmmgmt!VmOpenedFiles+0x73d [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmopenedfiles.cpp @ 334]
ffffd000c0d5b720 fffff8007646a7ec : ffffe001731ff070 ffffe00175c36044 0000000000000001 ffffd000c0d5b7f8 : vmmgmt!VmProtectVolumeDir+0x54d [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguard.cpp @ 269]
ffffd000c0d5b7b0 fffff8007646df42 : ffffe00175c36044 fffff80000000000 ffffe00100000000 0000000000000000 : vmmgmt!VmProtectDirectory+0x2dc [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguard.cpp @ 488]
ffffd000c0d5b830 fffff800764867b5 : ffffe00175c36044 ffffcf8100001000 0000000000000000 ffffd00000000001 : vmmgmt!VmGuardList+0x192 [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguardlist.cpp @ 140]
ffffd000c0d5b890 fffff800764b0a23 : ffffe00175c36030 ffffcf8100000000 fffff800765449d0 ffffe001759fa550 : vmmgmt!vm_guard_cfg+0xc5 [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_win_syscfg.c @ 120]
ffffd000c0d5b910 fffff800764b1a23 : ffffe00100000003 ffffd000c0d5bb40 fffff80000000000 ffffcf8171b4afe0 : vmmgmt!vm_do_ussd_cmd+0xd43 [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_cfg_upd.c @ 1293]
ffffd000c0d5bab0 fffff8021ff45794 : ffffcf814bd78fc0 ffffe000a49e8c00 ffffe000a49e8c10 ffffe000a49e8c10 : vmmgmt!vm_guardupdate_thread+0xcf3 [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_cfg_upd.c @ 2036]
ffffd000c0d5bc00 fffff8021ffd05c6 : ffffd000c0367180 ffffe00172bff880 ffffd000c03732c0 ffffe000a49e8c70 : nt!PspSystemThreadStartup+0x58
ffffd000c0d5bc60 0000000000000000 : ffffd000c0d5c000 ffffd000c0d56000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_IP:
vmmgmt!vm_rdwr_lock+52 [c:\work\6.0_beta\p\fspem\inc\arch_windows.h @ 333]
fffff800`7647ea72 0fb6c0 movzx eax,al

FAULTING_SOURCE_LINE: c:\work\6.0_beta\p\fspem\inc\arch_windows.h

FAULTING_SOURCE_FILE: c:\work\6.0_beta\p\fspem\inc\arch_windows.h

FAULTING_SOURCE_LINE_NUMBER: 333

FAULTING_SOURCE_CODE:
329: }
330: if(writeaccess == 0){
331: return ExAcquireResourceSharedLite(rwlock, (BOOLEAN) wait);
332: }else{

333: return ExAcquireResourceExclusiveLite(rwlock, (BOOLEAN) wait);
334: }
335: }
336: static void vm_rdwr_unlock(vm_rdwr_t* rwlock, int critical, u_int64_t thread){
337: if(thread){
338: ExReleaseResourceForThreadLite(rwlock, (ERESOURCE_THREAD) thread);

SYMBOL_STACK_INDEX: 9

SYMBOL_NAME: vmmgmt!vm_rdwr_lock+52

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: vmmgmt

IMAGE_NAME: vmmgmt.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5433c060

BUCKET_ID_FUNC_OFFSET: 52

FAILURE_BUCKET_ID: AV_VRF_vmmgmt!vm_rdwr_lock

BUCKET_ID: AV_VRF_vmmgmt!vm_rdwr_lock

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:av_vrf_vmmgmt!vm_rdwr_lock

FAILURE_ID_HASH: {62c43094-d81d-5e36-ec76-670c6adf0533}

Followup: MachineOwner

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Thanks
Ankit

2

0xC0000005 = STATUS_ACCESS_VIOLATION

This is being raised because the pointer being accessed is a user mode address. Thus, this suggests that you have an invalid pointer. Since the pointer being manipulated is inside the kernel thread dispatcher, it is running at DISPATCH_LEVEL - that’s the nature of how the kernel operates.

What is far more likely is that the lock you are passing into ExAcquireResourceExclusiveLite is invalid.

Your best bet is to start looking at your own frame and figuring out why the lock you are passing into ExAcquire is invalid - perhaps it isn’t initialized, or some other issue, but it looks like a programming bug.

Tony
OSR

3

From what I can tell is the resource pointer is trashed. See what you are
doing with it. Run with verifier maybe you are overwriting it from previous
operations with garbage or release it and use it again.
On Oct 7, 2014 5:57 PM, wrote:

> I am writing a mini filter driver.
>
> Earlier I was not using Exclusive locks with CcFlushCache and
> MmFlushImageSection(with write flag) so Whenever this was called, crash was
> generating with:
> IRQL_NOT_LESS_OR_EQUAL
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED(with access denied)
>
> After that I tried to use Resource and Paging Resource lock from FxContext.
> But When ExAcquireResourceAcquireLite() is called then I am getting same
> bug check as above.
> I checked in my function that irql is 0. But when crash is generated with
> IRQL_NOT_LESS_OR_EQUAL after that irql is 2.
>
> In SYSTEM_THREAD_EXCEPTION_NOT_HANDLED bug check irql is still 0.
>
> I am not getting what to do ? why I am getting crash on this ?
>
>
>
> ::::::::::::::::::::SYSTEM_THREAD_EXCEPTIO_NOT_HANDLED:::::::::::::::::::::::::::
>
> ***
>
>
> * Bugcheck Analysis
>
>
>
>
>
>
> 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: ffffffffc0000005, The exception code that was not handled
> Arg2: fffff8025c0ddc1c, The address that the exception occurred at
> Arg3: ffffd00099f16288, Exception Record Address
> Arg4: ffffd00099f15a90, Context Record Address
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx
> referenced memory at 0x%08lx. The memory could not be %s.
>
> FAULTING_IP:
> nt!KxWaitForLockOwnerShipWithIrql+14
> fffff8025c0ddc1c 48890a mov qword ptr [rdx],rcx<br>&gt;<br>&gt; EXCEPTION_RECORD: ffffd00099f16288 -- (.exr 0xffffd00099f16288)<br>&gt; ExceptionAddress: fffff8025c0ddc1c<br>&gt; (nt!KxWaitForLockOwnerShipWithIrql+0x0000000000000014)<br>&gt; ExceptionCode: c0000005 (Access violation)<br>&gt; ExceptionFlags: 00000000<br>&gt; NumberParameters: 2<br>&gt; Parameter[0]: 0000000000000001<br>&gt; Parameter[1]: 000000000007d3e4<br>&gt; Attempt to write to address 000000000007d3e4<br>&gt;<br>&gt; CONTEXT: ffffd00099f15a90 -- (.cxr 0xffffd00099f15a90;r)<br>&gt; rax=0000000000000000 rbx=0000000000000000 rcx=ffffd00099f16510<br>&gt; rdx=000000000007d3e4 rsi=ffffe001b3692040 rdi=ffffd00099f16510<br>&gt; rip=fffff8025c0ddc1c rsp=ffffd00099f164c0 rbp=0000000000000001<br>&gt; r8=ffffd00099f16560 r9=ffffe001b3692788 r10=0000000000000000<br>&gt; r11=ffffe001b3692788 r12=0000000000000000 r13=0000000000000000<br>&gt; r14=0000000000010001 r15=0000000000000000<br>&gt; iopl=0 nv up di pl zr na po nc<br>&gt; cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b<br>&gt; efl=00010046<br>&gt; nt!KxWaitForLockOwnerShipWithIrql+0x14:<br>&gt; fffff8025c0ddc1c 48890a mov qword ptr [rdx],rcx
> ds:002b:000000000007d3e4=????????????????<br>&gt; Last set context:<br>&gt; rax=0000000000000000 rbx=0000000000000000 rcx=ffffd00099f16510<br>&gt; rdx=000000000007d3e4 rsi=ffffe001b3692040 rdi=ffffd00099f16510<br>&gt; rip=fffff8025c0ddc1c rsp=ffffd00099f164c0 rbp=0000000000000001<br>&gt; r8=ffffd00099f16560 r9=ffffe001b3692788 r10=0000000000000000<br>&gt; r11=ffffe001b3692788 r12=0000000000000000 r13=0000000000000000<br>&gt; r14=0000000000010001 r15=0000000000000000<br>&gt; iopl=0 nv up di pl zr na po nc<br>&gt; cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b<br>&gt; efl=00010046<br>&gt; nt!KxWaitForLockOwnerShipWithIrql+0x14:<br>&gt; fffff8025c0ddc1c 48890a mov qword ptr [rdx],rcx
> ds:002b:000000000007d3e4=????????????????<br>&gt; Resetting default scope<br>&gt;<br>&gt; DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT<br>&gt;<br>&gt; PROCESS_NAME: System<br>&gt;<br>&gt; CURRENT_IRQL: 0<br>&gt;<br>&gt; ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced<br>&gt; memory at 0x%08lx. The memory could not be %s.<br>&gt;<br>&gt; EXCEPTION_PARAMETER1: 0000000000000001<br>&gt;<br>&gt; EXCEPTION_PARAMETER2: 000000000007d3e4<br>&gt;<br>&gt; WRITE_ADDRESS: 000000000007d3e4 Paged pool<br>&gt;<br>&gt; FOLLOWUP_IP:<br>&gt; vmmgmt!vm_rdwr_lock+52 [c:\work\6.0_beta\p\fspem\inc\arch_windows.h @ 333]<br>&gt; fffff8018dc4ea72 0fb6c0 movzx eax,al
>
> BUGCHECK_STR: AV
>
> ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre
>
> LAST_CONTROL_TRANSFER: from fffff8025c0a5a6c to fffff8025c0ddc1c
>
> STACK_TEXT:
> ffffd00099f164c0 fffff8025c0a5a6c : ffffe001b5fe34c0 fffff8018d2aad51
> fffffa8000000000 ffffe001b3692001 : nt!KxWaitForLockOwnerShipWithIrql+0x14
> ffffd00099f164f0 fffff8025c68b6b9 : ffffe001b3692002 ffffe001b3692040
> 0000000000000080 ffffe001b5fe34c0 :
> nt!ExAcquireResourceExclusiveLite+0x21c
> ffffd00099f16560 fffff8018dc4ea72 : ffffe001b3692040 ffffcf8082fbaff0
> 0000000000000010 0000000000010282 :
> nt!VerifierExAcquireResourceExclusiveLite+0x35
> ffffd00099f165a0 fffff8018dceb8db : ffffe001b5fe34c0 ffffe00100000001
> ffffe00100000001 fffff80100000001 : vmmgmt!vm_rdwr_lock+0x52
> [c:\work\6.0_beta\p\fspem\inc\arch_windows.h @ 333]
> ffffd00099f165d0 fffff8018dc4b4fd : ffffe001b5fe3538 ffffc0016d05e720
> 0000000000000000 fffff80100000001 : vmmgmt!PurgeFile+0x7b
> [c:\work\6.0_beta\p\fspem\vss\windows\lib\srvc\vsfile.cpp @ 840]
> ffffd00099f16620 fffff8018dc3b0dd : ffffe001b39fe070 ffffcf808344aec0
> 0000000000000000 ffffd00000000001 : vmmgmt!VmOpenedFiles+0x73d
> [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmopenedfiles.cpp @ 334]
> ffffd00099f16720 fffff8018dc3a7ec : ffffe001b39fe070 ffffe001b62bf044
> 0000000000000001 ffffd00099f167f8 : vmmgmt!VmProtectVolumeDir+0x54d
> [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguard.cpp @ 269]
> ffffd00099f167b0 fffff8018dc3df42 : ffffe001b62bf044 fffff80100000000
> ffffe00100000000 0000000000000000 : vmmgmt!VmProtectDirectory+0x2dc
> [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguard.cpp @ 488]
> ffffd00099f16830 fffff8018dc567b5 : ffffe001b62bf044 ffffcf8000001000
> 0000000000000000 ffffd00000000001 : vmmgmt!VmGuardList+0x192
> [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguardlist.cpp @ 140]
> ffffd00099f16890 fffff8018dc80a23 : ffffe001b62bf030 ffffcf8000000000
> fffff8018dd149d0 ffffcf8083300fe0 : vmmgmt!vm_guard_cfg+0xc5
> [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_win_syscfg.c @ 120]
> ffffd00099f16910 fffff8018dc81a23 : ffffcf8000000003 ffffd00099f16b40
> fffff80100000000 ffffe001b591a3d0 : vmmgmt!vm_do_ussd_cmd+0xd43
> [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_cfg_upd.c @ 1293]
> ffffd00099f16ab0 fffff8025c0db794 : ffffcf805c178fc0 0b0b0b0b0b0b0b0b
> 0b0b0b0b0b0b0b0b 0b0b0b0b0b0b0b0b : vmmgmt!vm_guardupdate_thread+0xcf3
> [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_cfg_upd.c @ 2036]
> ffffd00099f16c00 fffff8025c1665c6 : ffffd00099567180 ffffe001b3692040
> ffffd000995732c0 0b0b0b0b0b0b0b0b : nt!PspSystemThreadStartup+0x58
> ffffd00099f16c60 0000000000000000 : ffffd00099f17000 ffffd00099f11000
> 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
>
>
> FAULTING_SOURCE_LINE: c:\work\6.0_beta\p\fspem\inc\arch_windows.h
>
> FAULTING_SOURCE_FILE: c:\work\6.0_beta\p\fspem\inc\arch_windows.h
>
> FAULTING_SOURCE_LINE_NUMBER: 333
>
> FAULTING_SOURCE_CODE:
> 329: }
> 330: if(writeaccess == 0){
> 331: return ExAcquireResourceSharedLite(rwlock,
> (BOOLEAN) wait);
> 332: }else{
> > 333: return ExAcquireResourceExclusiveLite(rwlock,
> (BOOLEAN) wait);
> 334: }
> 335: }
> 336: static void vm_rdwr_unlock(vm_rdwr_t rwlock, int critical,
> u_int64_t thread){
> 337: if(thread){
> 338: ExReleaseResourceForThreadLite(rwlock,
> (ERESOURCE_THREAD) thread);
>
>
> SYMBOL_STACK_INDEX: 3
>
> SYMBOL_NAME: vmmgmt!vm_rdwr_lock+52
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: vmmgmt
>
> IMAGE_NAME: vmmgmt.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 5433dbc9
>
> STACK_COMMAND: .cxr 0xffffd00099f15a90 ; kb
>
> BUCKET_ID_FUNC_OFFSET: 52
>
> FAILURE_BUCKET_ID: AV_VRF_vmmgmt!vm_rdwr_lock
>
> BUCKET_ID: AV_VRF_vmmgmt!vm_rdwr_lock
>
> ANALYSIS_SOURCE: KM
>
> FAILURE_ID_HASH_STRING: km:av_vrf_vmmgmt!vm_rdwr_lock
>
> FAILURE_ID_HASH: {62c43094-d81d-5e36-ec76-670c6adf0533}
>
> Followup: MachineOwner
> ---------
>
> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::;
>
>
>
> ::::::::::::::::::::IRQL_NOT_LESS_OR_EQUAL::::::::::::::::::::::::::::::::::::::::::::::
> IRQL_NOT_LESS_OR_EQUAL (a)
> An attempt was made to access a pageable (or completely invalid) address
> at an
> interrupt request level (IRQL) that is too high. This is usually
> caused by drivers using improper addresses.
> If a kernel debugger is available get the stack backtrace.
> Arguments:
> Arg1: 00000000c00d0001, memory referenced
> Arg2: 0000000000000002, IRQL
> Arg3: 0000000000000001, bitfield :
> bit 0 : value 0 = read operation, 1 = write operation
> bit 3 : value 0 = not an execute operation, 1 = execute operation
> (only on chips which support this level of status)
> Arg4: fffff8021fece9f9, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> WRITE_ADDRESS: 00000000c00d0001 Paged pool
>
> CURRENT_IRQL: 2
>
> FAULTING_IP:
> nt!ExpWaitForResource+1c9
> fffff8021fece9f9 f00fba2e07 lock bts dword ptr [rsi],7<br>&gt;<br>&gt; DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT<br>&gt;<br>&gt; BUGCHECK_STR: AV<br>&gt;<br>&gt; PROCESS_NAME: System<br>&gt;<br>&gt; ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre<br>&gt;<br>&gt; TRAP_FRAME: ffffd000c0d5b2a0 -- (.trap 0xffffd000c0d5b2a0)<br>&gt; NOTE: The trap frame does not contain all registers.<br>&gt; Some register values may be zeroed or incorrect.<br>&gt; rax=000000000002c0ef rbx=0000000000000000 rcx=0000000690fe958f<br>&gt; rdx=ffffd000c0d5b3e0 rsi=0000000000000000 rdi=0000000000000000<br>&gt; rip=fffff8021fece9f9 rsp=ffffd000c0d5b430 rbp=0000000000000001<br>&gt; r8=0000000000000000 r9=fffff780000003b0 r10=fffff78000000008<br>&gt; r11=ffffd000c0d5b400 r12=0000000000000000 r13=0000000000000000<br>&gt; r14=0000000000000000 r15=0000000000000000<br>&gt; iopl=0 nv up ei pl zr na po nc<br>&gt; nt!ExpWaitForResource+0x1c9:<br>&gt; fffff8021fece9f9 f00fba2e07 lock bts dword ptr [rsi],7
> ds:0000000000000000=????????<br>&gt; Resetting default scope<br>&gt;<br>&gt; LAST_CONTROL_TRANSFER: from fffff80220053a46 to fffff8021ffd0b90<br>&gt;<br>&gt; STACK_TEXT:<br>&gt; ffffd000c0d5a9a8 fffff80220053a46 : 0000000000000000 0000000000000000<br>&gt; ffffd000c0d5ab10 fffff8021fec08cc : nt!DbgBreakPointWithStatus<br>&gt; ffffd000c0d5a9b0 fffff80220053357 : 0000000000000003 ffffd000c0d5ab10<br>&gt; fffff8021ffd7f80 000000000000000a : nt!KiBugCheckDebugBreak+0x12<br>&gt; ffffd000c0d5aa10 fffff8021ffca0a4 : ffffe00172bff880 fffff8021ff1f858<br>&gt; 0000000000000000 0000000000000000 : nt!KeBugCheck2+0x8ab<br>&gt; ffffd000c0d5b120 fffff8021ffd5ae9 : 000000000000000a 00000000c00d0001<br>&gt; 0000000000000002 0000000000000001 : nt!KeBugCheckEx+0x104<br>&gt; ffffd000c0d5b160 fffff8021ffd433a : 0000000000000001 ffffe00172bff880<br>&gt; ffff232091ec9500 ffffd000c0d5b2a0 : nt!KiBugCheckDispatch+0x69<br>&gt; ffffd000c0d5b2a0 fffff8021fece9f9 : ffffd000c0d5b401 ffffe00174bddc60<br>&gt; 0000000000000001 00000000c00d0001 : nt!KiPageFault+0x23a<br>&gt; ffffd000c0d5b430 fffff8021ff0fa2e : ffffe00174bddc60 00000000c00d0001<br>&gt; fffffa8000000000 ffffe00100000002 : nt!ExpWaitForResource+0x1c9<br>&gt; ffffd000c0d5b4f0 fffff802204f56b9 : ffffe00172bff802 ffffe00172bff880<br>&gt; 0000000000000080 ffffe00174bddc60 :<br>&gt; nt!ExAcquireResourceExclusiveLite+0x1de<br>&gt; ffffd000c0d5b560 fffff8007647ea72 : ffffe00172bff880 ffffcf814fa1aff0<br>&gt; 0000000000000010 0000000000010282 :<br>&gt; nt!VerifierExAcquireResourceExclusiveLite+0x35<br>&gt; ffffd000c0d5b5a0 fffff8007651b8d2 : ffffe00174bddc60 ffffe00100000001<br>&gt; ffffe00100000001 fffff80000000001 : vmmgmt!vm_rdwr_lock+0x52<br>&gt; [c:\work\6.0_beta\p\fspem\inc\arch_windows.h @ 333]<br>&gt; ffffd000c0d5b5d0 fffff8007647b4fd : ffffe00174bddcd8 ffffc001d0a13720<br>&gt; 0000000000000000 fffff80000000001 : vmmgmt!PurgeFile+0x72<br>&gt; [c:\work\6.0_beta\p\fspem\vss\windows\lib\srvc\vsfile.cpp @ 839]<br>&gt; ffffd000c0d5b620 fffff8007646b0dd : ffffe001731ff070 ffffcf814df20ec0<br>&gt; 0000000000000000 ffffd00000000001 : vmmgmt!VmOpenedFiles+0x73d<br>&gt; [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmopenedfiles.cpp @ 334]<br>&gt; ffffd000c0d5b720 fffff8007646a7ec : ffffe001731ff070 ffffe00175c36044<br>&gt; 0000000000000001 ffffd000c0d5b7f8 : vmmgmt!VmProtectVolumeDir+0x54d<br>&gt; [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguard.cpp @ 269]<br>&gt; ffffd000c0d5b7b0 fffff8007646df42 : ffffe00175c36044 fffff80000000000<br>&gt; ffffe00100000000 0000000000000000 : vmmgmt!VmProtectDirectory+0x2dc<br>&gt; [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguard.cpp @ 488]<br>&gt; ffffd000c0d5b830 fffff800764867b5 : ffffe00175c36044 ffffcf8100001000<br>&gt; 0000000000000000 ffffd00000000001 : vmmgmt!VmGuardList+0x192<br>&gt; [c:\work\6.0_beta\p\fspem\vss\windows\drv\src\vmguardlist.cpp @ 140]<br>&gt; ffffd000c0d5b890 fffff800764b0a23 : ffffe00175c36030 ffffcf8100000000<br>&gt; fffff800765449d0 ffffe001759fa550 : vmmgmt!vm_guard_cfg+0xc5<br>&gt; [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_win_syscfg.c @ 120]<br>&gt; ffffd000c0d5b910 fffff800764b1a23 : ffffe00100000003 ffffd000c0d5bb40<br>&gt; fffff80000000000 ffffcf8171b4afe0 : vmmgmt!vm_do_ussd_cmd+0xd43<br>&gt; [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_cfg_upd.c @ 1293]<br>&gt; ffffd000c0d5bab0 fffff8021ff45794 : ffffcf814bd78fc0 ffffe000a49e8c00<br>&gt; ffffe000a49e8c10 ffffe000a49e8c10 : vmmgmt!vm_guardupdate_thread+0xcf3<br>&gt; [c:\work\6.0_beta\p\fspem\vmcore\cfg\vm_cfg_upd.c @ 2036]<br>&gt; ffffd000c0d5bc00 fffff8021ffd05c6 : ffffd000c0367180 ffffe00172bff880<br>&gt; ffffd000c03732c0 ffffe000a49e8c70 : nt!PspSystemThreadStartup+0x58<br>&gt; ffffd000c0d5bc60 0000000000000000 : ffffd000c0d5c000 ffffd000c0d56000<br>&gt; 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16<br>&gt;<br>&gt;<br>&gt; STACK_COMMAND: kb<br>&gt;<br>&gt; FOLLOWUP_IP:<br>&gt; vmmgmt!vm_rdwr_lock+52 [c:\work\6.0_beta\p\fspem\inc\arch_windows.h @ 333]<br>&gt; fffff8007647ea72 0fb6c0 movzx eax,al
>
> FAULTING_SOURCE_LINE: c:\work\6.0_beta\p\fspem\inc\arch_windows.h
>
> FAULTING_SOURCE_FILE: c:\work\6.0_beta\p\fspem\inc\arch_windows.h
>
> FAULTING_SOURCE_LINE_NUMBER: 333
>
> FAULTING_SOURCE_CODE:
> 329: }
> 330: if(writeaccess == 0){
> 331: return ExAcquireResourceSharedLite(rwlock,
> (BOOLEAN) wait);
> 332: }else{
> > 333: return ExAcquireResourceExclusiveLite(rwlock,
> (BOOLEAN) wait);
> 334: }
> 335: }
> 336: static void vm_rdwr_unlock(vm_rdwr_t rwlock, int critical,
> u_int64_t thread){
> 337: if(thread){
> 338: ExReleaseResourceForThreadLite(rwlock,
> (ERESOURCE_THREAD) thread);
>
>
> SYMBOL_STACK_INDEX: 9
>
> SYMBOL_NAME: vmmgmt!vm_rdwr_lock+52
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: vmmgmt
>
> IMAGE_NAME: vmmgmt.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 5433c060
>
> BUCKET_ID_FUNC_OFFSET: 52
>
> FAILURE_BUCKET_ID: AV_VRF_vmmgmt!vm_rdwr_lock
>
> BUCKET_ID: AV_VRF_vmmgmt!vm_rdwr_lock
>
> ANALYSIS_SOURCE: KM
>
> FAILURE_ID_HASH_STRING: km:av_vrf_vmmgmt!vm_rdwr_lock
>
> FAILURE_ID_HASH: {62c43094-d81d-5e36-ec76-670c6adf0533}
>
> Followup: MachineOwner
> ---------
>
> :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
>
>
> Thanks
> Ankit
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

Yeah I am running with verifier.

  1. Is it necessary to use resource locks here?

SectionObjectPointer->DataSectionObject OR
SectionObjectPointer->SharedCacheMap OR
SectionObjectPointer->ImageSectionObject OR

Can above these opaque pointers contain low addresses(user mode addresses)? because whenever it generate crash then these addresses were user mode addresses.

5

They should never contain user mode addresses. They should either point to kernel mode locations or 0.

This sounds like some other logic issue, not a serialization issue. Are you sure the SOP is in non-paged pool? You might wish to set an access breakpoint on this in the debugger and find out where these values are being scribbled.

Your driver should never write anything into these fields (other than zeroing them when you first get the buffer allocated).

Tony
OSR