KeUpdateSystemTime BSOD

Hi All,

I got a BSOD in my close request, my driver verifier is enabled, I can’t understand the dump file.

In the close request, I try to free the memory, then it got the BSOD. From the dump file, it said that memory was referenced after it was freed, but the memory address I try to free is not the address as the dump showed, the memory I free is the first time to free from verifier log.

Here is the dump:
PAGE_FAULT_IN_FREED_SPECIAL_POOL (cc)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.
Arguments:
Arg1: fffff9804a48ef60, memory referenced
Arg2: 0000000000000001, value 0 = read operation, 1 = write operation
Arg3: fffff800016e8dba, if non-zero, the address which referenced memory.
Arg4: 0000000000000000, Mm internal code.

Debugging Details:

WRITE_ADDRESS: fffff9804a48ef60

FAULTING_IP:
nt!RtlSplay+9c
fffff800`016e8dba 498910 mov qword ptr [r8],rdx

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xCC

PROCESS_NAME: test2.exe

CURRENT_IRQL: d

MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0x0 (0)
Child-SP RetAddr Call Site
00000000052db5c0 00000000052dbbd0 mscorlib_ni!UNKNOWN+0x3b

EXCEPTION_RECORD: fffffa8000000000 – (.exr 0xfffffa8000000000)
ExceptionAddress: 0000000000000000
ExceptionCode: 00000000
ExceptionFlags: 00000000
NumberParameters: 0

LAST_CONTROL_TRANSFER: from fffff800016cc5f7 to fffff8000167052f

STACK_TEXT:
fffff8800add4f10 fffff800016cc5f7 nt! ?? ::FNODOBFM::string'+0x4f4a fffff8800add4fa0 fffff80001613895 nt!KeUpdateSystemTime+0x377 fffff8800add50a0 fffff800016c03f3 hal!HalpHpetClockInterrupt+0x8d fffff8800add50d0 fffff800016d74fa nt!KiInterruptDispatchNoLock+0x163 fffff8800add5260 fffff80001772a56 nt!KiIpiSendRequestEx+0xaa fffff8800add52a0 fffff800017c978d nt!KeFlushSingleTb+0x126 fffff8800add5320 fffff800017f5356 nt!MmFreeSpecialPool+0x34d fffff8800add5460 fffff88009a1175f nt!ExFreePool+0x9f3 fffff8800add5510 fffff88009a1286d MyDriver!RemoveInfoFromTable+0x13f fffff8800add5580 fffff88009a14ebd MyDriver!RemoveElementFromTable+0x26d fffff8800add5630 fffff88009a497ad MyDriver!CloseHandler+0x1d fffff8800add5660 fffff88009a0d701 MyDriver!FileCloseHandler+0x1d fffff8800add5690 fffff88001507c3e MyDriver!ClosePreOperationHandler+0xe1 fffff8800add5700 fffff880014c9027 fltmgr!FltvPreOperation+0xbe fffff8800add5810 fffff880014c9be9 fltmgr!FltpPerformPreCallbacks+0x2f7 fffff8800add5910 fffff880014c86c7 fltmgr!FltpPassThrough+0x2d9 fffff8800add5990 fffff80001b69c16 fltmgr!FltpDispatch+0xb7 fffff8800add59f0 fffff800019d740e nt!IovCallDriver+0x566 fffff8800add5a50 fffff800016c90b4 nt!IopDeleteFile+0x11e fffff8800add5ae0 fffff800019d7194 nt!ObfDereferenceObject+0xd4 fffff8800add5b40 fffff800019d7094 nt!ObpCloseHandleTableEntry+0xc4 fffff8800add5bd0 fffff800016c3153 nt!ObpCloseHandle+0x94 fffff8800add5c20 000000007746ffaa nt!KiSystemServiceCopyEnd+0x13 00000000052db3d8 000007fefd451843 ntdll!NtClose+0xa 00000000052db3e0 0000000077222c41 KERNELBASE!CloseHandle+0x13 00000000052db410 000007feee15cd27 KERNEL32!CloseHandleImplementation+0x3d 00000000052db520 000007feed349abb mscorwks!DoNDirectCall__PatchGetThreadCall+0x7b 00000000052db5c0 00000000052dbbd0 mscorlib_ni+0x399abb 00000000052db5c8 000007feed025d00 0x52dbbd0 00000000052db5d0 00000000`00000000 mscorlib_ni+0x75d00

So from the stack trace, you can see that I try to free the pool, why it got the bad memory reference in “KeUpdateSystemTime”?

I checked the memory fffff9804a48ef60 in Arg1 with verifier, this is my memory which was allocated and freed in another thread, It looks normal as I seen as following:

======================================================================
Pool block fffff9804a48ef60, Size 00000000000000a0, Thread fffffa80247ebaa0
fffff80001b5ec9a nt!VfFreePoolNotification+0x4a
fffff800017f5215 nt!ExFreePool+0x881
fffff80001b6792b nt!VerifierExFreePool+0x1b
fffff88009a36c8c MyDriver!ExFreeToPagedLookasideList+0x5c
fffff88009a435ff MyDriver!UserInfoFree+0x1f
fffff80001764ca7 nt!RtlDeleteElementGenericTable+0x57
fffff88009a434f6 MyDriver!DeleteElementGenericTableWithLock+0x36
fffff88009a117d6 MyDriver!RemoveInfoFromTable+0x1b6
fffff88009a1286d MyDriver!RemoveElementFromTable+0x26d
fffff88009a14ebd MyDriver!CloseHandler+0x1d
fffff88009a497ad MyDriver!FileCloseHandler+0x1d
fffff88009a0d701 MyDriver!ClosePreOperationHandler+0xe1
fffff88001507c3e fltmgr!FltvPreOperation+0xbe

Pool block fffff9804a48ef60, Size 0000000000000095, Thread fffffa80247ebaa0
fffff80001b5f026 nt!VeAllocatePoolWithTagPriority+0x2b6
fffff80001b5f09d nt!VerifierExAllocatePoolEx+0x1d
fffff88009a1fcf8 MyDriver!ExAllocateFromNPagedLookasideList+0x68
fffff88009a435b3 MyDriver!GtiUserInfoAllocate+0x23
fffff8000175cf49 nt!RtlInsertElementGenericTableFull+0x39
fffff8000175d048 nt!RtlInsertElementGenericTable+0x48
fffff88009a43458 MyDriver!GtInsertElementUserInfoTableWithLock+0x58
fffff88009a113f1 MyDriver!AddInfoToTable+0xf1
fffff88009a4b0dc MyDriver!ProcessFileRequest+0x19c
fffff88009a4bcf2 MyDriver!ProcessPreCreate+0x2e2
fffff88009a4c61d MyDriver!PreCreateOperationHandler+0x2ed
fffff88009a0d491 MyDriver!CreatePreOperationHandler+0x161
fffff88001507c3e fltmgr!FltvPreOperation+0xbe
Parsed entry 0000000000010000/0000000000010000…
Finished parsing all pool tracking information.

I am very appreciated if anyone can shed light on this issue.

Thanks

So when was the referenced memory last freed?

This looks like a pool corruption issue to me. Rather than assume it’s the memory you were freeing at that moment, you probably want to look deeper and figure out where that memory came from and when it was freed. Discovering pool corruption after the fact is common and it is typically reported by the first thread to touch the memory AFTER the corruption.

Tony
OSR

>This looks like a pool corruption issue to me.

And (for the OP, not for you): Verifier Special Pool option helps a lot.


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

Seems found the issue, but I still can’t understand why.

I have a RTL_GENERIC_TABLE, it will insert the element in the create request, it will delete the element in the close request.

In Cleanup request, I need to checkup the table, get the element, the problem is I use the mutex here is different with other places, after I fixed this issue, then I issue is gone.