Kernel_Security_Check_Failure

[tuscaniman]

Recently I've been having issues with my PC kicking me out of games with only a Windows has stopped working error. I have receive various BSOD. I've had some pool_corruption BSOD and now I received a new one. I have been checking my RAM with memtest and swapped out sticks. I still have 1 more to test out but I don't think it is my ram. Anyone have any ideas what my issue could be? I ran windows debugger on my most recent BSOD. Here are the results.

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: fffff8800f27be10, Address of the trap frame for the exception that caused the bugcheck
Arg3: fffff8800f27bd68, Address of the exception record for the exception that caused the bugcheck
Arg4: 0000000000000000, Reserved

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


TRAP_FRAME: fffff8800f27be10 -- (.trap 0xfffff8800f27be10)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa800958c750 rbx=0000000000000000 rcx=0000000000000003
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8014381c8f9 rsp=fffff8800f27bfa0 rbp=0000000000000000
r8=0000000000000000 r9=fffff780000003b0 r10=fffff78000000008
r11=fffffa8009535200 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt! ?? ::FNODOBFM::`string'+0x11515:
fffff801`4381c8f9 cd29 int 29h
Resetting default scope

EXCEPTION_RECORD: fffff8800f27bd68 -- (.exr 0xfffff8800f27bd68)
ExceptionAddress: fffff8014381c8f9 (nt! ?? ::FNODOBFM::`string'+0x0000000000011515)
ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
ExceptionFlags: 00000001
NumberParameters: 1
Parameter[0]: 0000000000000003

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: LIST_ENTRY_CORRUPT

BUGCHECK_STR: 0x139

PROCESS_NAME: bf3.exe

CURRENT_IRQL: 2

ERROR_CODE: (NTSTATUS) 0xc0000409 - 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.

EXCEPTION_CODE: (NTSTATUS) 0xc0000409 - 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.

EXCEPTION_PARAMETER1: 0000000000000003

LAST_CONTROL_TRANSFER: from fffff8014388d669 to fffff8014388e340

STACK_TEXT:
fffff880`0f27bae8 fffff801`4388d669 : 00000000`00000139 00000000`00000003 fffff880`0f27be10 fffff880`0f27bd68 : nt!KeBugCheckEx
fffff880`0f27baf0 fffff801`4388d990 : fffffa80`06a9f238 00000000`00000001 00000000`00000000 fffffa80`06a9f000 : nt!KiBugCheckDispatch+0x69
fffff880`0f27bc30 fffff801`4388cbf4 : 00000000`00000000 00000000`00000000 fffffa80`07a27df0 00000000`21548fff : nt!KiFastFailDispatch+0xd0
fffff880`0f27be10 fffff801`4381c8f9 : 00000000`00000000 fffffa80`0d11cae0 fffffa80`0d02d740 fffff801`4388d353 : nt!KiRaiseSecurityCheckFailure+0xf4
fffff880`0f27bfa0 fffff801`4387cd76 : fffffa80`0958c748 00000000`00000022 00000000`00000000 fffffa80`0c689400 : nt! ?? ::FNODOBFM::`string'+0x11515
fffff880`0f27c030 fffff801`438cb645 : 00000000`00000001 fffff880`064058f2 fffffa80`0c689400 fffff8a0`13eebed0 : nt!ExpAcquireFastMutexContended+0x4e
fffff880`0f27c070 fffff880`06caf615 : fffff8a0`143a8010 fffff880`06403157 00000000`00000000 fffff8a0`13eebe90 : nt!ExAcquireFastMutex+0x45
fffff880`0f27c0a0 fffff8a0`143a8010 : fffff880`06403157 00000000`00000000 fffff8a0`13eebe90 fffffa80`095351f0 : atikmdag+0xae615
fffff880`0f27c0a8 fffff880`06403157 : 00000000`00000000 fffff8a0`13eebe90 fffffa80`095351f0 fffff801`43a812ba : 0xfffff8a0`143a8010
fffff880`0f27c0b0 fffff880`0643e4b6 : fffff880`0f27c120 fffffa80`06e75920 fffff8a0`14c0e460 fffff8a0`143a8128 : dxgmms1!DXGFASTMUTEX::Acquire+0xf
fffff880`0f27c0f0 00000000`00000000 : fffff880`0f27c170 fffff880`06cb5597 fffff8a0`143a8010 fffff8a0`14e45bf0 : dxgmms1!VIDMM_LINEAR_POOL::FreeBlock+0x62


STACK_COMMAND: kb

FOLLOWUP_IP:
atikmdag+ae615
fffff880`06caf615 ?? ???

SYMBOL_STACK_INDEX: 7

SYMBOL_NAME: atikmdag+ae615

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: atikmdag

IMAGE_NAME: atikmdag.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 51083631

FAILURE_BUCKET_ID: 0x139_3_atikmdag+ae615

BUCKET_ID: 0x139_3_atikmdag+ae615

Followup: MachineOwner

 

[johnbl]

Most likely a driver bug where a driver tried to free the same kernel memory object twice. Or something corrupted the list of memory objects. (this can be caused by issues with RAM, or a bad driver that overwrites into memory that is should not)

the problem is hard to track down because by default the checks are not done at the time the driver asks to free the memory but at some time later when the system actually tries to free up blocks of memory.
if you know what driver you suspect, you can run driver verifier on it and turn on checking and it will bugcheck when the actual problem occurs. Problem is for a graphics driver it will really slow down your driver and may actually obscure the issue and make it harder to find.

-and again it can be other drivers that actually stomp on memory and change links in the linked list data structure.

- and it can be virus that do this on purpose to gain access to kernel data structures.

I generally do the following:
check your OS files by running
sfc.exe /scannow
then start updating 3rd party software that has device drivers
free virus scanners screw up a lot, then old software that has drivers.

as to if this is a hardware issue, you can rotate your RAM to new memory slots. You do this in the hopes that if one of your ram sticks has a issue you can move the issue from kernel memory space to user memory space. (crashing a usermode program just causes a app fault. much better than crashing a kernel mode program that will bugcheck your OS)

-I would update my ati graphics driver.
- also, windows 8 does more checking of memory structures (to fight off virus attacks)
and will bugcheck rather than just ignore the bad kernel call.

 

[jpishgar]

Best answer selected by jpishgar.

 

[Dark Lord of Tech]

This topic has been closed by SR-71 Blackbird