"ntoskrnl.exe" BSOD - Random moments

[timason]

"ntoskrnl.exe" BSOD - Lots of crashes, very frequent

I have been getting "ntoskrnl.exe" driver problem for the last few days. I have tried reinstalling my drivers and I even did a system restore but still remains...

Here are dmp files in the zips.
I can also provide other related files if needed.

Thanks,

Tim

 

[pcunite]

Disk or RAM is bad most likely ... make sure everything is seated well.

 

[timason]

I think its a driver version but i am not sure. My graphic card is Radeon HD 6950...

 

[writhziden]

[list=1]
[*]
Loading Dump File [C:\Users\Mike\Downloads\BSODDmpFiles\timason\Windows_NT6_BSOD_jcgriff2\011912-13306-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\users\mike\documents\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16841.amd64fre.win7_gdr.110622-1503
Machine Name:
Kernel base = 0xfffff800`02c56000 PsLoadedModuleList = 0xfffff800`02e93e70
Debug session time: Thu Jan 19 14:02:40.080 2012 (UTC - 7:00)
System Uptime: 0 days 0:07:48.001
Loading Kernel Symbols
...............................................................
................................................................
....................................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 4E, {99, b5f6c, 2, 1}

Probably caused by : memory_corruption ( nt!MiBadShareCount+4c )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling
MmUnlockPages twice with the same list, etc).  If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 0000000000000099, A PTE or PFN is corrupt
Arg2: 00000000000b5f6c, page frame number
Arg3: 0000000000000002, current page state
Arg4: 0000000000000001, 0

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


BUGCHECK_STR:  0x4E_99

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80002d5613c to fffff80002cc65c0

STACK_TEXT:  
fffff880`0c3536a8 fffff800`02d5613c : 00000000`0000004e 00000000`00000099 00000000`000b5f6c 00000000`00000002 : nt!KeBugCheckEx
fffff880`0c3536b0 fffff800`02c6a407 : 00000000`0005f000 fffffa80`02191410 00000000`00000000 fffff880`0c353878 : nt!MiBadShareCount+0x4c
fffff880`0c3536f0 fffff800`02fda03d : fffff980`048c0000 fffff8a0`0c5b4250 fffffa80`00000000 fffff800`00000000 : nt! ?? ::FNODOBFM::`string'+0x2c11b
fffff880`0c3539d0 fffff800`02cdf3b7 : 00000000`00040000 fffffa80`06a08200 00000000`00000000 00000000`00ac0000 : nt!CcUnmapVacb+0x5d
fffff880`0c353a10 fffff800`02cb6144 : fffffa80`08edfb01 fffffa80`07da2a50 fffffa80`07d86701 00000000`00000000 : nt!CcUnmapVacbArray+0x1b7
fffff880`0c353aa0 fffff800`02cb9bdc : fffffa80`07d867e0 00000000`00000011 fffffa80`07d867e0 fffff800`00000000 : nt!CcDeleteSharedCacheMap+0x140
fffff880`0c353b10 fffff800`02cba3ec : fffff880`069aed00 fffff880`0c353c18 00000000`00000000 fffff880`00000000 : nt!CcWriteBehind+0x5bc
fffff880`0c353bc0 fffff800`02cd37e1 : fffffa80`06a3dee0 fffff880`012f1980 fffff800`02ecd160 00000000`00000002 : nt!CcWorkerThread+0x1c8
fffff880`0c353c70 fffff800`02f666fa : fffff880`0c2140e0 fffffa80`09de6040 00000000`00000080 fffffa80`06a1d040 : nt!ExpWorkerThread+0x111
fffff880`0c353d00 fffff800`02ca4b46 : fffff880`02fd5180 fffffa80`09de6040 fffff880`02fdffc0 fffff880`0126d810 : nt!PspSystemThreadStartup+0x5a
fffff880`0c353d40 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiBadShareCount+4c
fffff800`02d5613c cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!MiBadShareCount+4c

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aa44

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  X64_0x4E_99_nt!MiBadShareCount+4c

BUCKET_ID:  X64_0x4E_99_nt!MiBadShareCount+4c

Followup: MachineOwner
---------
[*]
Loading Dump File [C:\Users\Mike\Downloads\BSODDmpFiles\timason\Windows_NT6_BSOD_jcgriff2\011912-20014-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\users\mike\documents\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16841.amd64fre.win7_gdr.110622-1503
Machine Name:
Kernel base = 0xfffff800`02c0a000 PsLoadedModuleList = 0xfffff800`02e47e70
Debug session time: Thu Jan 19 04:08:55.271 2012 (UTC - 7:00)
System Uptime: 0 days 2:18:05.566
Loading Kernel Symbols
...............................................................
................................................................
....................................
Loading User Symbols
Loading unloaded module list
..........................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 109, {a3a039d8a16c76d2, b3b7465ef3e948c8, fffff80002c13ae5, 1}

*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : memory_corruption

Followup: memory_corruption
---------

2: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
 or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
 debugger that was not attached when the system was booted. Normal breakpoints,
 "bp", can only be set if the debugger is attached at boot time. Hardware
 breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d8a16c76d2, Reserved
Arg2: b3b7465ef3e948c8, Reserved
Arg3: fffff80002c13ae5, Failure type dependent information
Arg4: 0000000000000001, Type of corrupted region, can be
	0 : A generic data region
	1 : Modification of a function or .pdata
	2 : A processor IDT
	3 : A processor GDT
	4 : Type 1 process list corruption
	5 : Type 2 process list corruption
	6 : Debug routine modification
	7 : Critical MSR modification

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


BUGCHECK_STR:  0x109

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  CODE_CORRUPTION

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff80002c7a5c0

STACK_TEXT:  
fffff880`031a8598 00000000`00000000 : 00000000`00000109 a3a039d8`a16c76d2 b3b7465e`f3e948c8 fffff800`02c13ae5 : nt!KeBugCheckEx


STACK_COMMAND:  kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
    fffff80002c13aea - nt! ?? ::FNODOBFM::`string'+2d55
	[ e9:e8 ]
1 error : !nt (fffff80002c13aea)

MODULE_NAME: memory_corruption

IMAGE_NAME:  memory_corruption

FOLLOWUP_NAME:  memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP:  0

MEMORY_CORRUPTOR:  ONE_BIT

FAILURE_BUCKET_ID:  X64_MEMORY_CORRUPTION_ONE_BIT

BUCKET_ID:  X64_MEMORY_CORRUPTION_ONE_BIT

Followup: memory_corruption
---------


[/list]

If you are overclocking anything, please stop.

1. Possible causes are Memory problems... Drivers...
2. Possible causes are Memory problems... Drivers...

Thanks to Dave76 for help understanding possible causes.

• Run the boot version of Memtest86+ paying close attention to Parts 2 and 3 of the tutorial. Also, in case Memtest86+ misses anything and comes up with no errors, run the extended version of the Windows Memory Diagnostics Tool for at least five passes. These you may want to run overnight since they take a long time to complete (run them an hour before bed each of the next two nights and check before going to sleep that they are still running).
  
  
  
• An underlying driver may be incompatible\conflicting with your system. Run Driver Verifier to find any issues. To run Driver Verifier, do the following:
  
  a. Backup your system and user files
  b. Create a system restore point
  c. If you do not have a Windows 7 DVD, Create a system repair disc
  d. Run Driver Verifier
  
  If Windows cannot start in normal mode with driver verifier running, start in safe mode. If it cannot start in safe mode or normal mode, restore the system restore point using http://www.sevenforums.com/tutorials/700-system-restore.html OPTION TWO.
  
  Thanks to zigzag3143 for contributing to the Verifier steps.
  If you are unable to start Windows with all drivers being verified or if the blue screen crashes fail to create .dmp files, run them in groups of 5 or 10 until you find a group that causes blue screen crashes and stores the blue screen .dmp files.​

 

[timason]

Thank you, I am proceeding.

 

[writhziden]

Alright. Post back any .dmp files from the crashes caused by Verifier. That will help to determine any incompatible drivers.

 

[timason]

Ok, now I really don't know, I did the ram test (both of them) but no problem appeared. I reinstalled the system a few times changing a few things in the BIOS. I discovered that my ram wasnt running in MFP (1600mkz) so I fixed that. It seemed to stabilize itself for a few days. But now it restarted, and its something to do with memory as the crash emits a loud noise like ram crash.
Here is some dmp. Thanks for the help.



Tim

 

[writhziden]

Loading Dump File [C:\Users\Mike\Downloads\timason\012812-166047-01\012812-165017-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02c62000 PsLoadedModuleList = 0xfffff800`02ea7670
Debug session time: Sat Jan 28 13:37:23.183 2012 (GMT-7)
System Uptime: 0 days 0:14:52.979
Loading Kernel Symbols
...............................................................
................................................................
..................................
Loading User Symbols
Loading unloaded module list
...
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 4E, {99, 135f6c, 2, 1}

Probably caused by : memory_corruption ( nt!MiBadShareCount+4c )

Followup: MachineOwner
---------

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PFN_LIST_CORRUPT (4e)
Typically caused by drivers passing bad memory descriptor lists (ie: calling
MmUnlockPages twice with the same list, etc).  If a kernel debugger is
available get the stack trace.
Arguments:
Arg1: 0000000000000099, A PTE or PFN is corrupt
Arg2: 0000000000135f6c, page frame number
Arg3: 0000000000000002, current page state
Arg4: 0000000000000001, 0

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


BUGCHECK_STR:  0x4E_99

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  wmpnetwk.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80002d67d7c to fffff80002cdec40

STACK_TEXT:  
fffff880`0c9da2d8 fffff800`02d67d7c : 00000000`0000004e 00000000`00000099 00000000`00135f6c 00000000`00000002 : nt!KeBugCheckEx
fffff880`0c9da2e0 fffff800`02c8e442 : fffffa80`03fa41c0 00000000`00000001 ffffffff`ffffffff fffff880`0c9dab00 : nt!MiBadShareCount+0x4c
fffff880`0c9da320 fffff800`02de069a : fffffa80`06b2c758 fffff880`0c9da530 00000000`00000000 fffffa80`0000000d : nt! ?? ::FNODOBFM::`string'+0x21513
fffff880`0c9da510 fffff800`02f2251d : fffffa80`06d2b060 ffffffff`00000001 ffffffff`ffffffff fffff880`0c9dab60 : nt!MiEmptyWorkingSet+0x24a
fffff880`0c9da5c0 fffff800`0312ffcd : 00000000`00000001 00000000`00000801 00000000`00000000 64536553`00000000 : nt!MmAdjustWorkingSetSizeEx+0xad
fffff880`0c9da640 fffff800`03034aab : 00000000`00000008 00000000`00000000 00000000`00000001 00000000`00fff7f0 : nt!PspSetQuotaLimits+0x32d
fffff880`0c9da790 fffff800`02cdded3 : fffffa80`06d2b060 fffff880`0c9dab60 00000000`0387d6c0 00000000`0387d6c0 : nt! ?? ::NNGAKEGL::`string'+0x4a9b0
fffff880`0c9daae0 00000000`771b14da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`00fff7b8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x771b14da


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!MiBadShareCount+4c
fffff800`02d67d7c cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!MiBadShareCount+4c

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aaa3

IMAGE_NAME:  memory_corruption

FAILURE_BUCKET_ID:  X64_0x4E_99_nt!MiBadShareCount+4c

BUCKET_ID:  X64_0x4E_99_nt!MiBadShareCount+4c

Followup: MachineOwner
---------

Possible causes are Memory problems... Drivers...

Run both memory diagnostics again, Memtest86+ and the Windows Memory Diagnostic tool. Sometimes they miss problems on one run and catch them on a subsequent run.

 

[timason]

I am running the test right now, ram by ram. If an error appears, does it just mean that it's faulty?

 

[writhziden]

If an error occurs, it means either the module or the slot is faulty and you should test the module in a known good slot (where RAM has passed multiple times before) to determine whether it is the module or slot.

 

[timason]

No errors still... I am using the Z68AP-D3 Gigabyte Mobo and 2x 4GB Corsair Ram CMZ8GX3M2A1600C9B.
If it is a driver causing it, is there no simple way to find it? I tried driver verifier, I had to restore my system to an older point. Humph, I built my computer in 2-3 days but I have been spending weeks trying to fix this crash. I did correct other errors though.

 

[writhziden]

You can run Verifier with 5-10 drivers at a time. That sometimes provides more stability and still allows determination of any driver conflicts.

 

[timason]

Ok, now I am sure it's the Ram, but for some reason it doesn't crash with one ram not 2x. I own the Corsair CMZ8GX3M2A1600C9B Vengeance Desktop Memory Kit - 8GB (2x 4GB), PC3-12800, DDR3-1600MHz, 9-9-9-24 CAS Latency, Intel XMP Ready, Unbuffered
and for mobo: GIGABYTE GA-Z68AP-D3 Intel Z68 Motherboard - ATX, Socket H2 (LGA1155), Intel Z68 Express, DDR3 2133MHz, SATA 6.0 Gb/s, RAID, 7.1-CH Audio, Gigabit LAN, SuperSpeed USB 3.0, CrossFireX Ready

Any suggestions before complaining to Corsair? This has been happening since I built my computer, all new parts...
I made sure I was running XMP and 1.5v for voltage. What I don't understand is why I didn't find errors with ram tests, and for some reason my computer doesnt BSOD with one ram. Something to do with Dual Channel?

 

[writhziden]

Up the voltage to 1.6 V and see if it behaves any better.

 

[timason]

Nope, didn't seem to help. Should I raise the dram ref voltage also? Could it be the mobo that is defective?

 

[timason]

bumpity bump sorry for editing last message..

 

[writhziden]

Yes, raise the DRAM voltage by 0.1 V

 

[timason]

Oh, sorry, yes I did do that, I was talking about the dram vref... which is at 0.750v (i think). The dram voltage is well at 1.6v now, but still crashes.

 

[writhziden]

oh, leave dram vref at its default value

Darn, sometimes that works.

Seems the two are not meshing well. Those modules were not tested by Gigabyte, so they are not guaranteed to be compatible by Gigabyte. You would have to call Corsair and ask if they should be compatible. If so, it is possible the RAM you received was defective or had an ESD attack.

You may find Avoid Static Damage to Your PC | PCWorld interesting further reading as to why RAM problems can occur. It basically says that ~400 Volts of electrostatic discharge (ESD) can ruin RAM, but you will not feel the discharge until it reaches ~1400-3500 Volts (that link says 3500-4000 Volts, but it varies based on the climate and how dry it is). When RAM receives a shock that we cannot feel, it can work for a while, and then slowly fail over time until symptoms become noticeable. That is one of the many reasons why so many users end up on these forums wondering why their systems are suddenly not working.

So for future reference, make sure you practice good electrostatic discharge (ESD) habbits and keep yourself grounded when touching PC components.

For ESD Safety, follow these steps:

1. Shut down and turn off your computer.
2. Unplug all power supplies to the computer (AC Power then battery for laptops, AC power for desktops)
3. Hold down the power button for 30 seconds to close the circuit and ensure all power drains from components.
4. Make sure you are grounded by using proper grounding techniques, i.e. work on an anti-static workbench, anti-static desk, or an anti-static pad. Hold something metallic while touching it to the anti-static surface, or use an anti-static wristband to attach to the anti-static material while working.

Once these steps have been followed, it is safe to remove and replace components within your computer.

 

[timason]

Darn. I thought I avoided ESD... I shall contact Corsair. Thanks a lot for the help.