Question My PC rebooted from a bugcheck today and I need help to find the cause ?

Jan 14, 2025
31
0
30
This is probably no big deal, since it's only done it today so far, but i figured we should try to diagnose it just in case. My system bugchecked on boot, and then automatically rebooted as normal. These are my specs:

Motherboard: Asus PRIME B760-PLUS D4
CPU: Intel Core i5 13400F
GPU: Asus GeForce RTX 4060
RAM: Two x G.Skill DDR4 Aegis 2x8GB 3000Mhz, so 4 sticks of 8 GB.
PSU: Cooler Master MWE Gold 550 Full Modular V2 PSU
Storage: Samsung V-NAND 850 EVO 1TB SSD. - about 30% full. This is the only storage device.
OS: Windows 10 Home, Build 19045.5737, Version 22H2
Case: Fractal Design Meshify C

And here's the minidump:

https://files.catbox.moe/chktw4.zip

While going through the event viewer, i noticed a lot of errors related to GameInput Service, starting since a few days ago. There was apparently a duplicate installation of the program, which i have now fixed. Maybe that was the cause of the bugcheck, maybe not. I don't know how to open the dump file.

I don't know if it helps, but the event data was:
'0x00000050 (0xffffd308f0d68398, 0x0000000000000000, 0xfffff8076760ab9b, 0x0000000000000002)' with Report ID 'fb1d2fe6-1f50-4bcd-b38a-695cb86567b1'
 
Last edited:
RAM: Two x G.Skill DDR4 Aegis 2x8GB 3000Mhz, so 4 sticks of 8 GB.
Not saying that this is the cause of the problem, but from what I understand, generally it's best to only use RAM sticks from the same kit together; mixing kits, even of the same make and model, can apparently sometimes cause stability issues. If the BSOD starts happening regularly, it might be worth investigating if the RAM is the source of the problem (via memory tests, trying using only one stick and seeing if the problem resolves, or using a different, single kit of RAM if you have any spares and seeing if that resolves the problem). But I wouldn't rush out and buy a new kit of RAM until you are basically certain that that will fix the problem.
 
note: make sure you are not running a old windows insider build. from Dec 2019

looks like a bug in a service unfortunately the service is running under a generic name.
svchost.exe

the system looked like it was accessing a valid kernel address but it was invalid and caused a bugcheck.
it could be a bug in software or it could be a bit flipped in hardware. just can not tell.
System Uptime: 1 days 14:31:54.148
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
debugger does not like your build version. (checksum errors checking the build version with microsoft, might just be a debugger issue)

notes:
: kd> !sysinfo machineid
Machine ID Information [From Smbios 3.5, DMIVersion 0, Size=5698]
BiosMajorRelease = 18
BiosMinorRelease = 5
BiosVendor = American Megatrends Inc.
BiosVersion = 1805
BiosReleaseDate = 10/30/2024
SystemManufacturer = ASUS
SystemProductName = System Product Name
SystemFamily = To be filled by O.E.M.
SystemVersion = System Version
SystemSKU = SKU
BaseBoardManufacturer = ASUSTeK COMPUTER INC.
BaseBoardProduct = PRIME B760-PLUS D4
BaseBoardVersion = Rev 1.xx
0: kd> !sysinfo cpuspeed
CPUID: "13th Gen Intel(R) Core(TM) i5-13400F"
Rated Speed: Not detected!
Measured Speed: 2496
 
Last edited:
note: make sure you are not running a old windows insider build. from Dec 2019

I'm not sure what to do about this. I've never participated in it, as far as i'm aware.

looks like a bug in a service unfortunately the service is running under a generic name.
svchost.exe

the system looked like it was accessing a valid kernel address but it was invalid and caused a bugcheck.
it could be a bug in software or it could be a bit flipped in hardware. just can not tell.
System Uptime: 1 days 14:31:54.148
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
debugger does not like your build version. (checksum errors checking the build version with microsoft, might just be a debugger issue)

I do know that GameInput Service causes system crashes when it has a duplicate install. GameInput Service started throwing error messages in event viewer after i installed some legacy software so i could play Naissance. I've since fixed the duplicate install, and the errors have dissapeared. Perhaps that was all that was going on.

notes:
: kd> !sysinfo machineid
Machine ID Information [From Smbios 3.5, DMIVersion 0, Size=5698]
BiosMajorRelease = 18
BiosMinorRelease = 5
BiosVendor = American Megatrends Inc.
BiosVersion = 1805
BiosReleaseDate = 10/30/2024
SystemManufacturer = ASUS
SystemProductName = System Product Name
SystemFamily = To be filled by O.E.M.
SystemVersion = System Version
SystemSKU = SKU
BaseBoardManufacturer = ASUSTeK COMPUTER INC.
BaseBoardProduct = PRIME B760-PLUS D4
BaseBoardVersion = Rev 1.xx
0: kd> !sysinfo cpuspeed
CPUID: "13th Gen Intel(R) Core(TM) i5-13400F"
Rated Speed: Not detected!
Measured Speed: 2496

Weird CPU speeds again? I wonder if it's some kind of lingering damage from the intel shenanigans. I didn't touch the voltages myself.

My system has been stable since i built it last summer, and it's been fine today, so as long as this doesn't get any worse i suppose it's fine. It's a shame there's nothing conclusive in the logs, but we'll see if anything else pops up.
 
weird cpu speed: just from past experience, I have seen cpu speeds reported in increments of 100MHz as proper values. When I see a cpu speed like 2496 Mhz I start to look for things that would tweak the cpu speeds. it can indicate:
- old bios with a newer CPU
- bios overclocking
- new overclocking driver used on a old bios version
- new bios version using a old overclocking driver
- more than one overclocking driver in use at the same time
- on old systems, cpu fans clogged with dust, cpu overheating and the cpu throttling kicking in to reduce the heat.

for the old build of windows 10, just make sure that windows updates are not being blocked. Sometimes I see people restore a old build and block the updates. Windows 10 is going out of support in october 2025. in your case, your build does not match the builds that the windows debugger has symbols for. This means you can not trust the debugger for the info it is reports.
the debugger indicates that about 90 percent of your windows files did not match known version of the files.

for your case since the problem is in a service host it is just likely a 3rd party service that is causing the problem. (I think my system has over 50 service host running)

a service host is a program that just runs under another program as a service. when the program crashes it just looks like the main program crashed and does not name the subprogram that is really the cause.
you have to look on the running services on your machine and look at the ones not produced by windows. it will not be a windows service if you have windows update turned on, since windows update will update any broken windows service. Windows expect you to update any third party service. Most often it will be in mouse software/ firmware and other addons

you can look at the services running and stop or disable suspect services. this tool can also help:
https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer

it can show how the service was started.
edit: you would run procexp64.exe then sort the list by company name. I would first look at the non microsoft services. (list is pretty short on my system 5 non microsoft services)
 
Last edited:
weird cpu speed: just from past experience, I have seen cpu speeds reported in increments of 100MHz as proper values. When I see a cpu speed like 2496 Mhz I start to look for things that would tweak the cpu speeds. it can indicate:
- old bios with a newer CPU
- bios overclocking
- new overclocking driver used on a old bios version
- new bios version using a old overclocking driver
- more than one overclocking driver in use at the same time
- on old systems, cpu fans clogged with dust, cpu overheating and the cpu throttling kicking in to reduce the heat.
None of these really match my circumstances - i don't overclock, and the system should be clean enough to prevent throttling. I wouldn't be surprised if it's got something to do with the emergency updates to save intel processors though. According the manufacturer specs, the rated speed is 2500 Mhz.

for the old build of windows 10, just make sure that windows updates are not being blocked. Sometimes I see people restore a old build and block the updates. Windows 10 is going out of support in october 2025. in your case, your build does not match the builds that the windows debugger has symbols for. This means you can not trust the debugger for the info it is reports.
the debugger indicates that about 90 percent of your windows files did not match known version of the files.
The only thing i've done that could cause something like this is that i blocked some windows 11 stuff and some windows 10 features that i didn't like. It was most of a year ago, so I can't remember exactly what i did, but i've taken care not to block anything that would cause a security risk . The majority of the updates should still work fine, but i do see them fail fairly often in the reliability monitor - about 1 in 10-15 per week. Not nearly enough to cause 90%, i would think. (EDIT: all of the failed updates are related to 'yourphone' and xbox stuff. Nothing I care about)

for your case since the problem is in a service host it is just likely a 3rd party service that is causing the problem. (I think my system has over 50 service host running)

a service host is a program that just runs under another program as a service. when the program crashes it just looks like the main program crashed and does not name the subprogram that is really the cause.
you have to look on the running services on your machine and look at the ones not produced by windows. it will not be a windows service if you have windows update turned on, since windows update will update any broken windows service. Windows expect you to update any third party service. Most often it will be in mouse software/ firmware and other addons
That does sound like it might have been the GameInput service.

EDIT: i've run process explorer and found nothing suspicious. I could post a screenshot if you like.
 
Last edited:
None of these really match my circumstances - i don't overclock, and the system should be clean enough to prevent throttling. I wouldn't be surprised if it's got something to do with the emergency updates to save intel processors though. According the manufacturer specs, the rated speed is 2500 Mhz.


The only thing i've done that could cause something like this is that i blocked some windows 11 stuff and some windows 10 features that i didn't like. It was most of a year ago, so I can't remember exactly what i did, but i've taken care not to block anything that would cause a security risk . The majority of the updates should still work fine, but i do see them fail fairly often in the reliability monitor - about 1 in 10-15 per week. Not nearly enough to cause 90%, i would think. (EDIT: all of the failed updates are related to 'yourphone' and xbox stuff. Nothing I care about)


That does sound like it might have been the GameInput service.

EDIT: i've run process explorer and found nothing suspicious. I could post a screenshot if you like.
process explorer will not report any problems, it just makes it easy to see the non microsoft services, then click on them and see the command line and name of the .exe used to run as a service. Then you have to search your drive for the .exe and check the data and file stamp and look for a update. I think you can also dump the stack for the process but I have not used it in years, it might have been a different sysinternals program.

otherwise, you can change the memory dump type to kernel and have someone see if they can find the service command line string in the dump. I might remember how to do it. (it always take a few tries in the debugger) the info is not saved in a minidump file

for your case: you had what looks like a kernel address that should have been valid but was not. The assumption would be that one of the bits in the kernel address was not valid when read. the recommendation for this case would be to run memtest86 and confirm your memory timings are correct. this removes windows and windows device drivers as a potential cause since memtest86 runs on its own boot image without windows.

just make sure any bios auto overclocking is turned off or you can waste a lot of time looking for a problem that is due to a bios setting to auto overclock
 
Last edited:
  • Like
Reactions: ThereAndBackAgain
process explorer will not report any problems, it just makes it easy to see the non microsoft services, then click on them and see the command line and name of the .exe used to run as a service. Then you have to search your drive for the .exe and check the data and file stamp and look for a update. I think you can also dump the stack for the process but I have not used it in years, it might have been a different sysinternals program.

otherwise, you can change the memory dump type to kernel and have someone see if they can find the service command line string in the dump. I might remember how to do it. (it always take a few tries in the debugger) the info is not saved in a minidump file

for your case: you had what looks like a kernel address that should have been valid but was not. The assumption would be that one of the bits in the kernel address was not valid when read. the recommendation for this case would be to run memtest86 and confirm your memory timings are correct. this removes windows and windows device drivers as a potential cause since memtest86 runs on its own boot image without windows.

just make sure any bios auto overclocking is turned off or you can waste a lot of time looking for a problem that is due to a bios setting to auto overclock
for memory timings I would be looking at what your RAM secondary timing for your command rate is set to.
often it defaults to a 1 clock (1n or 1t) when it really needs to be set to 2. (just a common issue where bios defaults are often wrong and results in address bits getting flipped since they get read before the address controller lines are stable)
 
just make sure any bios auto overclocking is turned off or you can waste a lot of time looking for a problem that is due to a bios setting to auto overclock
I've been trying to figure this out, and i've noticed that my CPU speed tends to vary between 2.5 and 4.6 Ghz due to turboboosting, which is standard behaviour for this kind of CPU. Is that the auto overclocking you're talking about? It would seem like a pretty big loss in performance to turn that off.

I am, in the meantime, setting up memtest. It seem pretty straightforward. I won't touch any of the settings other than ensuring it does all 11 tests for 4 passes, unless you say otherwise. I'll probably be doing it this on friday, which is when i have the time.
 
Last edited:
I've been trying to figure this out, and i've noticed that my CPU speed tends to vary between 2.5 and 4.6 Ghz due to turboboosting, which is standard behaviour for this kind of CPU. Is that the auto overclocking you're talking about? It would seem like a pretty big loss in performance to turn that off.
I don't think stock off-the-shelf boost frequencies are a problem.
 
I actually managed to get the memtest done today, and it passed with no errors. I also took the chance to take a look through the BIOS settings, and there was no sign of XMP profiles, overclocking or anything. All settings were on either auto or default.

I also took a picture of the voltage monitor, just in case any of it looks wrong to anyone:

20250416-175025.jpg
 
Last edited:
for memory timings I would be looking at what your RAM secondary timing for your command rate is set to.
often it defaults to a 1 clock (1n or 1t) when it really needs to be set to 2. (just a common issue where bios defaults are often wrong and results in address bits getting flipped since they get read before the address controller lines are stable)
I'm not finding the exact thing you're talking about, but i'm guessing you want me to set this to 2N?

https://postimg.cc/BtN1tGvL
 
Last edited:
So you want everything to be set slower for the sake of stability?
I hope the voltages are on that same screen somewhere, because i have no idea what i'm doing.

I've also taken another look at the software side of things, and noticed this:
System Uptime: 1 days 14:31:54.148
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
debugger does not like your build version. (checksum errors checking the build version with microsoft, might just be a debugger issue)
OS: Windows 10 Home, Build 19045.5737, Version 22H2
How is that the log you read and my systems 'about' page list two different build versions? Or is it referring to something else?

To be honest, i'm not even sure if the stability problem is still there. This is, as i said before, the first crash in 9 months, scannow fixed some things, and fixing my GameInput Service problems did fix a bunch of errors. I'm half inclined to wait and see if it was just a fluke and/or the stuff i did so far fixed it.
 
Last edited:
16-18-18-38-2n 1.35v

looks like you have
15-15-15-36 (dram command rate set to auto, not shown)
your voltage is 1.2 v
Before i touch anything, i have one more question:
You initially told me to only change the timing to 2N. Was also changing all of the other stuff always implied, or just a later addition based on my picture? Would only changing the timing to 2N have done harm? Because i really do need to stress that i know nothing about this other than what i've recently googled.
 
Last edited:
Before i touch anything, i have one more question:
You initially told me to only change the timing to 2N. Was also changing all of the other stuff always implied, or just a later addition based on my picture? Would only changing the timing to 2N have done harm? Because i really do need to stress that i know nothing about this other than what i've recently googled.
using under voltage on your memory, while overclocking from the default, I would set the command rate to 2N just because it is only adding 1 clock tick to make sure that the setup and hold time for the memory address electronics is stable before the address is locked in.
if you could see what the electronics signals look like on a oscilloscope it is easier to understand. More voltage, adds heat but puts makes the signals more into the correct voltage range for proper address sampling. Adding time to the command rate moves the sample time to a higher point in the voltage curve and gets a better chance to read the address as the correct value.
(the conversion from a voltage to a bit value)

I just mention the 2N because it is so often a simple fix and is so commonly set incorrectly in bios. The biggest problem I see is that people might set it, years later do a bios update and forget to set it again.
note: we are talking about nanosecond timing signals.
1 N often works until you have more memory sticks, then you get a time lag due to the distance/capacitance of the circuit. (ie memory chips closer to the cpu work as expected, chips a inch further start to hit timing problems)