- May 7, 2013
- 10,400
This was a rather interesting crash because it was actually wasn’t caused by a driver but from a scheduled task which had been set to run once the user had logged in. A registry key was being unloaded twice which lead to a double free on a list entry in a linked list. The kernel has some checks in place to prevent this kind of behaviour from being exploited for nefarious means and therefore it very common to always see these bugchecks supplemented with the following exception:
This is often a cause of confusion for many people since they assume that the error was because of a stack buffer overrun. It wasn’t and never usually is.
There are other variations of the above but this is usually the most common one. The exception record does help to show us where the exception was thrown. It is always handled by the fast dispatch exception handler which is used to handle security check failures.
Let’s take a look at the call stack and some of the stack frames which are of interest to us.
There’s a single IOCTL request being handled at the beginning of the call stack, although, this didn’t appear to be relevant to the bugcheck. It was related to reading the light intensity and is typically issued by video streaming devices such as cameras and capture cards. The user was watching videos at the time of the crashes so it may explain why it was consistently present in all the dump files. And I should mention, every dump file had the exact same call stack and each crash occurred exactly 15 minutes from the system booting up. This is was a big clue that the crash was possibly being caused by something which was set to run as a scheduled task at login.
The driver mentioned in the call stack is an unknown Windows registry driver, I haven’t been able to find anything about it in the system logs or through the registry. It’s possible that it may either use a different name while stored on the disk or possibly be dynamically created in memory.
The first parameter is a pointer to the key control block of the registry key which is being unloaded. You can use the !reg kcb command with it to dump the associated registry key path.
The nt!CmpDelayDerefKeyControlBlock function isn’t officially documented by Microsoft but you can find similar code in ReactOS and on GitHub. From the code, it is evident that a linked list is involved and this would explain the Stop 0x139 bugcheck.
A function call just before the function call which causes the Stop 0x139, did have a little more information on what the key was used for.
The process mentioned above is related to Microsoft Office Feature Updater. This process was scheduled to run at login and once the user had removed the scheduled task. The crashes ceased completely.
Rich (BB code):
3: kd> !error c0000409
Error code: (NTSTATUS) 0xc0000409 (3221226505) - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.This is often a cause of confusion for many people since they assume that the error was because of a stack buffer overrun. It wasn’t and never usually is.
Rich (BB code):
KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure. The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: ffff9d0a0598fa50, Address of the trap frame for the exception that caused the bugcheck
Arg3: ffff9d0a0598f9a8, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, ReservedThere are other variations of the above but this is usually the most common one. The exception record does help to show us where the exception was thrown. It is always handled by the fast dispatch exception handler which is used to handle security check failures.
Rich (BB code):
3: kd> .exr 0xffff9d0a0598f9a8
ExceptionAddress: fffff804660e837f (nt!CmpDelayDerefKeyControlBlock+0x0000000000211a0f)
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 0000000000000003
Subcode: 0x3 FAST_FAIL_CORRUPT_LIST_ENTRY
Rich (BB code):
3: kd> !idt 0x29
Dumping IDT: ffffc881f3dcf000
29: fffff80466314d40 nt!KiRaiseSecurityCheckFailureShadowLet’s take a look at the call stack and some of the stack frames which are of interest to us.
Rich (BB code):
3: kd> knL
# Child-SP RetAddr Call Site
00 ffff9d0a`0598f728 fffff804`65c652a9 nt!KeBugCheckEx
01 ffff9d0a`0598f730 fffff804`65c65832 nt!KiBugCheckDispatch+0x69
02 ffff9d0a`0598f870 fffff804`65c63606 nt!KiFastFailDispatch+0xb2
03 ffff9d0a`0598fa50 fffff804`660e837f nt!KiRaiseSecurityCheckFailure+0x346
04 ffff9d0a`0598fbe0 fffff804`65ed68df nt!CmpDelayDerefKeyControlBlock+0x211a0f
05 ffff9d0a`0598fc20 fffff804`65ed3c10 nt!CmpCleanUpKcbCacheWithLock+0xff
06 ffff9d0a`0598fc50 fffff804`65a3d0bb nt!CmpDereferenceKeyControlBlockWithLock+0x8c
07 ffff9d0a`0598fc80 fffff804`65f0cb15 nt!CmpDrainDelayDerefContext+0x9b
08 ffff9d0a`0598fcc0 fffff804`65f0c7b1 nt!CmpCleanUpKCBCacheTable+0xe1
09 ffff9d0a`0598fd50 fffff804`65f0c765 nt!CmpEnumerateAllOpenSubKeys+0x35
0a ffff9d0a`0598fd90 fffff804`65f0b419 nt!CmpDoesKeyHaveOpenSubkeys+0x25
0b ffff9d0a`0598fde0 fffff804`65f0b147 nt!CmpPerformUnloadKey+0x14d
0c ffff9d0a`0598fef0 fffff804`65f0abe9 nt!CmUnloadKey+0x437
0d ffff9d0a`059901a0 fffff804`65c649e5 nt!NtUnloadKey+0x29
0e ffff9d0a`059901e0 fffff804`65c55490 nt!KiSystemServiceCopyEnd+0x25
0f ffff9d0a`05990378 fffff804`65f8c265 nt!KiServiceLinkage
10 ffff9d0a`05990380 fffff804`65f8c143 nt!VrpUnloadDifferencingHive+0xf5
11 ffff9d0a`059903f0 fffff804`65f8ba15 nt!VrpCleanupNamespace+0xa7
12 ffff9d0a`05990430 fffff804`65f8d54d nt!VrpHandleIoctlUnloadDynamicallyLoadedHives+0x15d
13 ffff9d0a`059904e0 fffff804`65b372d7 nt!VrpIoctlDeviceDispatch+0x11d
14 ffff9d0a`05990590 fffff804`662df21f nt!IopfCallDriver+0x53
15 ffff9d0a`059905d0 fffff804`65c7658f nt!IovCallDriver+0x5f
16 ffff9d0a`05990610 fffff804`65ee30b0 nt!IofCallDriver+0x237fef
17 ffff9d0a`05990650 fffff804`65ee4ae7 nt!IopSynchronousServiceTail+0x1d0
18 ffff9d0a`05990700 fffff804`65ee43c6 nt!IopXxxControlFile+0x707
19 ffff9d0a`05990900 fffff804`65c649e5 nt!NtDeviceIoControlFile+0x56
1a ffff9d0a`05990970 00007ffe`a872ee34 nt!KiSystemServiceCopyEnd+0x25
1b 0000008c`845ff1f8 00000000`00000000 0x00007ffe`a872ee34There’s a single IOCTL request being handled at the beginning of the call stack, although, this didn’t appear to be relevant to the bugcheck. It was related to reading the light intensity and is typically issued by video streaming devices such as cameras and capture cards. The user was watching videos at the time of the crashes so it may explain why it was consistently present in all the dump files. And I should mention, every dump file had the exact same call stack and each crash occurred exactly 15 minutes from the system booting up. This is was a big clue that the crash was possibly being caused by something which was set to run as a scheduled task at login.
Rich (BB code):
3: kd> !irp ffff82870b91e010
Irp is active with 1 stacks 1 is current (= 0xffff82870b91e0e0)
No Mdl: System buffer=ffff82870e5cda00: Thread ffff8287061a5040: Irp stack trace.
cmd flg cl Device File Completion-Context
>[IRP_MJ_DEVICE_CONTROL(e), N/A(0)]
5 0 ffff8286e5c9e6f0 ffff82871030f9f0 00000000-00000000
\Driver\WscVReg
Args: 00000000 00000008 0x220018 00000000
Irp Extension present at 0xffff82870b91e128:
Rich (BB code):
3: kd> !ioctldecode 0x220018
IOCTL_LAMP_GET_INTENSITY_COLOR
Device Type : 0x22 (FILE_DEVICE_WINLOAD) (FILE_DEVICE_USER_MODE_BUS) (FILE_DEVICE_USB) (FILE_DEVICE_UNKNOWN)
Method : 0x0 METHOD_BUFFERED
Access : FILE_ANY_ACCESS
Function : 0x6The driver mentioned in the call stack is an unknown Windows registry driver, I haven’t been able to find anything about it in the system logs or through the registry. It’s possible that it may either use a different name while stored on the disk or possibly be dynamically created in memory.
Rich (BB code):
04 ffff9d0a0598fbe0 fffff80465ed68df nt!CmpDelayDerefKeyControlBlock+211a0f (perf)
Parameter[0] = ffff9f07b3e714f0 << Key Control Block
Parameter[1] = ffff9d0a0598fce0 << Thread Change State object
Parameter[2] = (unknown)
Parameter[3] = (unknown)The first parameter is a pointer to the key control block of the registry key which is being unloaded. You can use the !reg kcb command with it to dump the associated registry key path.
Rich (BB code):
3: kd> !reg kcb ffff9f07b3e714f0
Key : \REGISTRY\WC\SILO063A5EE3-F55B-4D51-B5CC-26CE97198778USER_SID\SOFTWARE\MICROSOFT\OFFICE\16.0\COMMON\CLIENTTELEMETRY\RULESMETADATA
RefCount : 0x0000000000000001
Flags : CompressedName,
ExtFlags :
Parent : 0xffff9f07ad88ea60
KeyHive : 0xffff9f07b94b8000
KeyCell : 0x6420 [cell index]
TotalLevels : 10
LayerHeight : 1
MaxNameLen : 0x1a
MaxValueNameLen : 0x0
MaxValueDataLen : 0x0
LastWriteTime : 0x 1d9c89a:0x f038492
KeyBodyListHead : 0xffff9f07b3e71568 0xffff9f07b3e71568
SubKeyCount : 1
Owner : 0x0000000000000000
KCBLock : 0xffff9f07b3e715e8
KeyLock : 0xffff9f07b3e715f8The nt!CmpDelayDerefKeyControlBlock function isn’t officially documented by Microsoft but you can find similar code in ReactOS and on GitHub. From the code, it is evident that a linked list is involved and this would explain the Stop 0x139 bugcheck.
A function call just before the function call which causes the Stop 0x139, did have a little more information on what the key was used for.
Rich (BB code):
06 ffff9d0a0598fc50 fffff80465a3d0bb nt!CmpDereferenceKeyControlBlockWithLock+8c
Parameter[0] = ffff9f07ad896470
Parameter[1] = ffff9d0a0598fce0
Parameter[2] = 0000000000000001
Parameter[3] = (unknown)
Rich (BB code):
3: kd> !reg kcb ffff9f07ad896470
Key : \REGISTRY\WC\SILO063A5EE3-F55B-4D51-B5CC-26CE97198778USER_SID\SOFTWARE\MICROSOFT\OFFICE\16.0\COMMON\CLIENTTELEMETRY\RULESMETADATA\SDXHELPER.EXE
RefCount : 0x0000000000000000
Flags : Decommissioned, CompressedName,
ExtFlags :
Parent : 0xffff9f07b3e714f0
KeyHive : 0xffff9f07b94b8000
KeyCell : 0x38bd0 [cell index]
TotalLevels : 11
LayerHeight : 1
MaxNameLen : 0x14
MaxValueNameLen : 0x0
MaxValueDataLen : 0x0
LastWriteTime : 0x 1d9c89a:0x f038492
KeyBodyListHead : 0xffff9f07ad8964e8 0xffff9f07ad8964e8
SubKeyCount : 1
Owner : 0xffff8287061a5040
KCBLock : 0xffff9f07ad896568
KeyLock : 0xffff9f07ad896578The process mentioned above is related to Microsoft Office Feature Updater. This process was scheduled to run at login and once the user had removed the scheduled task. The crashes ceased completely.