Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Windows › Crash Analysis and Debugging › Recurring BSOD caused by ntoskrnl.exe - Driver verifier enabled - .dmp file within
New Posts  All Forums:Forum Nav:

Recurring BSOD caused by ntoskrnl.exe - Driver verifier enabled - .dmp file within

post #1 of 13
Thread Starter 
I'm going to post this thread and then edit it because my PC keeps BSOD'ing and I don't want to lose this thread. More to come.

Here is the .dmp file.

Basically I have a home built box that I built in March of 2009. It's been flawless. Just a few days ago it started to reboot at random times.

I read on this forum in another thread about enabling Driver Verifier so I did that. I'm using BlueScreenViewer to look at the data from the .dmp file but either I am not looking at enough of the info or I can't find it. I only see ntoskrnl.exe. I thought that there would be extra info after I enabled verifier but it doesn't seem like there is.

I ran Memtest for about an hour and it came up with no errors.

I had originally noticed that the CMOS battery was dead so I just replaced it today. I noticed that I'd lose all my BIOS settings and the clock multiplier would be wrong etc. So I went in tonight after replacing the battery and reconfigured all the settings.

Not sure if it is a power supply issue, a driver, the memory, a hard drive or what. I'm used to seeing a .dll listed or something in the BSOD and then I can tell what the culprit is. I'm not used to just getting ntoskrnl.exe with nothing else.

I'll get my specs together here shortly. I'm running G'Skill memory, Gigabyte MB, and an Intel Proc E7400 @ 2.8GHz . Nothing overclocked.

I can provide more .dmp files if needed.

I really truly appreciate the help in advance. Thanks much!
Edited by ServerMechanic - 8/1/13 at 10:26am
post #2 of 13

Attaching any other DMP files you may help will be great to look for any consistency or other issues we need to look out for.

In the meantime, the attached DMP file is of the CRITICAL_STRUCTURE_CORRUPTION (109) bugcheck. This bugcheck occurs when the kernel detects that critical kernel code of data has been corrupted. Generally there are two main causes:

a) hardware


b) device drivers.

I cannot seem to get any info regarding if verifier was enabled for the attached dump in the OP:
0: kd> !verifier
fffff800030a1ac0: Unable to get verifier list.

Are you sure this was the dump you enabled verifier for?
System Uptime: 0 days 0:43:54.994

System uptime isn't very long. If we had other dumps with similar consistency this would scream hardware, most likely.

Driver(s) from software that need to be updated or removed for temporary troubleshooting purposes if no updates are available:
aksifdh fffff880`04216000 fffff880`04229000 Sun Jul 20 02:40:52 2008 (4882ddf4) 0001b1ef aksifdh.sys

^^ Alladin eToken security - http://www.aladdin.co.il/support/default.aspx

That's about all I can see from this current dump.


post #3 of 13
Thread Starter 
Here are two more .dmp files.


Yeah the PC will only stay up for an hour give or take. I've cleaned it out, blown it out with compressed air etc. All the fans are working and I don't get a temp warning so I think it is not overheating. Sometimes it's on for 30 mins and sometimes it's on for 55 mins but it seems to reboot every 30 - 70 minutes. Sometimes I'm not even doing anything at all, and I'm not at the PC.

The odd thing too is that I'm typing this in Firefox because for the last 2 days Google Chrome just crashes and crashes and crashes. I can't use it anymore.

When this started I did a system restore to a week before and that didn't help either. I wonder if it would be worth while to throw another hard drive in and load Windows 7 from scratch to see if it still reboots. That would rule out hardware if it stays on you think?

Tons of thanks man. Seriously; from one geek to another.
Edited by ServerMechanic - 7/31/13 at 8:11pm
post #4 of 13
Thanks for providing additional dumps!

Both attached DMP files are still of the same bugcheck, and I still cannot seem to get a verifier list. It's likely due to the system crashing well before verifier can truly do its job. For example, take a look at the uptimes on the dumps~

1: System Uptime: 0 days 0:14:00.012

2: System Uptime: 0 days 0:29:06.413

Not long at all!!!

Definitely thinking hardware here at this point given we have constant low system uptime, no verifier lists, and ntoskrnl.exe probably caused by culprits.

First thing I am going to recommend doing is a Memtest. I know you said you've run it already, but I recommend running it for no less than ~8 passes (SEVERAL hours) for it to do its job:

Download Memtest86+ here:


Which should I download?

You can either download the pre-compiled ISO that you would burn to a CD and then boot from the CD, or you can download the auto-installer for the USB key. What this will do is format your USB drive, make it a bootable device, and then install the necessary files. Both do the same job, it's just up to you which you choose, or which you have available (whether it's CD or USB).

How Memtest works:

Memtest86 writes a series of test patterns to most memory addresses, reads back the data written, and compares it for errors.

The default pass does 9 different tests, varying in access patterns and test data. A tenth test, bit fade, is selectable from the menu. It writes all memory with zeroes, then sleeps for 90 minutes before checking to see if bits have changed (perhaps because of refresh problems). This is repeated with all ones for a total time of 3 hours per pass.

Many chipsets can report RAM speeds and timings via SPD (Serial Presence Detect) or EPP (Enhanced Performance Profiles), and some even support changing the expected memory speed. If the expected memory speed is overclocked, Memtest86 can test that memory performance is error-free with these faster settings.

Some hardware is able to report the "PAT status" (PAT: enabled or PAT: disabled). This is a reference to Intel Performance acceleration technology; there may be BIOS settings which affect this aspect of memory timing.

This information, if available to the program, can be displayed via a menu option.

Any other questions, they can most likely be answered by reading this great guide here:



post #5 of 13
Thread Starter 

Thanks man. I'm going to fire up memtest again since I already have the latest stable version on CD. I'll let it run overnight. Here's a screenshot of my Driver Verifier settings. I know you can't see everything in the right hand pane but I figure you get the idea.

No need to thank me for the additional dumps. I appreciate you helping me out with them. This is a great forum. I've lurked for a while. smile.gif

Oh yeah, I also just removed the eToken stuff. That used to be installed for VPN to work but now we just use Remote Desktop Gateway so no need.
post #6 of 13
My pleasure : )

Your verifier settings look okay, here's my canned DV speech just in case you want to review anything real quick:

Driver Verifier:
What is Driver Verifier?
Driver Verifier is included in Windows 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.
Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver by flagging it and causing your system to BSOD.
Before enabling Driver Verifier, it is recommended to create a System Restore Point:
Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
How to enable Driver Verifier:
Start > type "verifier" without the quotes > Select the following options -
1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7)
- Concurrentcy Stress Test (Windows 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.
Important information regarding Driver Verifier:
- If Driver Verifier finds a violation, the system will BSOD.
- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will flag it, and as stated above, that will cause / force a BSOD.
If this happens, do not panic, do the following:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > type "system restore" without the quotes.
- Choose the restore point you created earlier.
If you did not set up a restore point, do not worry, you can still disable Driver Verifier to get back into normal Windows:
- Start > Search > type "cmd" without the quotes.
- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
- Restart and boot into normal Windows.
How long should I keep Driver Verifier enabled for?
It varies, many experts and analysts have different recommendations. Personally, I recommend keeping it enabled for at least 36-48 hours. If you don't BSOD by then, disable Driver Verifier.
My system BSOD'd, where can I find the crash dumps?
They will be located in C:\Windows\Minidump
Any other questions can most likely be answered by this article:

Let me know how Memtest turns out after at least ~8 passes.


post #7 of 13
Thread Starter 
So I left Memtest run overnight and it ran for over 7 hours. Pic below.

I'm going to let it run a while longer and then see what happens. If I boot it back up to Windows and it starts rebooting again but it didn't do it while booted off the memtest CD would you think that it would rule out hardware?

post #8 of 13
Thread Starter 
Here are 3 more dmp files from today after I fired it back up into Windows.


Here is what I was able to gather from Windbg myself after reading your tutorial. Thanks Patrick!

Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [X:\Google Drive\dmp files\080113-14040-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.18113.amd64fre.win7sp1_gdr.130318-1533
Machine Name:
Kernel base = 0xfffff800`02e5f000 PsLoadedModuleList = 0xfffff800`030a2670
Debug session time: Thu Aug 1 09:25:04.434 2013 (UTC - 4:00)
System Uptime: 0 days 0:14:00.011
Loading Kernel Symbols
Loading User Symbols
Loading unloaded module list
* *
* Bugcheck Analysis *
* *

Use !analyze -v to get detailed debugging information.

BugCheck 109, {a3a039d896ed6934, b3b7465ee96ba5e6, fffff80000b96bb0, 6}

*** WARNING: Unable to verify timestamp for ntoskrnl.exe
*** ERROR: Module load completed but symbols could not be loaded for ntoskrnl.exe
Probably caused by : ntoskrnl.exe ( nt_fffff80000b95000+1bb0 )

Followup: MachineOwner

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

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.
Arg1: a3a039d896ed6934, Reserved
Arg2: b3b7465ee96ba5e6, Reserved
Arg3: fffff80000b96bb0, Failure type dependent information
Arg4: 0000000000000006, 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:

fffff800`00b96bb0 ?? ???






fffff880`02fef598 00000000`00000000 : 00000000`00000109 a3a039d8`96ed6934 b3b7465e`e96ba5e6 fffff800`00b96bb0 : nt!KeBugCheckEx


fffff800`00b96bb0 ?? ???

SYMBOL_NAME: nt_fffff80000b95000+1bb0


MODULE_NAME: nt_fffff80000b95000

IMAGE_NAME: ntoskrnl.exe


FAILURE_BUCKET_ID: X64_0x109_6_nt_fffff80000b95000+1bb0

BUCKET_ID: X64_0x109_6_nt_fffff80000b95000+1bb0

Followup: MachineOwner

Wondering if I should just throw an extra hard drive in and load windows 7 from scratch and see if I still have this problem? Hmm...
post #9 of 13

Well, this is good as we know it's not your memory!

We could be dealing with some pretty bitter OS corruption here if not memory related. We can go through various corruption diagnostics, but since you have seemed eager to try a fresh Windows on a different drive, that would help out a lot as it would rule out many variables!


post #10 of 13
Thread Starter 
Cool deal. I'm going to do a fresh install on a different HD tonight and see what happens.

I'll report back.

Thanks much!

New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Crash Analysis and Debugging
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Windows › Crash Analysis and Debugging › Recurring BSOD caused by ntoskrnl.exe - Driver verifier enabled - .dmp file within