Reporting an interruption where the display turns dark plus a buzzing sound followed by a restart.
Reporting an interruption where the display turns dark plus a buzzing sound followed by a restart.
This situation seems to occur roughly every couple of weeks, though it’s still worrying. I keep playing the same game, and it appears to happen intermittently. It usually ends with a sudden black screen accompanied by a persistent buzzing sound before the system restarts quickly. The Event Viewer shows a critical error: "The system has rebooted without cleanly shutting down first. This error could be caused if the system stopped responding, crashed, or lost power unexpectedly."
I don’t have any under or overclocks other than XMP and PBO being active, which is the standard setting for my CPU (Ryzen 5600X). All drivers are up to date. I’m worried because all components are less than a year old except the PSU, but it’s only around 4-5 years old—nothing unusual.
Here’s a summary of my specs (excluding PSU) and their validation via CPU-Z:
https://valid.x86.fr/g9fv13
My PSU: EVGA 600W 80 GD+
AMD Ryzen 5 5600X at 4398.97 MHz - CPU-Z validator
[g9fv13] Verified dump by DESKTOP-K8A07C4 (2024-01-20 19:26:24) - MB: MSI MPG B550 GAMING PLUS (MS-7C56) - RAM: 32768 MB
valid.x86.fr
BIOS: American Megatrends International LLC. 1.C0 (03/13/2023)
https://www.msi.com/Motherboard/MPG-B550...US/support
Update BIOS to version 7C56v1F, reset CMOS and test.
To reset CMOS: shut down, unplug from power and display, remove CMOS battery, hold power button for 30 seconds, then replace battery after 30 minutes. Re-enable BIOS, turn on X.M.P and disable CSM if needed.
Your PSU model is EVGA 600W 80 GD+.
How much is your PSU?
In fact, this PSU was originally from a pre-built unit I purchased over four years ago. Given that 4 to 5 years have passed, it's likely it's reached its age. All components in the pre-build, including the motherboard and boot drive, have been replaced. Only the case and PSU remain intact.
Additionally, I want to troubleshoot other aspects first—since I never removed a CMOS battery from a motherboard, I'm a bit worried about making mistakes, but I’m confident I can find a guide.
Lastly, I downloaded WinDbg and executed it on a .dmp file located at: Windows/LiveKernelReports/WHEA. I ran the analysis command and will share the results below if they’re helpful.
Edited by Moderator to add the spoiler tags
Spoiler
************* Preparing the environment for Debugger Extensions Gallery repositories **************
ExtensionRepository : Implicit
UseExperimentalFeatureForNugetShare : true
AllowNugetExeUpdate : true
AllowNugetMSCredentialProviderInstall : true
AllowParallelInitializationOfLocalRepositories : true
-- Configuring repositories
----> Repository : LocalInstalled, Enabled: true
----> Repository : UserExtensions, Enabled: true
>>>>>>>>>>>>> Preparing the environment for Debugger Extensions Gallery repositories completed, duration 0.000 seconds
************* Waiting for Debugger Extensions Gallery to Initialize **************
>>>>>>>>>>>>> Waiting for Debugger Extensions Gallery to Initialize completed, duration 0.015 seconds
----> Repository : UserExtensions, Enabled: true, Packages count: 0
----> Repository : LocalInstalled, Enabled: true, Packages count: 36
Microsoft ® Windows Debugger Version 10.0.25921.1001 AMD64
Copyright © Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\LiveKernelReports\WHEA\WHEA-20240120-0017.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19045 MP (12 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Kernel base = 0xfffff801`65400000 PsLoadedModuleList = 0xfffff801`6602a790
Debug session time: Sat Jan 20 00:17:24.274 2024 (UTC - 5:00)
System Uptime: 0 days 0:00:04.868
Loading Kernel Symbols
...............................................................
................................................................
...........
Loading User Symbols
PEB is paged out (Peb.Ldr = 00000082`8d9c2018). Type ".hh dbgerr001" for details
Mini Kernel Dump does not contain unloaded driver list
For analysis of this file, run !analyze -v
nt!LkmdTelCreateReport+0x13e:
fffff801`65d856c6 488b03 mov rax,qword ptr [rbx] ds:002b:ffffa901`632a1f70=????????????????
6: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
nt!_WHEA_ERROR_RECORD structure that describes the error condition. Try !errrec Address of the nt!_WHEA_ERROR_RECORD structure to get more details.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: ffffa90163411840, Address of the nt!_WHEA_ERROR_RECORD structure.
Arg3: 00000000baa00000, High order 32-bits of the MCi_STATUS value.
Arg4: 000000000002010b, Low order 32-bits of the MCi_STATUS value.
Debugging Details:
------------------
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: hal!_WHEA_PROCESSOR_GENERIC_ERROR_SECTION ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Either you specified an unqualified symbol, or your debugger ***
*** doesn't have full symbol information. Unqualified symbol ***
*** resolution is turned off by default. Please either specify a ***
*** fully qualified symbol module!symbolname, or enable resolution ***
*** of unqualified symbols by typing ".symopt- 100". Note that ***
*** enabling unqualified symbol resolution with network symbol ***
*** server shares in the symbol path may cause the debugger to ***
*** appear to hang for long periods of time when an incorrect ***
*** symbol name is typed or the network symbol server is down. ***
*** ***
*** For some commands to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: hal!_WHEA_PROCESSOR_GENERIC_ERROR_SECTION ***
*** ***
*************************************************************************
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 2546
Key : Analysis.Elapsed.mSec
Value: 2542
Key : Analysis.IO.Other.Mb
Value: 0
Key : Analysis.IO.Read.Mb
Value: 0
Key : Analysis.IO.Write.Mb
Value: 0
Key : Analysis.Init.CPU.mSec
Value: 264
Key : Analysis.Init.Elapsed.mSec
Value: 4876
Key : Analysis.Memory.CommitPeak.Mb
Value: 82
Key : Bugcheck.Code.LegacyAPI
Value: 0x124
Key : Dump.Attributes.AsUlong
Value: 18
Key : Dump.Attributes.KernelGeneratedTriageDump
Value: 1
Key : Failure.Bucket
Value: LKD_0x124_0_AuthenticAMD_PROCESSOR__UNKNOWN_IMAGE_AuthenticAMD.sys
Key : Failure.Hash
Value: {f59f17e7-f24e-04f5-3f16-e9425b2acba5}
BUGCHECK_CODE: 124
BUGCHECK_P1: 0
BUGCHECK_P2: ffffa90163411840
BUGCHECK_P3: baa00000
BUGCHECK_P4: 2010b
FILE_IN_CAB: WHEA-20240120-0017.dmp
DUMP_FILE_ATTRIBUTES: 0x18
Kernel Generated Triage Dump
Live Generated Dump
PROCESS_NAME: smss.exe
STACK_TEXT:
ffffbe8a`4992f150 fffff801`65d6095f : ffffa901`63411820 00000000`00000000 ffffa901`63411840 00000000`00000022 : nt!LkmdTelCreateReport+0x13e
ffffbe8a`4992f690 fffff801`65d60856 : ffffa901`63411820 fffff801`00000000 00000082`00000000 00000082`8daff9d0 : nt!WheapReportLiveDump+0x7b
ffffbe8a`4992f6d0 fffff801`65bd3e7d : 00000000`00000001 ffffbe8a`4992fb40 00000082`8daff9d0 00000000`0000020c : nt!WheapReportDeferredLiveDumps+0x7a
ffffbe8a`4992f700 fffff801`65a883f7 : 00000000`00000000 ffffa901`62431030 00000000`00000103 00000000`00000000 : nt!WheaCrashDumpInitializationComplete+0x59
ffffbe8a`4992f730 fffff801`65811238 : ffffa901`630e0000 ffffa901`6243ed80 ffffbe8a`4992fb40 ffffa901`00000000 : nt!NtSetSystemInformation+0x1f7
ffffbe8a`4992fac0 00007ffe`8e2f0554 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x28
00000082`8daff978 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`8e2f0554
MODULE_NAME: AuthenticAMD
IMAGE_NAME: AuthenticAMD.sys
STACK_COMMAND: .cxr; .ecxr ; kb
FAILURE_BUCKET_ID: LKD_0x124_0_AuthenticAMD_PROCESSOR__UNKNOWN_IMAGE_AuthenticAMD.sys
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {f59f17e7-f24e-04f5-3f16-e9425b2acba5}
Followup: MachineOwner
---------
Moderator Note: Do not post long log listings without wrapping them with the "<spoiler>", "</spoiler>" tags.
I also noticed the Event ID 18 in the event viewer at the time of the crash:
https://imgur.com/lJ4ZvrJ
This raises the possibility of a hardware problem, especially since all components are new and the PSU is nearly five years old. The EVGA 600W 80 Gold+ should be dependable, but it's still worrying.
Troubleshooting becomes difficult because the crash happens infrequently. I can try several steps like resetting the BIOS, reinstalling drivers, disabling XMP, and running memory tests, but I’m unsure how effective they’d be without a crash in just three weeks.
Could there be a way to monitor something like the PSU’s power draw? That might give more insight without needing to remove parts or change settings for an extended period?