[W10] Kernel Power 41 - Unexpected instant shutdown

kyle said:

not a random shutdown this time but a bsod.

Attachment 388528

whea cpu error

5: 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
whea_error_record structure that describes the error conditon. Try !errrec address of the whea_error_record structure to get more details.
Arguments:
Arg1: 0000000000000000, machine check exception
arg2: Ffffc802c7bb7028, address of the whea_error_record structure.
Arg3: 00000000b6000000, high order 32-bits of the mci_status value.
Arg4: 0000000000100153, 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: 2093

key : Analysis.debuganalysismanager
value: Create

key : Analysis.elapsed.msec
value: 2681

key : Analysis.init.cpu.msec
value: 171

key : Analysis.init.elapsed.msec
value: 3758

key : Analysis.memory.commitpeak.mb
value: 77


dump_file_attributes: 0x8
kernel generated triage dump

bugcheck_code: 124

bugcheck_p1: 0

bugcheck_p2: Ffffc802c7bb7028

bugcheck_p3: B6000000

bugcheck_p4: 100153

blackboxbsd: 1 (!blackboxbsd)


blackboxntfs: 1 (!blackboxntfs)


blackboxpnp: 1 (!blackboxpnp)


blackboxwinlogon: 1

customer_crash_count: 1

process_name: Firefox.exe

stack_text:
Ffffb780`569c6938 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Nt!kebugcheckex


module_name: Authenticamd

image_name: Authenticamd.sys

stack_command: .thread ; .cxr ; 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
---------

Both dumps in that upload are 0x124 WHEA_UNCORRECTABLE_ERROR with a machine check exception code, these are almost always a hardware error although they can sometimes be driver related. Unfortunately the WHEA error record doesn't appear to contain anything useful, although the error type is FATAL.

Are you overclocking anything? I can see you have MSI Afterburner installed, so are you overclocking the GPU? What about RAM, is that running at stock frequencies? WHEA errors are commonly caused by overly aggressive overclocking, or by overly aggressive undervolting too. It's most important with these types of BSOD that everything is running at stock voltages and frequencies.

I can see too that both ESET Security and Malwarebytes Security are running. Malwarebytes is pretty tolerant of other anti-malware products, but I'm not sure that ESET is quite so tolerant. It's generally unwise to have two real-time anti-virus engines running because they can get in each other's way. Whether they can cause a WHEA BSOD I'm far less sure about. It would be safer to pick one other products and uninstall the other (or both TBH).

I would also suggest starting Windows in Safe Mode (with networking). In this mode no third-party drivers are loaded, so if you can make it BSOD in Safe Mode you're almost certainly looking at a hardware issue. On the other hand, if it won't BSOD it's likely to be a rogue driver and we can do some more troubleshooting on that.

On balance however, I think this smells of a hardware issue.

The only way to know is to drop back to stock settings and see whether it's stable.

There are two dumps in that upload and both are 0x124 WHEA_UNCORRECTABLE_ERROR for a machine check exception, these BSODs are almost always hardware related. Unfortunately I can't get any useful data from the WHEA_ERROR_RECORD structure. You could try uploading the file C:\Windows\Memory.dmp (that's the most recent kernel dump) to a cloud service (Dropbox, OneDrive, etc.) and post a link to it here - be sure to make the file public.

I see nothing in your logs that might indicate hardware failing.

I would suggest downloading Memtest86 and running the free version twice (so you do 8 iterations of then 13 tests). You do have a strange RAM configuration with three 4GB sticks and one 2GB stick, why is that? It might be worth removing a couple of sticks and running for a while on just two, if it's OK then swap the sticks over. This is often the most reliable RAM test.