Multiple CPU (Intel) related BSOD's

D

Demetrius

Member
Joined
May 8, 2023
Posts
13
Good day/evening everyone.
My current computer hardware is brand new, just 7 months old (Expect my psu), and i'm getting blue screens of death, for like 1-2 months now,out of nowhere.
Tried almost everything. Memtest, Windows Memory Diagnostics, Driver Verifier, and few stress tools. OCCT & Intel Processor Diagnostic Tool. Everything of the above, shows no errors at all. Same goes for OCCT/Intel's diagnostics. Everything passed.
I have reinstalled Windows 3-4 times in between 2 months, again bsod's. Testing with various tools/stress tests, everything comes clean/passed again.
Updated everything related to my Intel's cpu. Via official Gigabyte's and/or Intel's websites.
Still getting blue screens at this day. It happens randomly. Be it while playing any game(s), using Handbrake to convert video files, and/or while copying/pasting large data files from one disk to another.
So,my question is: Any possibility that my CPU is defected, since almost every dump files i checked, refers to 124 WHEA? And the most strange part is, not getting any bsod's while doing any kind of stress tests & windows driver verification. At the moment i can't figure out what is the cause of the problem for that many crashes in 2 months and with fresh OS installations. Can be due to some kind of conflict between my motherboard (z590) and my non K (11900f) cpu? Not using overclocking at all both at cpu/gpu, expect Intel's turbo mode, and XMP for my memory modules. Perhaps my old psu need a replacement? Maybe to check with Windows Driver Verifier with another settings, since some forums suggests different settings? Please if anyone can assist me with my problem, (sadly,i don't have 2nd cpu to test) i will be glad in eternity. And i'm sorry for the long text, my bad English, and if i don't post back in time. Currently experiencing problems with our ISP provider, and connection goes offline from time to time.

* Text below are what i see into crash dumps almost 90% of the time everytime my system crashing*

0x124_0_GenuineIntel_PROCESSOR__UNKNOWN_IMAGE_GenuineIntel.sys
0x124_0_GenuineIntel_PROCESSOR_MAE_INTERNAL_TIMER_IMAGE_GenuineIntel.sys
CLOCK_WATCHDOG_TIMEOUT_INVALID_CONTEXT_nt!KeAccumulateTicks

http://speccy.piriform.com/results/Sr6Rx2nq4ckxSdwbV0ImVvV
 

Attachments

The most recent BSOD was a 0x101 CLOCK_WATCHDOG_TIMEOUT, dated today (8th May) - 050823-10328-01.dmp. There should be a corresponding kernel dump in the file C:\Windows\Memory.dmp, can you please upload that dump to the cloud somewhere (it will be too large for here) and post a link to it here. Be sure to make the file public.

BTW. What Adobe products do you run?
 
ubuysa said:
The most recent BSOD was a 0x101 CLOCK_WATCHDOG_TIMEOUT, dated today (8th May) - 050823-10328-01.dmp. There should be a corresponding kernel dump in the file C:\Windows\Memory.dmp, can you please upload that dump to the cloud somewhere (it will be too large for here) and post a link to it here. Be sure to make the file public.

BTW. What Adobe products do you run?
Click to expand...
Thank you for responding back. I used Photoshop 7 day trial months ago, but no recently.

Here's my memory dump:

memorydmp.7z

and minidumps in case of need:

minidumps.7z

Also i see, Speccy reports wrong CPU and GPU vram. I attach another system info with Aida64 trial version here.

Edit: Another bsod while trying to gather full system information with Aida64.
Also, lots of the following text into report.txt:

"MSR Registers (CPU #8):

MSR 000001AC < FAILED >
MSR 000001AD 2F2F-2F2F-2F2F-2F2F
MSR 000001AE < FAILED >
MSR 000001AF < FAILED >
MSR 000001B0 < FAILED >"
Latest minidump few minutes ago with Aida64 bsod: MEMORY.7z
 

Attachments

Last edited:
It's getting late here (Crete, Greece) but I'll look at the kernel dump first thing tomorrow.

FWIW a CLOCK_WATCHDOG_TIMEOUT is almost always a CPU failure. But I'll confirm that tomorrow.

You might want to clean up your hosts file. ;)
 
ubuysa said:
It's getting late here (Crete, Greece) but I'll look at the kernel dump first thing tomorrow.

FWIW a CLOCK_WATCHDOG_TIMEOUT is almost always a CPU failure. But I'll confirm that tomorrow.

You might want to clean up your hosts file. ;)
Click to expand...

Thank you very much Συντεκνε. :) Going to clean host file right away, and i hope you could give me a helping hand if possible.
 
Short Answer
The CLOCK_WATCHDOG_TIMEOUT BSOD occurs because a processor did not respond in time to a clock synchronisation interrupt, these are used to synchronise the various processor clocks. The failing processor (processor 10) is stuck in an MWaitIdle state, this is a special Intel power management state which probably allows the processor to enter a lower power state because there is no useful work for it to do (it's idle). In the MWait state however, the processor should respond to any interrupt - like the clock synchronisation interrupt - and it didn't. The software environment is all as expected so that failure to respond to the interrupt must be a hardware failure. You need to replace the CPU I'm afraid.

The WHEA (Windows Hardware Error Architecture) BSODs you've been getting are also suggestive of a CPU problem, but this CLOCK_WATCHDOG_TIMEOUT confirms it. You may want to stress your CPU with the tools mentioned above, but I doubt that it will get very far in any of them. It's terminal sadly.

Longer Answer
The CLOCK_WATCHDOG_TIMEOUT writes the faulty processor identifier in argument 4 of the parameters passed when the bugcheck occurs....
Rich (BB code): 
CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 000000000000000c, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffffb901dc7e4180, The PRCB address of the hung processor.
Arg4: 000000000000000a, The index of the hung processor.
This of course is processor 10 in decimal. If we examine the call stack of processor 10...
Rich (BB code): 
10: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffff948c`f2abef78 ffffb7c0`f246be46     intelppm!MWaitIdle+0x1f
01 ffff948c`f2abef80 0000002c`88cac0e0     0xffffb7c0`f246be46
02 ffff948c`f2abef88 ffff9d08`3107a0f0     0x0000002c`88cac0e0
03 ffff948c`f2abef90 ffffb901`dc7e4180     0xffff9d08`3107a0f0
04 ffff948c`f2abef98 00000000`00000000     0xffffb901`dc7e4180
These stacks are read from the bottom up (they're push down stacks), you can see that the last function that was called was intelppm!MWaitIdle. This is an Intel function that essentially handles power management of the processors, the MWaitIdle component places the processor in an idle state and (probably) a lower power state - but this is Intel specific. In the MWaitIdle state the processor is still enabled for interrupts and so should have responded to the clock synchronisation interrupt but it didn't.

Interestingly, if we examine the Interrupt Flag (the IF register) it should be at logical 1 if the processor is enabled for interrupts, and it's not...
Rich (BB code): 
10: kd> r if
if=0
That could indicate a problem with the interlppm.sys driver, though that's very unlikely. You could try installing the Intel Driver & Support Assistant and see whether that finds driver updates for the Intel hardware you have. This could also be related to the MWait instruction that Intel processors use to put the processor in a lower power idle state with interrupts enabled, it's possible that the MWait instruction doesn't set the IF register. I don't know nearly enough about the Intel x64 instruction set to know for sure.

If we look instead at processor 0 (the one that detected the problem) we can see what processor 10 should have done...
Rich (BB code): 
0: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffff801`24ca7c88 fffff801`20643704     nt!KeBugCheckEx
01 fffff801`24ca7c90 fffff801`20486e3d     nt!KeAccumulateTicks+0x1bfae4
02 fffff801`24ca7cf0 fffff801`2047dec1     nt!KiUpdateRunTime+0x5d
03 fffff801`24ca7d40 fffff801`20481253     nt!KiUpdateTime+0x4a1
04 fffff801`24ca7e80 fffff801`20488ae2     nt!KeClockInterruptNotify+0x2e3
05 fffff801`24ca7f30 fffff801`2053e965     nt!HalpTimerClockInterrupt+0xe2
06 fffff801`24ca7f60 fffff801`205fdc3a     nt!KiCallInterruptServiceRoutine+0xa5
07 fffff801`24ca7fb0 fffff801`205fe407     nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
08 ffff948c`f98ce810 fffff801`204ea6c1     nt!KiInterruptDispatchNoLockNoEtw+0x37
09 ffff948c`f98ce9a0 fffff801`208120e3     nt!KeFlushProcessWriteBuffers+0xb5
0a ffff948c`f98ce9e0 fffff801`20808d67     nt!ExpGetProcessInformation+0x183
0b ffff948c`f98cf040 fffff801`20807f17     nt!ExpQuerySystemInformation+0xd07
0c ffff948c`f98cf380 fffff801`2060f4f5     nt!NtQuerySystemInformation+0x37
0d ffff948c`f98cf3c0 00007ff9`f518d724     nt!KiSystemServiceCopyEnd+0x25
0e 00000066`67bdd478 00000000`00000000     0x00007ff9`f518d724
You can see the call to nt!HalpTimerClockInterrupt on receipt of the clock synchronisation interrupt. Processor 10 should have responded in a similar way and didn't. That's a hardware fault in the CPU.
 
Last edited:
jcgriff2 said:
Agree.

Until @ubuysa returns, run the Intel CPU diagnostic test - CPU STRESS testing: Mersenne.org Prime95 and Intel Processor Diagnostic Tool (IPDT)

Regards. . .

jcgriff2
Click to expand...

Sorry for late response. My son need the pc for school work/gaming. However, i did two quick Prime95 tests 1h each (Small FFT/Blend) & Intel's Diagnostic Tool, both no errors/warnings, and intel passed everything. Cpu temp was a bit high (100% cpu maxed at 83c), since son using just a cpu air cooler, without front/exhaust fans. No blue screens of death at all. I attach both prime95 + sys tool infos again in any case.
 

Attachments

ubuysa said:
Short Answer
The CLOCK_WATCHDOG_TIMEOUT BSOD occurs because a processor did not respond in time to a clock synchronisation interrupt, these are used to synchronise the various processor clocks. The failing processor (processor 10) is stuck in an MWaitIdle state, this is a special Intel power management state which probably allows the processor to enter a lower power state because there is no useful work for it to do (it's idle). In the MWait state however, the processor should respond to any interrupt - like the clock synchronisation interrupt - and it didn't. The software environment is all as expected so that failure to respond to the interrupt must be a hardware failure. You need to replace the CPU I'm afraid.

The WHEA (Windows Hardware Error Architecture) BSODs you've been getting are also suggestive of a CPU problem, but this CLOCK_WATCHDOG_TIMEOUT confirms it. You may want to stress your CPU with the tools mentioned above, but I doubt that it will get very far in any of them. It's terminal sadly.

Longer Answer
The CLOCK_WATCHDOG_TIMEOUT writes the faulty processor identifier in argument 4 of the parameters passed when the bugcheck occurs....
Rich (BB code): 
CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 000000000000000c, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffffb901dc7e4180, The PRCB address of the hung processor.
Arg4: 000000000000000a, The index of the hung processor.
This of course is processor 10 in decimal. If we examine the call stack of processor 10...
Rich (BB code): 
10: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffff948c`f2abef78 ffffb7c0`f246be46     intelppm!MWaitIdle+0x1f
01 ffff948c`f2abef80 0000002c`88cac0e0     0xffffb7c0`f246be46
02 ffff948c`f2abef88 ffff9d08`3107a0f0     0x0000002c`88cac0e0
03 ffff948c`f2abef90 ffffb901`dc7e4180     0xffff9d08`3107a0f0
04 ffff948c`f2abef98 00000000`00000000     0xffffb901`dc7e4180
These stacks are read from the bottom up (they're push down stacks), you can see that the last function that was called was intelppm!MWaitIdle. This is an Intel function that essentially handles power management of the processors, the MWaitIdle component places the processor in an idle state and (probably) a lower power state - but this is Intel specific. In the MWaitIdle state the processor is still enabled for interrupts and so should have responded to the clock synchronisation interrupt but it didn't.

Interestingly, if we examine the Interrupt Flag (the IF register) it should be at logical 1 if the processor is enabled for interrupts, and it's not...
Rich (BB code): 
10: kd> r if
if=0
That could indicate a problem with the interlppm.sys driver, though that's very unlikely. You could try installing the Intel Driver & Support Assistant and see whether that finds driver updates for the Intel hardware you have. This could also be related to the MWait instruction that Intel processors use to put the processor in a lower power idle state with interrupts enabled, it's possible that the MWait instruction doesn't set the IF register. I don't know nearly enough about the Intel x64 instruction set to know for sure.

If we look instead at processor 0 (the one that detected the problem) we can see what processor 10 should have done...
Rich (BB code): 
0: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffff801`24ca7c88 fffff801`20643704     nt!KeBugCheckEx
01 fffff801`24ca7c90 fffff801`20486e3d     nt!KeAccumulateTicks+0x1bfae4
02 fffff801`24ca7cf0 fffff801`2047dec1     nt!KiUpdateRunTime+0x5d
03 fffff801`24ca7d40 fffff801`20481253     nt!KiUpdateTime+0x4a1
04 fffff801`24ca7e80 fffff801`20488ae2     nt!KeClockInterruptNotify+0x2e3
05 fffff801`24ca7f30 fffff801`2053e965     nt!HalpTimerClockInterrupt+0xe2
06 fffff801`24ca7f60 fffff801`205fdc3a     nt!KiCallInterruptServiceRoutine+0xa5
07 fffff801`24ca7fb0 fffff801`205fe407     nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
08 ffff948c`f98ce810 fffff801`204ea6c1     nt!KiInterruptDispatchNoLockNoEtw+0x37
09 ffff948c`f98ce9a0 fffff801`208120e3     nt!KeFlushProcessWriteBuffers+0xb5
0a ffff948c`f98ce9e0 fffff801`20808d67     nt!ExpGetProcessInformation+0x183
0b ffff948c`f98cf040 fffff801`20807f17     nt!ExpQuerySystemInformation+0xd07
0c ffff948c`f98cf380 fffff801`2060f4f5     nt!NtQuerySystemInformation+0x37
0d ffff948c`f98cf3c0 00007ff9`f518d724     nt!KiSystemServiceCopyEnd+0x25
0e 00000066`67bdd478 00000000`00000000     0x00007ff9`f518d724
You can see the call to nt!HalpTimerClockInterrupt on receipt of the clock synchronisation interrupt. Processor 10 should have responded in a similar way and didn't. That's a hardware fault in the CPU.
Click to expand...

Oh...So, that explain the below texts too?

MSR Registers (CPU #1):
MSR 00000017 0004-0000-0000-0000 [PlatID = 1]
MSR 0000001B 0000-0000-FEE0-0800
MSR 00000035 0000-0000-0008-0010
MSR 00000048 0000-0000-0000-0001
MSR 00000049 < FAILED >

I just run Intel SSU too just now. Not a clue however, just added it. So, since i don't wanna bother people for my own problems, CPU needs a replacement? Perhaps some conflict due to motherboard (Gigabyte z590 Aorus Master) are designed for K cpus, while 11900f are not K? Sorry again, i know just few basics, and thats all :/
 

Attachments

Well that's interesting! Both your RAM and your CPU are on the qualified vendor list for that motherboard, so there should be no issues there. The Aida64 is another CLOCK_WATCHDOG_TMEOUT also failing processor 10...
Code: 
CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 000000000000000c, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffffd08038fe4180, The PRCB address of the hung processor.
Arg4: 000000000000000a, The index of the hung processor.
This time though the call stack of processor 10 is empty...
Code: 
10: kd> knL
 # Child-SP          RetAddr               Call Site
00 00000000`00000000 00000000`00000000     0x0
I've never seen that before but it doesn't look at all right. Are you sure you ran Aida64 (and Primne95) on ALL processors?

I notice that you have MSI Afterburner installed...
Code: 
10: kd> lmDvmrtcore64
Browse full module list
start             end                 module name
fffff803`63910000 fffff803`6391a000   RTCore64   (deferred)            
    Image path: \??\C:\Program Files (x86)\MSI Afterburner\RTCore64.sys
    Image name: RTCore64.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Jun 18 14:55:42 2020 (5EEB563E)
    CheckSum:         0000AC19
    ImageSize:        0000A000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
Are you doing any overclocking at all with that?

Also, one of our tools (SysnativeBSODApps.exe for the other BSOD analysts reading this) lists the throttlestop.sys driver as being installed...
Code: 
ThrottleStop.sys            Tue Oct  6 23:34:27 2020 (5F7CD4D3)
ThrottleStop is another CPU tweaking tool (primarily for laptops) that is used to tweak the CPU performance features - and undervolt the CPU. What use, if any, have you made of that tool?

It's essential with these kinds of BSOD that any and all CPU tweaking tools are returned to the stock values. This kind of CPU tweaking can (and does) lead to BSODs.

There don't appear to be any chipset driver updates on your motherboard support site, but I think it's worth downloading and running the Intel Driver & Support Assistant to see whether that finds any updated Intel drivers.

I also discovered that there is a recent BIOS update for your motherboard, dated April 26th 2023, it might be wise to upgrade to that.
 
ubuysa said:
Well that's interesting! Both your RAM and your CPU are on the qualified vendor list for that motherboard, so there should be no issues there. The Aida64 is another CLOCK_WATCHDOG_TMEOUT also failing processor 10...
Code: 
CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 000000000000000c, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffffd08038fe4180, The PRCB address of the hung processor.
Arg4: 000000000000000a, The index of the hung processor.
This time though the call stack of processor 10 is empty...
Code: 
10: kd> knL
 # Child-SP          RetAddr               Call Site
00 00000000`00000000 00000000`00000000     0x0
I've never seen that before but it doesn't look at all right. Are you sure you ran Aida64 (and Primne95) on ALL processors?

I notice that you have MSI Afterburner installed...
Code: 
10: kd> lmDvmrtcore64
Browse full module list
start             end                 module name
fffff803`63910000 fffff803`6391a000   RTCore64   (deferred)         
    Image path: \??\C:\Program Files (x86)\MSI Afterburner\RTCore64.sys
    Image name: RTCore64.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Jun 18 14:55:42 2020 (5EEB563E)
    CheckSum:         0000AC19
    ImageSize:        0000A000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
Are you doing any overclocking at all with that?

Also, one of our tools (SysnativeBSODApps.exe for the other BSOD analysts reading this) lists the throttlestop.sys driver as being installed...
Code: 
ThrottleStop.sys            Tue Oct  6 23:34:27 2020 (5F7CD4D3)
ThrottleStop is another CPU tweaking tool (primarily for laptops) that is used to tweak the CPU performance features - and undervolt the CPU. What use, if any, have you made of that tool?

It's essential with these kinds of BSOD that any and all CPU tweaking tools are returned to the stock values. This kind of CPU tweaking can (and does) lead to BSODs.

There don't appear to be any chipset driver updates on your motherboard support site, but I think it's worth downloading and running the Intel Driver & Support Assistant to see whether that finds any updated Intel drivers.

I also discovered that there is a recent BIOS update for your motherboard, dated April 26th 2023, it might be wise to upgrade to that.
Click to expand...

MSi afterburner yes. To keep an eye for gpu temps.
ThrottleStop suggested from a friend of mine, to just undervolt abit (-30mV) CPU Core/Cache, and to power limit, and lock all cores at 47, instead of 52, to check stability.Not using it now.Though, BSOD's occured even on pure vanilla Windows installation, without MSi / TStop or any other kind of software. Not even Gigabyte's official software for updates. I prefer to not tampering with Windows installations.
About motherboard firmware upate. This is weird now. Because i had updated bios a month ago with another Gigabyte update (f8a & f8f), that is both removed now from their site as i can see.But i'm gonna use that one from April 26 right away.
Regarding Aida and Prime95, yes tested all cores. No errors/warning at all.I don't know any other tools to check. Intel SSU also on all cores. Not any kind of overclocking also. Computer is used by my son for casual online gaming, and for school.
I can't understand why system hanging on normal use, be it while gaming, zipping/unziping folders, or compressing videos with Handbrake, but not a single bsod while doing all the stress test/benchmarks and/or Driver Verifier procedure. By the way, can you please suggest proper settings to run Driver Verifier once again, and motherboard to be defective and causing CPU issues?? Because various sites suggests different settings, and i'm confused. Thanks in advance and sorry for bothering you once again with my issue.
 
Last edited:
It's no bother at all, I like doing this stuff!

I don't think this is a driver error, but enabling Driver Verifier isn't a bad idea at all. See Driver Verifier - BSOD related - Windows 11, 10, 8.1 and 8 for full details on how to enable it.

This looks to me like a CPU problem, it's certainly a hardware problem because your System log is full of these error messages...
Code: 
Event[17]:
  Log Name: System
  Source: Microsoft-Windows-WHEA-Logger
  Date: 2023-05-09T10:05:27.3110000Z
  Event ID: 1
  Task: N/A
  Level: Error
  Opcode: Info
  Keyword: WHEA Error Event Logs
  User: S-1-5-19
  User Name: NT AUTHORITY\LOCAL SERVICE
  Computer: DESKTOP-29HD1SO
  Description:
A fatal hardware error has occurred. A record describing the condition is contained in the data section of this event.
It may be that whilst the CPU is hot running the stress tests it's behaving but when it's cooler it's flaky? I can't really explain what you're seeing with those stress tests, although I don't know how (or whether) they test the ability of the processors to process interrupts - which is what the CLOCK_WATCHDOG_TIMEOUT BSODs are failing?

I'm going to tag a couple of some of the forum's BSOD gurus, @axe0 and @x BlueRobot, to get their input on this, though they're very busy people so it may take a while for them to become available.
 
ubuysa said:
It may be that whilst the CPU is hot running the stress tests it's behaving but when it's cooler it's flaky? I can't really explain what you're seeing with those stress tests, although I don't know how (or whether) they test the ability of the processors to process interrupts - which is what the CLOCK_WATCHDOG_TIMEOUT BSODs are failing?
Click to expand...

Running any kind of stress test, not a single bsod, strange system behaviour(s) etc. And temps never going over 83c at full load (100%). But indeed, system hanging/crashing while doing normal stuff,s uch as gaming, compressing/uncompressing files and converting video files. My own personal computer,it's several years old, with an Intel 8700k (not o/c. Just turbo mode), and never had such issues. I'm just confused what is going on with that cpu (11900f) at the moment and can't explain it's behaviour. Perhaps to blame PSU since it's several years old? Motherboard? Gigabyte removed two bios updates from their official site (f8a/f8f), one of which (f8f) i had until before few minutes, before i update with F8 that you suggested me. I attached an image with the version of bios i had updated a month ago, which shows as "F8F" from December, while at GB site was as early April version. Thanks in advance once again for spending your time to help me. :)
 

Attachments

  • IMG_20230509_165055.jpg
    IMG_20230509_165055.jpg
    87.8 KB · Views: 4
xilolee said:
Hi!

(Ubuysa: check the CMP section :-))

We had another user with a 0x124 bsod and with an Intel processor.
He "solved" it disabling intelppm driver/he didn't have bsod without intelppm.
Take a look: [SOLVED] - 0x124 caused by GenuineIntel. WORKAROUNDS: Don't let CPU MHz drop (disable intelppm;disable speedstep;change power plan settings;remove under-clock)

By the way, if you are able to substitute It without losing money...
Click to expand...

Hello there, and thanks for taking time to help me. So, we should try with the "fix" above, by disabling "Intelppm.sys" and "Intel C-States" via bios? Or just one of the two? I don't have another same socket CPU to test also i am affraid. My personal system it's old, with 8700k, and runs just fine. Son's gaming/school computer has the issues, and alas, i can't afford at the moment to spend money (again) to buy new cpu.
 
Many thanks @xilolee, that's an interesting thread.

@Demetrius, one thing from that thread that I should have advised earlier is to try running the Intel Processor Diagnostic Tool. Since that's Intel specific it may be more useful than generic stress tests. It's worth running in any case.

Before you make any other changes, are your BIOS settings set to their default values or have you made any changes, if so what? And please double-check that there are no CPU overclocks or undervolts in place.

I would also strongly recommend that you take a System Restore point before doing anything else. If for any reason Windows won't boot you can boot the Windows installation media and run System Restore from there to go back to where you are now.

You can try disabling intelppm.sys by navigating to C:\Windows\System32\drivers, locate the intelppm.sys file and rename it to intelppm.sys.bak, then reboot. The intelppm.sys driver will not be loaded, so see how the PC behaves. I would expect the CPU to run a little hotter since there is now no power management.
 
Last edited:
Hi,

If we were to debug any 0x101 properly, we would need a full kernel dump.

Not sure how worthwhile it'd be to try the fix xilolee linked to. The user in that thread xilolee links to has a motherboard that's known to have a problem with that specific cpu for which the workaround applies.

What I would guess is that there may be a faulty hardware component, probably the cpu than the motherboard, but we can't confirm without physically swapping. Problem with hardware tests is that they're limited in what they can test, they may be effective but I've yet to see any test be able to find a problem with a CPU more than 2/100 times where the CPU was indeed the cause.
 
ubuysa said:
@Demetrius, one thing from that thread that I should have advised earlier is to try running the Intel Processor Diagnostic Tool. Since that's Intel specific it may be more useful than generic stress tests. It's worth running in any case.

Before you make any other changes, are your BIOS settings set to their default values or have you made any changes, if so what? And please double-check that there are no CPU overclocks or undervolts in place.

I would also strongly recommend that you take a System Restore point before doing anything else. If for any reason Windows won't boot you can boot the Windows installation media and run System Restore from there to go back to where you are now.

You can try disabling intelppm.sys by navigating to C:\Windows\System32\drivers, locate the intelppm.sys file and rename it to intelppm.sys.bak, then reboot. The intelppm.sys driver will not be loaded, so see how the PC behaves. I would expect the CPU to run a little hotter since there is now no power management.
Click to expand...

Just finished few minutes ago Intel Processor Diagnostic Tool 64bit, after updated bios via Gigabytes latest firmware. Everything passed again, temps maxed out: 75c / 5191.86MHz. Everything at default at Bios. No overcloking and such. Test results as attachment.

axe0 said:
Hi,

If we were to debug any 0x101 properly, we would need a full kernel dump.

Not sure how worthwhile it'd be to try the fix xilolee linked to. The user in that thread xilolee links to has a motherboard that's known to have a problem with that specific cpu for which the workaround applies.
Click to expand...

Hello there and many thanks for your response to my issue. I would be glad to submit a full kernel file, but as i said earlier, my Computer knowledge is limited to very basics. Full kernel dump is the "Memory.dmp" aka "complete crash dump"? If that is the correct file, i have submitted it few posts above, but i will here now again for any case. Sorry if this the wrong file. I'm bit lost with such technical terms.

MEMORY.7z
 

Attachments

That is the kernel dump that you have linked to. @axe0 may well see something in there that I have missed.

BTW. Disabling intelppm.sys will (should) cause your CPU to run at maximum power, which is what it will have been doing during the stress testing - which didn't BSOD. When you are using it normally the CPU, or at least some processors, will be switched to lower power states - and that may be the problem.

However, in my view, if disabling intelppm.sys does stop the BSODs it's only a workaround because your CPU should be stable across all power states.
 

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

Back
Top