BSOD clock

austings

Member
Joined
Sep 24, 2013
Posts
22
I keep getting a BSOD. Usually when browsing the net, or listening to music. I ran windows update several times to make sure I had everything. I also went to the motherboar manufacturer and downloaded all of the drivers it said I needed, I also went into the BIOS and resetr everything to factory defaults. I still get a BSOD.
I noticed in device manager it says I dont have a driver for the Coprocessor, but I have no idea where to find that driver
· OS - Windows 7
·x64
· What was original installed OS on system?
· full retail version
· Age of system (hardware) 3 years
· Age of OS installation - have you re-installed the OS? Yes.

· CPU
AMD Phenom 9600 Agena 2.3GHz Socket AM2+ 95W Quad-Core Processor Model
· Video Card
· MotherBoard
MSI K9N2GM-FIH AM2+/AM2 NVIDIA GeForce 8200 HDMI Micro ATX AMD Motherboard

If you need more info, let me know. I greatly appreciate any, and all
 

Attachments

Hi,

All of the attached DMP files are of the CLOCK_WATCHDOG_TIMEOUT (101) bugcheck.

This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.

We are going to need a Kernel memory dump to fully analyze a *101.

Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > change from Small to Kernel.

It will be too large to zip up and attach here, so upload it to a place like Mediafire or Skydrive and link it here.

In the meantime before that though:

Remove and replace AVG with Microsoft Security Essentials for temporary troubleshooting purposes:

AVG removal tool - AVG | Download tools and utilities

MSE - Microsoft Security Essentials - Microsoft Windows

Regards,

Patrick
 
Hi,

All of the attached DMP files are of the CLOCK_WATCHDOG_TIMEOUT (101) bugcheck.

This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.

We are going to need a Kernel memory dump to fully analyze a *101.

Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > change from Small to Kernel.

It will be too large to zip up and attach here, so upload it to a place like Mediafire or Skydrive and link it here.

In the meantime before that though:

Remove and replace AVG with Microsoft Security Essentials for temporary troubleshooting purposes:

AVG removal tool - AVG | Download tools and utilities

MSE - Microsoft Security Essentials - Microsoft Windows

Regards,

Patrick

Thank you!

I have removed AVG, MSE is installing right this second.
Heres the link to that file.
MEMORY
 
Right, so as per usual, the attached DMP file is of the CLOCK_WATCHDOG_TIMEOUT (101) bugcheck.

BugCheck 101, {30, 0, fffff88002fd3180, 3}

30 clock ticks in regards to the timeout.

fffff88002fd3180 is the PRCB address of the hung processor, let's keep this address in mind.

Running a !prcb on processor 0:

Code:
0: kd> !prcb 0
PRCB for Processor 0 at fffff80002c4be80:
Current IRQL -- 13
Threads--  Current fffffa8004483700 Next 0000000000000000 Idle fffff80002c59cc0
Processor Index 0 Number (0, 0) GroupSetMember 1
Interrupt Count -- 0015b171
Times -- Dpc    00000002 Interrupt 00000012 
         Kernel 0000d116 User      00002b51
No match for address, let's try processor 1 this time:

Code:
0: kd> !prcb 1
PRCB for Processor 1 at fffff880009e9180:
Current IRQL -- 0
Threads--  Current fffffa8001ea4580 Next 0000000000000000 Idle fffff880009f3fc0
Processor Index 1 Number (0, 1) GroupSetMember 2
Interrupt Count -- 001452fd
Times -- Dpc    0000000e Interrupt 0000001e 
         Kernel 0000d431 User      000027d6
Nope, no match either. I'll spare you the space in the post and tell you that processor #3 is the one we're looking for :+)
Code:
0: kd> !prcb 3
PRCB for Processor 3 at [COLOR=#ff0000][U][I][B]fffff88002fd3180[/B][/I][/U][/COLOR]:
Current IRQL -- 0
Threads--  Current fffffa8003c17270 Next fffffa8002ba1060 Idle fffff88002fddfc0
Processor Index 3 Number (0, 3) GroupSetMember 8
Interrupt Count -- 001be656
Times -- Dpc    000002ac Interrupt 0000019f 
         Kernel 0000cd65 User      00002bfc
For reference, I did not do !prcb 0 through 3. That would have been very tedious. Instead, you can run the !running -it command. The "i" argument causes it to display idle procs too, and "t" displays the stack trace for the thread running on each proc.

Hint: At times, the 4th parameter of the bugcheck will show you the responsible processor. For example, in your *101 here, it was correct as the 4th parameter was 3.

As this matches the 3rd parameter of the bugcheck, processor #3 is the responsible processor. Now with the information we have here thus far, we know that processor #3 reached 30 clock ticks without responding, therefore the system crashed. Before we go further, what is a clock tick? A clock interrupt is a form of interrupt which involves counting the the cycles of the processor core, which is running a clock on the processors to keep them all in sync. A clock interrupt is handed out to all processors and then they must report in, and when one doesn't report in, you then crash.

If we look at the call stack for processor #3, we can see it did absolutely nothing:
Code:
  3    fffff88002fd3180  fffffa8003c17270  fffffa8002ba1060  ................

Child-SP          RetAddr           Call Site
00000000`00000000 00000000`00000000 0x0

If we look at the call stacks for the other processors, we can see various NTFS routines being called:

Code:
  2    fffff88002f63180  fffffa8001820040                    ................

Child-SP          RetAddr           Call Site
fffff880`03179240 fffff800`02b1496c nt!KeFlushMultipleRangeTb+0x266
fffff880`03179310 fffff880`0122369c nt!MmSetAddressRangeModified+0x2b0
fffff880`03179410 fffff880`012cedfb Ntfs!LfsFlushLfcb+0x5d8
fffff880`03179590 fffff880`012d0f10 Ntfs!LfsFlushToLsnPriv+0x143
fffff880`03179620 fffff880`0128be6a Ntfs!LfsFlushToLsn+0xa0
fffff880`03179650 fffff880`0128c63c Ntfs!NtfsCommonFlushBuffers+0x366
fffff880`03179730 fffff880`01055bcf Ntfs!NtfsFsdFlushBuffers+0x104
fffff880`031797a0 fffff880`010546df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880`03179830 fffff800`02ddba9b fltmgr!FltpDispatch+0xcf
fffff880`03179890 fffff800`02d70781 nt!IopSynchronousServiceTail+0xfb
fffff880`03179900 fffff800`02acfe13 nt!NtFlushBuffersFile+0x171
fffff880`03179990 fffff800`02acc3d0 nt!KiSystemServiceCopyEnd+0x13
fffff880`03179b28 fffff800`02d71537 nt!KiServiceLinkage
fffff880`03179b30 fffff800`02d713a4 nt!CmpFileFlush+0x3f
fffff880`03179b70 fffff800`02d71582 nt!HvWriteDirtyDataToHive+0x18c
fffff880`03179be0 fffff800`02d62473 nt!HvOptimizedSyncHive+0x32
fffff880`03179c10 fffff800`02d625d5 nt!CmpDoFlushNextHive+0x197
fffff880`03179c70 fffff800`02ada261 nt!CmpLazyFlushWorker+0xa5
fffff880`03179cb0 fffff800`02d6ebae nt!ExpWorkerThread+0x111
fffff880`03179d40 fffff800`02ac18c6 nt!PspSystemThreadStartup+0x5a
fffff880`03179d80 00000000`00000000 nt!KiStartSystemThread+0x16

Code:
  1    fffff880009e9180  fffffa8001ea4580                    ................

Child-SP          RetAddr           Call Site
fffff880`083c4aa0 fffff800`02af0251 nt!KeFlushMultipleRangeTb+0x266
fffff880`083c4b70 fffff800`02af2c98 nt!MiFlushTbAsNeeded+0x1d1
fffff880`083c4c80 fffff800`02c01f86 nt!MiAllocatePagedPoolPages+0x4cc
fffff880`083c4da0 fffff800`02af09b0 nt!MiAllocatePoolPages+0x906
fffff880`083c4ee0 fffff800`02c0543e nt!ExpAllocateBigPool+0xb0
fffff880`083c4fd0 fffff880`0133c67e nt!ExAllocatePoolWithTag+0x82e
fffff880`083c50c0 fffff880`0130ab8d Ntfs!NtfsPrefetchFile+0x5ce
fffff880`083c51f0 fffff880`012c333d Ntfs! ?? ::NNGAKEGL::`string'+0x1cdcb
fffff880`083c5230 fffff880`01055bcf Ntfs!NtfsFsdFileSystemControl+0x13d
fffff880`083c52d0 fffff880`0107595e fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880`083c5360 fffff800`02deecc7 fltmgr!FltpFsControl+0xee
fffff880`083c53c0 fffff800`02dab262 nt!IopXxxControlFile+0x607
fffff880`083c54f0 fffff800`02f2f101 nt!NtFsControlFile+0x56
fffff880`083c5560 fffff800`02f2f5aa nt!PfpPrefetchEntireDirectory+0x121
fffff880`083c5610 fffff800`02f305bb nt!PfSnPrefetchMetadata+0x1ca
fffff880`083c5710 fffff800`02f30a0f nt!PfSnPrefetchScenario+0x15b
fffff880`083c5980 fffff800`02e3070f nt!PfSnBeginAppLaunch+0x35f
fffff880`083c5a50 fffff800`02dc001c nt! ?? ::NNGAKEGL::`string'+0x4c0c0
fffff880`083c5a80 fffff800`02ac19f5 nt!PspUserThreadStartup+0x148
fffff880`083c5ae0 fffff800`02ac1977 nt!KiStartUserThread+0x16
fffff880`083c5c20 00000000`770ec520 nt!KiStartUserThreadReturn
00000000`0021feb8 00000000`00000000 0x770ec520

Possible hard disk issues, so let's run diagnostics:

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.

If the hard disk diagnostics come back clean, let's enable Driver Verifier just to make sure we are not dealing with possible device driver corruption and or conflicts:


Driver Verifier:

What is Driver Verifier?

Driver Verifier is included in Windows 8, 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 if it detects a violation.

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"
Windows 8 - Restore Point - Create in Windows 8

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 & 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 24 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 %systemroot%\Minidump

Any other questions can most likely be answered by this article:
Using Driver Verifier to identify issues with Windows drivers for advanced users

Regards,

Patrick
 
Right, so as per usual, the attached DMP file is of the CLOCK_WATCHDOG_TIMEOUT (101) bugcheck.

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.

If the hard disk diagnostics come back clean, let's enable Driver Verifier just to make sure we are not dealing with possible device driver corruption and or conflicts:


Driver Verifier:

What is Driver Verifier?

Driver Verifier is included in Windows 8, 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 if it detects a violation.

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"
Windows 8 - Restore Point - Create in Windows 8

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 & 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 24 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 %systemroot%\Minidump

Any other questions can most likely be answered by this article:
Using Driver Verifier to identify issues with Windows drivers for advanced users

Regards,

Patrick

Ok, I ran chkdsk, and seatools, both came up clean. I enabled Driver Verifier, and an hour later, it BSOD'd. Ill attach the crash dump
 

Attachments

It's another *101 failing to flag a device driver regardless of being verifier enabled. Have you tried a clean install of Windows at any point with nothing 3rd party installed aside from the latest drivers for all of your hardware?

Regards,

Patrick
 
It's another *101 failing to flag a device driver regardless of being verifier enabled. Have you tried a clean install of Windows at any point with nothing 3rd party installed aside from the latest drivers for all of your hardware?

Regards,

Patrick

Yes, 2 times now.
 
At this point I am going to believe it's a CPU issue then. CPU's are generally the fault of most *101 bugchecks, however there are of course possibilities and we always want to be as sure as we can be. Have you attempted a Memtest yet just to check the health of your RAM?

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

Regards,

Patrick
 
Hi,

My apologies, I forgot to mention to let it run for NO less than ~8 passes (several hours).

Regards,

Patrick
 
I also re-enabled Driver verifier, and deleted the other crash dump files just in case I messed up on the settings, or uploaded the wrong one. Here is the most current one.

Also, when in the BIOS, I noticed that my CPU is running at 120 degrees, not sure if that is normal( I think it is). I opened the case and blew off as much dust as possible.

I also noticed, that in memtest, it said my ram timings were 5-5-5-18, Under the details section of where I bought the ram, it says the timings are 4-4-4-12. Again, not sure if this is normal. I'm thinking the system changed the timings for whatever reason.

This might all sound un-needed to you, but I am just trying to give you as much information as possible.
 

Attachments

Hi,

Also, when in the BIOS, I noticed that my CPU is running at 120 degrees, not sure if that is normal( I think it is).

Maybe be an incorrect sensor because I think it'd throttle and then shut-down to avoid further damage at that temperature. It's not normal at all, no, not on Earth at least.

Download and install Speccy and post a screenshot of your temps on IDLE (not playing games, etc... just sitting at Desktop) - Speccy - System Information - Free Download

The attached DMP is of the *101 bugcheck as usual but isn't a Kernel so there's unfortunately not much we can do. I'm interested in this temperature thing now, so let me know.

In regards to Memtest reporting those timings, I think it's a bug. I've seen it mentioned before in previous BSOD cases. What's the RAM set to in the BIOS, Auto? If so, check the DRAM frequency if possible and see if it's 5-5-5-18.

Regards,

Patrick
 
Just went into the BIOS,its set at Auto and, it said "Current DRAM frequency is 800mhz", Didnt say anything about 5-5-5-18.
 
So then, if the drivers are good, hard drive, and ram i all check out good, all thats left is the CPU then? I find it hard to believe that it is BSOD'ing because of over heating. Id assume if heat were a problem, it would BSOD more often, not just randomly.

Would Prime95 be a good way of testing the CPU?
 
Would Prime95 be a good way of testing the CPU?

Precisely.

I would recommend running Blend for a few hours. Monitor the temps as it's being stressed, if you can.

Regards,

Patrick
 

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

Back
Top