[SOLVED] BSOD Errors Internal Power Error and Clock Watchdog Timeout

[gevans166]

I have been having problems with my pc since I built it. The main problem is that the computer will restart or freeze. Sometimes it is after a minute or two on the other hand I have gotten it to run for over an hour before. Likewise sometimes there is a blue screen error message other times not. I have gotten a couple of blue screen error messages the two I remember are internal power error and clock watchdog timeout.

I have tried several things in order to resolve this issue. The first thing I tried was updating the BIOS followed by setting the XMP profile and then a hard reset thinking that it was an issue with my memory. Afterwards I tried manually setting the ram speed, voltage, and memory timing going through several different combinations as well as making sure my ram was in the correct slots. It may just be the random nature of the problem but it seems to me that adjusting those settings generally increased the time it took the computer to freeze or restart.

None of that solved the problem so I tried other things. Such as updating the BIOS again, updating drivers (using a 3rd party driver installer), running various troubleshooters, running both mdsched and memtest86. I tried running sfc/scannow as well as chkdsk /f c: in addition I ran ccleaner to fix the registry and nothing worked.

Then I had a look in the event viewer which didn’t make a lot of sense so after that I had a look in the mini dump folder. There I found a reoccurring errors for both internal power error and clock watchdog timeout caused by ntoskrnl.exe. I decided to run the computer in safe mode to see if that did anything. I ran the computer overnight and it went into hibernation as it should. Next I ran it for four hours and it went to sleep but did not freeze or restart. So it seems my problem does not occur in safe mode. With that good omen I ran the computer in clean boot and it has both froze and restarted.

I am not quite sure what to do now or what exactly is causing the problem. So I have linked both the event viewer logs and mini dump logs in the hopes that you guys can give me some advice.

https://drive.google.com/open?id=1MQdFbzam_GhWKFCgt0LVFjNS9WWBwXuK
https://drive.google.com/open?id=1yNZcbcHgNRIpuEHuzcwrz-rQJvFi6zLe

 

[kaehligj]

The most simple and most overlooked problem is ram hardware compatibility.
You have to check your mobo QVL on ram first off, before you run yourself into deep mud.

If your ram is not listed in the QVL, you are out in the thin blue air, completely on your own.
No excuses are valid.

Look up the exact motherboard type number support/download page.
Do not use a similar number, it must be exact
Find the ram/memory QVL pdf file and download it.

If your fitted ram modules type number - exactly - as printed on the ram module, can not be found in the QVL, you have found your problem.
I repeat : no excuses are valid.

The QVL is intended as a customer service to avoid hardware problems.
Not a joke.

It has nothing to do with the quality or brand of the ram modules.
Its based on internal technical differences on the various brands and types of ram modules.

 

[PC Tailor]

The dump files link is blocked from shared access, could you open this up so I can grab the dump files?

Whilst I generally agree with above, the QVL is ultimately a guide only, so RAM not being on the QVL does not mean exactly that the RAM isn't supported, usually just that the RAM hasn't been tested with that board. This is especially relevant on older boards. So if it's not on the QVL, I do not agree that it means that is your problem, more than it could be a problem.

Having said that the internal power error can come from various sources, and I'd need to see the dump file for more detail.
And a Clock Watchdog is usually a hardware error ( it can be software, but not often ) - as it is ultimately a CPU hang, so from a HW point of view, the CPU is the first thing I'd usually look at, but again I'd need the dump files.

Ideally for Clock Watchdogs it's best to have kernel dump files too, not just minidumps.

 

[gevans166]

kaehligj that was my first guess when all this started. So I posted in the memory forum about determining if the ram I used was the problem. Here is a link to that thread https://forums.tomshardware.com/threads/troubleshooting-if-ram-is-my-problem.3503128/ basically the mod Darkbreeze said it was very doubtful that ram compatibility was my problem. While I don't disagree with you I am inclined to head the advice of someone with significantly more experience with computer than myself.

PC Tailor I have set the link for the mini dump folder to shareable. You should be able to view it now. Also I know how to alter what dump files are created but how do you have multiple types at the same time?

 

[Darkbreeze]

The most simple and most overlooked problem is ram hardware compatibility.
You have to check your mobo QVL on ram first off, before you run yourself into deep mud.

If your ram is not listed in the QVL, you are out in the thin blue air, completely on your own.
No excuses are valid.

Look up the exact motherboard type number support/download page.
Do not use a similar number, it must be exact
Find the ram/memory QVL pdf file and download it.

If your fitted ram modules type number - exactly - as printed on the ram module, can not be found in the QVL, you have found your problem.
I repeat : no excuses are valid.

The QVL is intended as a customer service to avoid hardware problems.
Not a joke.

It has nothing to do with the quality or brand of the ram modules.
Its based on internal technical differences on the various brands and types of ram modules.

This is so far from the truth I don't even know where to begin, actually. Nothing stated in this response is accurate at all, and it should be completely ignored.


QVL lists are irrelevant. They don't tell you anything remotely like "only these will work on this board" AND, more importantly, not every kit listed on the QVL list will run at it's XMP speed. Most QVL listed kits are only tested at the default speed unless the QVL SPECIFICALLY SAYS that it was tested at the XMP speed. Just because it LISTS the XMP speed, doesn't mean that is the speed that the kit was tested at AND these days, the BIOS update improvements for Ryzen have resulted in just about any memory kit being able to work on most mid to upper tiered boards so long as the speed is compatible. For Ryzen, you want to stay at 3600mhz or lower kits.

The memory manufacturers only have one thing to worry about, and that's whether THEIR memory works on a limited number of boards, rather than the motherboard manufacturers who would have an exhausting time of trying to make sure EVER memory kit out there worked on ALL of their motherboards. Not going to happen. Even testing all kits AT the XMP profile speed for just their flagship boards is unlikely.

The memory compatibility lists offered by G.Skill, Corsair, Crucial, Kingston, etc. are likely to be a much better tool than anything on the motherboard manufacturers product pages.

 

[Colif]

Also I know how to alter what dump files are created but how do you have multiple types at the same time?

you can't, it is sort of annoying that the size counts as a format, until I just looked I had assumed they could be both mini and kernel at same time.

how big is your MEMORY.DMP right now?
You might need to swap it to kernel for one BSOD and then swap back to minidump. It really depends what the current ones show, I can't read them myself. I rely on people like PC to convert them first.

 

[PC Tailor]

I've used a bulk analyser (doesn't generate postable report) so will have to transpose findings manually really. But I have reported ONE of the 101 dump files here: https://pste.eu/p/KeG4.html

As I've stated previously, the 101 bugcheck is a CPU hang. And the CPU usually only hangs for a couple of reasons, the main being faulty hardware (usually faulty CPU), but can sometimes come from drivers causing the CPU to then hang. Now after digging into each one (P4 of each 101 dump file):

Arg4: 0000000000000001, The index of the hung processor.
Arg4: 0000000000000004, The index of the hung processor.
Arg4: 0000000000000009, The index of the hung processor.
Arg4: 0000000000000005, The index of the hung processor.
Arg4: 0000000000000000, The index of the hung processor.
Arg4: 0000000000000000, The index of the hung processor.
Arg4: 0000000000000000, The index of the hung processor.
Arg4: 0000000000000006, The index of the hung processor.
Arg4: 0000000000000007, The index of the hung processor.
Arg4: 0000000000000004, The index of the hung processor.

It's various processors that are hanging, so this is showing that in the first dump, it was processor 1 that hung. 2nd dump is processor 4 etc.
Each one also took 10 clock ticks in each one to time out (Arg1: 0000000000000010 on all dumps)

However when trying to run some additional commands, due to them being minidumps, I cannot extract all the relevant information:

11: kd> !irql 0
Cannot get PRCB address from processor 0x0
11: kd> ~0
Can't switch processors on a single processor kernel triage dum

So realistically, I'm clutching at straws for the most part. However what I would go through first as considerations:

I believe there is a BIOS update available for your board.
Is your RAM from the same physical pack?

Remove:

NTIOLib_X64.sys

10/07/2017

MSI

MSI Afterburner (Known BSOD)

I would consider removing or at the very least finding updates for:

I2cHkBurn.sys

18/02/2014

Fintek

FINTEK FitGpBus Driver

You likely also need to update:

amdpsp.sys

27/10/2017

AMD

AMD Chipset Driver

rt640x64.sys

28/08/2018

Realtek

Realtek Ethernet Driver

RTKVHD64.sys

27/11/2018

Realtek

Realtek HD Audio Driver

Finally you may want to remove Kaspersky and run on Windows Defender until you resolve the issue as AV can cause all manner of issues.

Ultimately, being as it is a CPU hang (in most cases) I would also be tempted to:

• Monitor CPU temps under load
• Run Prime95 to test - if this finds failures, we've likely found the problem.
• Run Driver Verifier as per this guide: https://forums.tomshardware.com/thr...nclude-in-blue-screen-of-death-posts.3468965/ as if it IS a driver, this might help.

- Please post your entire system spec including PSU make and model.

 

[Colif]

nt! ?? ::FNODOBFM::`string'+ - https://bsodtutorials.wordpress.com/2014/12/27/resolving-nt-fnodobfmstring0x32c3b-in-call-stacks/

 

[gevans166]

Here is my parts build . https://pcpartpicker.com/list/j2fPr6 Both of my sticks of same are from the same pack.

I was having problems uninstalling Kaspersky as well as updating Windows 10. The latter I needed to do in order to update AMD chipset driver. It was annoying me so I decided to reset Windows 10 last night. I didn't have any important files on the computer so I kept nothing. After reinstalling Windows 10 I have updated Windows Defender but done nothing else. This includes not updating the BIOS or installing the drivers.

Just to see what would happen I left the computer on over night about seven hours in normal mode. It seems to be working fine as it was just as I left it when I checked it this morning. I am new to building and troubleshooting computers but that seems to be to indicate that it isn't a cpu problem but a software issue, corruption, or malware of some kind. Now the only weirdness I have seen so far is that I can neither update Windows 10 through the built in automatic updater nor activate Windows 10.

So any ideas on what could be my problem and how I can prevent it with this new piece of information?

My current plan is to try and stress test my system first without doing anything else besides install a temp monitor. Whether that works or not as long as it doesn't give an error I will install the driver disk. This will include updating without the use of third party software and uninstall what has previously been recommended to be uninstalled. If all goes well next would be to update the BIOS and then set memory timings seeing where that gets me.

 

[Darkbreeze]

Update the BIOS, first. Everything else is chasing ghosts until you know this is not an errata issue that was resolved through a BIOS or microcode update, or simply a code fault that was corrected in a subsequent BIOS update.