Windows 8 x101 BSOD

bc8907

Member
Joined
Sep 1, 2013
Posts
23
Hi everyone,

Not very knowledgeable in crash debugging. Got an 8 machine that is BSODing only during online gaming. Unit is running an A6 APU, so the first thing I tried was updating the chipset/display drivers. Have tried the newest stable, beta, and rolling back with no luck. Driver Verifier has also raised no flags. Currently running Furmark and Prime95 to test the actual hardware itself. I can get the Kernel dump or any other info upon request. Jcgrifff's BSOD info is attached and System info is as follows:

· Windows 8
· x64 ?
· Windows 7 Original OS
· Full Retail OS
· Entire System - Almost exactly 2 years except for SSD and MOBO which were both installed earlier this year
· OS has been reinstalled within the past month

· AMD A6-3650
· ASROCK A75M
· Zalman 500W

· Home Build


 

Attachments

Last edited:
Hi,

Yes, as it's a *101 bugcheck we will need a kernel or higher to analyze. Also, run the collection app and attach the zip here. We can't do much with .txt formats of it.

Regards,

Patrick
 
Thank you for your timely response. I believe the unit was set to produce a full dump as the file is ~8Gb. As such I can't compress it enough to upload. I have attached the zip in the mean time and will upload a smaller kernel dump as soon as the unit crashes again.
 

Attachments

Full Memory Dump isn't necessary, a kernel will do just fine and you can upload that to Skydrive or any 3rd party hosting site of your choice.

In the mean-time, thanks for providing the small dumps, and they are indeed all of *101. Fortunately in our case they are telling us a little more than the usual 'nothing' when they aren't kernel memory dumps :')

CLOCK_WATCHDOG_TIMEOUT (101)

An expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval. This can occurs when the processor is not responding or is deadlocked.

In all of the *101's, we are seeing:

Code:
Unable to load image \SystemRoot\system32\DRIVERS\atikmdag.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for atikmdag.sys
*** ERROR: Module load completed but symbols could not be loaded for atikmdag.sys
Probably caused by : atikmdag.sys ( atikmdag+827c7 )

Ensure you have the latest video card drivers. If you are already on the latest video card drivers, uninstall and install a version or a few versions behind the latest to ensure it's not a latest driver only issue. If you have already experimented with the latest video card driver and many previous versions, please give the beta driver for your card a try.

Regards,

Patrick
 
So, just double-checked and that specific driver was dated from March of this year. I extracted a newer version from AMD's latest CCC to try that out, since it's installer wasn't overwriting. Will try it out for a bit and let you know.
 
So, just double-checked and that specific driver was dated from March of this year. I extracted a newer version from AMD's latest CCC to try that out, since it's installer wasn't overwriting. Will try it out for a bit and let you know.

Let me know how it works! I'll check the kernel in a bit (or the newest one you attach after new driver testing).

Regards,

Patrick
 
No crash so far. Looks good. Thank you. If you don't mind me, could you point me to where you were finding that driver in the dumps? I was unable to locate them.
 
No crash so far. Looks good. Thank you. If you don't mind me, could you point me to where you were finding that driver in the dumps? I was unable to locate them.

Great, please keep me updated.

In regards to atikmdag.sys within the dump, it appears before running !analyze -v and many other places (took screenshots to make it easier to see):

example 1.png

After you run the !analyze -v, after the stack you can see it's also the followup ip, the symbol / module / image name, as well as the failure bucket ID:

example 2.png

You can also see from that screenshot that the follow up ip atikmdag corresponds to the atikmdag within the failure bucket id.

Note that this was surprsingly (so far, knock on wood) a very simple *101 dump. In most cases you need a Kernel as mentioned earlier and need to dig through the processors for any relevant information.
 
Couple other notes: Technically it didn't BS it just crashed and no dump was generated. Also, when I pull up those dumps in WinDbg I don't see that. This is my view:

windbg.jpg
 
It's actually not generating a kernel now as it just locks up and has to be physically restarted. I will try to force it to crash again and hopefully I can get you a report.
 
Got it, thanks.

If it keeps locking up and there's no sign of getting a dump, let's run a few hardware diagnostics. Start with a Memtest for NO LESS than ~8 passes (several hours):

Memtest:

Memtest86+:

Download Memtest86+ here:

Memtest86+ - Advanced Memory Diagnostic Tool

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:

FAQ : please read before posting

-------------------------------------------------------------------------------------------------------------

Chkdsk:

Chkdsk:
There are various ways to run Chkdsk~


Method 1:

Start > Search bar > Type cmd (right click run as admin to execute Elevated CMD)

Elevated CMD should now be opened, type the following:

chkdsk x: /r

x implies your drive letter, so if your hard drive in question is letter c, it would be:

chkdsk c: /r

Restart system and let chkdsk run.

Method 2:


Open the "Computer" window
Right-click on the drive in question
Select the "Tools" tab
In the Error-checking area, click <Check Now>.

If you'd like to get a log file that contains the chkdsk results, do the following:

Press Windows Key + R and type powershell.exe in the run box

Paste the following command and press enter afterwards:

get-winevent -FilterHashTable @{logname="Application"; id="1001"}| ?{$_.providername –match "wininit"} | fl timecreated, message | out-file Desktop\CHKDSKResults.txt

This will output a .txt file on your Desktop containing the results of the chkdsk.

If chkdsk turns out okay, run Seatools -

SeaTools | Seagate

You can run it via Windows or DOS. Do note that the only difference is simply the environment you're running it in. In Windows, if you are having what you believe to be device driver related issues that may cause conflicts or false positive, it may be a wise decision to choose the most minimal testing environment (DOS).

Run all tests EXCEPT: Fix All, Long Generic, and anything Advanced.

Regards,

Patrick
 
12 hrs, 10 MemTest passes, and one ChkDsk later here we are. Everything looks good so far. My disk is a Samsung SSD and Magician has the health of the drive as good in lieu of SeaTools. ChkDsk log attached. Any ideas on what might be causing the crashes?
 

Attachments

Hi,

Is the firmware of the SSD up to date? I'll check the kernel in a bit.

Regards,

Patrick
 
Anyone else got any ideas? All the hardware seems to be okay, and I can't pinpoint a driver causing this issue.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top