Could you post the .CBS log from here -
http://www.sevenforums.com/tutorials/1538-sfc-scannow-command-system-file-checker.html
Please post the log created by Check Disk -
http://www.sevenforums.com/tutorials/96938-check-disk-chkdsk-read-event-viewer-log.html
Please post the MBAM logs and TDSS logs.
-------------------------------------------------------------
Code:
[COLOR=Red]BugCheck C2[/COLOR], {[COLOR=Blue]7[/COLOR], 1097, 0, [COLOR=SeaGreen]fffffa8008c3c340[/COLOR]}
GetPointerFromAddress: unable to read from fffff80002f030e0
GetUlongFromAddress: unable to read from fffff80002f03198
Probably caused by : [COLOR=Red]win32k.sys[/COLOR] ( win32k!xxxMsgWaitForMultipleObjects+108 )
Code:
0: kd> [COLOR=SeaGreen]dt nt!_KAPC_STATE fffffa80062a6660[/COLOR]
+0x000 ApcListHead : [2] _LIST_ENTRY [ 0x00000000`00000006 - 0xfffffa80`062a6668 ]
+0x020 Process : 0x00000000`672911a0 _KPROCESS
+0x028 KernelApcInProgress : 0x70 'p'
+0x029 KernelApcPending : 0x9d ''
+0x02a UserApcPending : 0x39 '[COLOR=Red]9[/COLOR]'
I don't think the APC data structures have been paged out properly since this is a Minidump. The values of the fields of some of the other structures didn't appear to look right.
Code:
0: kd> [COLOR=SeaGreen]!pool fffffa8008c3c340[/COLOR]
Pool page fffffa8008c3c340 region is Nonpaged pool
fffffa8008c3c000 size: 300 previous size: 0 (Free) TNbl
[COLOR=Red]*fffffa8008c3c300 size: 150 previous size: 300 (Allocated) *File (Protected)[/COLOR]
Pooltag File : [COLOR=Red]File objects[/COLOR]
fffffa8008c3c450 size: 860 previous size: 150 (Free) AfdB
fffffa8008c3ccb0 size: 100 previous size: 860 (Allocated) MmCa
fffffa8008c3cdb0 size: 150 previous size: 100 (Allocated) File (Protected)
fffffa8008c3cf00 size: 100 previous size: 150 (Allocated) MmCa
We can see that the Protected bit has been set for the pool allocation which was being freed, the Protected bit enables the Windows Memory Manager to check that the pool allocation being freed is the intentional one.
Code:
0: kd> [COLOR=SeaGreen]!stack[/COLOR]
Call Stack : [COLOR=Red]12 frames[/COLOR]
## Stack-Pointer Return-Address Call-Site
00 fffff88002399538 fffff80002dfe60e nt!KeBugCheckEx+0
01 fffff88002399540 fffff80002ceacce [COLOR=Red]nt!ExFreePoolWithTag[/COLOR]-1aa2 (perf)
02 fffff880023995f0 fffff80002ca823f [COLOR=Red]nt!IopCompleteRequest[/COLOR]+5ce
03 fffff880023996c0 fffff80002cd2bfd [COLOR=Red]nt!KiDeliverApc[/COLOR]+1d7
04 fffff88002399740 fffff80002cceeeb nt!KiCommitThreadWait+3dd (perf)
05 fffff880023997d0 fffff9600015a46c nt!KeWaitForMultipleObjects+26b (perf)
06 fffff88002399a80 fffff9600015b443 win32k!xxxMsgWaitForMultipleObjects+108
07 fffff88002399b00 fffff96000115098 win32k!xxxDesktopThread+253
08 fffff88002399b80 fffff96000195f9a win32k!xxxCreateSystemThreads+64
09 fffff88002399bb0 fffff80002ccaad3 win32k!NtUserCallNoParam+36
0a fffff88002399be0 000007fefd9c3d5a nt!KiSystemServiceCopyEnd+13
The thread was placed into a wait state, possibly to allow the APC deliver to provide the I/O operation, which lead to the release of the pool allocation which has already been freed.
Code:
0xfffff880023995e8 : 0xfffff80002ceacce : nt!IopCompleteRequest+0x5ce
0xfffff880023995f8 : 0xfffff80002cd177a : nt!KiSwapContext+0x7a
0xfffff88002399610 : 0xfffff88002399628 : 0xfffff9600021656f : win32k!StartDeviceRead+0x1e7
0xfffff88002399618 : 0xfffff960001b9da9 : [COLOR=Red]win32k!ProcessMouseInput[/COLOR]+0x1d5
0xfffff88002399628 : 0xfffff9600021656f : [COLOR=Red]win32k!StartDeviceRead[/COLOR]+0x1e7
0xfffff880023996b8 : 0xfffff80002ca823f : nt!KiDeliverApc+0x1d7
In fact, the APC delivery may have been used, to help service a I/O operation from the mouse.
The File Object within the pool block is most likely the mouse.
Code:
0: kd> [COLOR=SeaGreen]!irql[/COLOR]
Debugger saved IRQL for processor 0x0 -- [COLOR=Red]1 (APC_LEVEL)[/COLOR]
Run
Driver Verifier to scan for any corrupted drivers which may be causing problems, this program works by running various stress tests on drivers, in order to produce a BSOD which will locate the driver; run for
least 24 hours:
