Error encountered during startup: LiveKernelEvent 124
Error encountered during startup: LiveKernelEvent 124
MB: msi b450m-a pro
CPU: Ryzen 9 5900x
GPU RXT 3060 12GB ASUS
16GB RAM 2X8GB 2400MHZ
800W ATX NETWAY PSU
2x SAMSUNG EVO HDD 1TB, 1x HDD KINGSTON 500GB
W10
Crashes only happen during gaming. PC ( new CPU, GPU AND PSU) is 2 months old. Went from a AMD GPU to a NVIDIA GPU, used DDU to make a clean install.
CPU temp doesn't go over 65ºC. No overclocking setups.
Tried: Scanning drives, windows memory diagnostic, /scan /restorehealth, checking drivers, updating gpu drivers.
DMP from the last crash:
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: ffff9f83c59e7028, Address of the nt!_WHEA_ERROR_RECORD structure.
Arg3: 00000000bc800800, High order 32-bits of the MCi_STATUS value.
Arg4: 00000000060c0859, 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: 2859
Key : Analysis.Elapsed.mSec
Value: 10198
Key : Analysis.IO.Other.Mb
Value: 5
Key : Analysis.IO.Read.Mb
Value: 0
Key : Analysis.IO.Write.Mb
Value: 25
Key : Analysis.Init.CPU.mSec
Value: 561
Key : Analysis.Init.Elapsed.mSec
Value: 16633
Key : Analysis.Memory.CommitPeak.Mb
Value: 98
Key : Bugcheck.Code.LegacyAPI
Value: 0x124
Key : Dump.Attributes.AsUlong
Value: 8
Key : Dump.Attributes.KernelGeneratedTriageDump
Value: 1
Key : Failure.Bucket
Value: 0x124_0_AuthenticAMD_PROCESSOR__UNKNOWN_IMAGE_AuthenticAMD.sys
Key : Failure.Hash
Value: {035dcc87-485b-74b3-1c1b-ee50cb0c2865}
BUGCHECK_CODE: 124
BUGCHECK_P1: 0
BUGCHECK_P2: ffff9f83c59e7028
BUGCHECK_P3: bc800800
BUGCHECK_P4: 60c0859
FILE_IN_CAB: 122623-6078-01.dmp
DUMP_FILE_ATTRIBUTES: 0x8
Kernel Generated Triage Dump
BLACKBOXBSD: 1 (!blackboxbsd)
BLACKBOXNTFS: 1 (!blackboxntfs)
BLACKBOXPNP: 1 (!blackboxpnp)
BLACKBOXWINLOGON: 1
CUSTOMER_CRASH_COUNT: 1
PROCESS_NAME: DeadByDaylight
STACK_TEXT:
ffffd781`581a6938 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
MODULE_NAME: AuthenticAMD
IMAGE_NAME: AuthenticAMD.sys
STACK_COMMAND: .cxr; .ecxr ; kb
FAILURE_BUCKET_ID: 0x124_0_AuthenticAMD_PROCESSOR__UNKNOWN_IMAGE_AuthenticAMD.sys
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {035dcc87-485b-74b3-1c1b-ee50cb0c2865}
Followup: MachineOwner
(I'm not that much into tech so I'm kinda lost. Thank you in advance)
I don't recognize this brand.
What GPU were you using previously?
Do you experience BSOD with an older GPU?
Could you follow option one on the link provided?
Then proceed with the following steps: Small memory dumps - Have Windows create a small memory dump (minidump) after each BSOD - which generates a file in c windows/minidump following the next BSOD
Open Windows File Explorer
Go to C:\Windows\Minidump
Transfer the mini-dump files to your Desktop
Avoid using Winzip; use the built-in feature in Windows
Select those files on your Desktop, right-click and choose 'Send to' - Compressed (zipped) folder
Upload the zip file to the cloud (OneDrive, Dropbox, etc.)
Then share a link to the zip file so we can review it together.
I received an RX580 without any issues.
The manufacturer comes from the most popular computer shop in Spain (PCBox).
Attached in the dropbox link are the latest reports and a photo of the label.
New and older GPUs share identical power consumption. What CPU did you have before? It might be a mix of components... the PSU seems to be the weakest part. I’m not sure if this is the same model for the PSU.
https://foro-elchapuzasinformatico-...tr_sl=es&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=sc
report
- mostly for me, it didn’t help much this time.
WHEA errors don’t usually give much information.
File: 122623-6078-01.dmp (Dec 26 2023 - 22:20:32)
BugCheck: [124]
Likely caused by: AuthenticAMD (Process: DeadByDaylight)
Uptime: 0 Day(s), 18 Hour(s), 33 Min(s), 48 Sec(s)
File: 122423-5953-01.dmp (Dec 25 2023 - 06:16:07)
BugCheck: [124]
Likely caused by: AuthenticAMD (Process: HogwartsLegacy)
Uptime: 0 Day(s), 4 Hour(s), 17 Min(s), 28 Sec(s)
File: 122423-5734-01.dmp (Dec 25 2023 - 01:58:10)
BugCheck: [124]
Likely caused by: AuthenticAMD (Process: HogwartsLegacy)
Uptime: 1 Day(s), 2 Hour(s), 45 Min(s), 56 Sec(s)
File: 122223-5937-01.dmp (Dec 23 2023 - 08:24:25)
BugCheck: [124]
Likely caused by: AuthenticAMD (Process: HogwartsLegacy)
Uptime: 0 Day(s), 2 Hour(s), 54 Min(s), 48 Sec(s)
Hogwarts is affected, not the cause.
Comment: Two or more types of RAM are installed.
How long have you been using mismatched RAM sticks?
8192MB | 2400MHz | Kingston | KHX3200C18D4/8G
8192MB | 2400MHz | Kingston | KHX3200C16D4/8GX
different latency, it’s hard to say this would be the reason.
My previous CPU was a Ryzen 5 2600.
It seems the same PSU model is being used. The 800W unit.
I've been using a second RAM stick for almost four years, originally because I wanted to play Warzone during the lockdown and 8GB wasn't sufficient, so I upgraded to another one (the closest available).
Netway might belong to a brand under PCBox, but information about it is limited. The CPU wattage difference could be the reason, as you now have more cores than before. I’d consider getting a PSU from Corsair if possible—it’s likely to provide the power you need.