Question Help with MiniDump Please?

[Gazza_1988]

Hello all,

I was wondering if someone could help me as I'm losing the will with my PC which I use for work. I seem to be experiencing sudden BSOD's (every hour or so). I had this problem last year and I thought it was being caused by the iCue software I had installed however the problems have returned and strangely enough, it seems to happen when the weather is hot as it did last year. My system shows the GPU and CPU are around 40-50C so I can't seem to pinpoint where the problem is. I have my fans going 100% including the GPU but still I get BSOD's.

My PC consists of the following components

i7 6800k (NZXT Kraken X52 AIO)
RTX 3070TI (FE)
MSI X99 Gaming Carbon Pro
4x8GB Corsair Vengeance DDR4 3200
WD Blue NVME M.2 Boot Drive

Here is the latest mini dump file. I have no idea what I'm looking at so apologies for my ignorance but any assistance would be very much appreciated.

For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff803`3b5fbca0 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:ffffb100`4c1678f0=0000000000000124
10: 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: ffff9d8648c8f028, Address of the nt!_WHEA_ERROR_RECORD structure.
Arg3: 00000000be000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000800400, 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 ***
*** ***
*************************************************************************
*** WARNING: Unable to verify checksum for win32k.sys

KEY_VALUES_STRING: 1

Key : Analysis.CPU.mSec
Value: 5031

Key : Analysis.DebugAnalysisManager
Value: Create

Key : Analysis.Elapsed.mSec
Value: 15583

Key : Analysis.IO.Other.Mb
Value: 3

Key : Analysis.IO.Read.Mb
Value: 0

Key : Analysis.IO.Write.Mb
Value: 27

Key : Analysis.Init.CPU.mSec
Value: 1125

Key : Analysis.Init.Elapsed.mSec
Value: 50152

Key : Analysis.Memory.CommitPeak.Mb
Value: 99

Key : Bugcheck.Code.DumpHeader
Value: 0x124

Key : Bugcheck.Code.Register
Value: 0x124

Key : WER.OS.Branch
Value: vb_release

Key : WER.OS.Timestamp
Value: 2019-12-06T14:06:00Z

Key : WER.OS.Version
Value: 10.0.19041.1


FILE_IN_CAB: 061223-9875-01.dmp

BUGCHECK_CODE: 124

BUGCHECK_P1: 0

BUGCHECK_P2: ffff9d8648c8f028

BUGCHECK_P3: be000000

BUGCHECK_P4: 800400

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: System

STACK_TEXT:
ffffb100`4c1678e8 fffff803`3b6b785a : 00000000`00000124 00000000`00000000 ffff9d86`48c8f028 00000000`be000000 : nt!KeBugCheckEx
ffffb100`4c1678f0 fffff803`3ab815b0 : 00000000`00000000 ffff9d86`48c8f028 ffff9d86`469f1360 ffff9d86`48c8f028 : nt!HalBugCheckSystem+0xca
ffffb100`4c167930 fffff803`3b7b9b3e : 00000000`00000000 ffffb100`4c1679d9 ffff9d86`48c8f028 ffff9d86`469f1360 : PSHED!PshedBugCheckSystem+0x10
ffffb100`4c167960 fffff803`3b6b9181 : ffff9d86`46902ac0 ffff9d86`46902ac0 ffff9d86`469f13b0 ffff9d86`469f1360 : nt!WheaReportHwError+0x46e
ffffb100`4c167a40 fffff803`3b6b94f3 : 00000000`0000000a ffff9d86`469f13b0 ffff9d86`469f1360 00000000`0000000a : nt!HalpMcaReportError+0xb1
ffffb100`4c167bb0 fffff803`3b6b93d0 : ffff9d86`468e37e0 00000000`00000001 00000000`00000000 00000000`00000000 : nt!HalpMceHandlerCore+0xef
ffffb100`4c167c00 fffff803`3b6b9621 : 00000000`0000000c 00000000`00000001 00000000`00000000 00000000`00000000 : nt!HalpMceHandler+0xe0
ffffb100`4c167c40 fffff803`3b6b888b : 00000000`00000000 00000000`00000000 ffffb100`4c167ed0 00000000`00000000 : nt!HalpMceHandlerWithRendezvous+0xc9
ffffb100`4c167c70 fffff803`3b6bb0d5 : ffff9d86`468e37e0 00000000`00000000 00000000`00000000 00000000`00000000 : nt!HalpHandleMachineCheck+0x5f
ffffb100`4c167ca0 fffff803`3b710bf9 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!HalHandleMcheck+0x35
ffffb100`4c167cd0 fffff803`3b60c8ba : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiHandleMcheck+0x9
ffffb100`4c167d00 fffff803`3b60c577 : 00000000`00000000 fffff803`3b60c4ac 00000000`00000001 00000000`00000000 : nt!KxMcheckAbort+0x7a
ffffb100`4c167e40 fffff803`5581138f : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiMcheckAbort+0x277
ffff9702`7a4bf678 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : intelppm!MWaitIdle+0x1f


MODULE_NAME: GenuineIntel

IMAGE_NAME: GenuineIntel.sys

STACK_COMMAND: .cxr; .ecxr ; kb

FAILURE_BUCKET_ID: 0x124_0_GenuineIntel_PROCESSOR__UNKNOWN_IMAGE_GenuineIntel.sys

OS_VERSION: 10.0.19041.1

BUILDLAB_STR: vb_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {5371cb52-c3d9-558e-47d4-d31c09567ca2}

Followup: MachineOwner
---------

 

[Ralston18]

Debuggers and mini-dumps have their purposes and there are some members here ( I, full disclosure, am not one of them) who regularly work with mini-dumps for diagnostic purposes.

One or more of those members may provide additional comment and suggestions.

In the meantime, take a look in Reliability History/Monitor and Event Viewer.

Either one or both tools may be capturing some related error codes, warnings, or even informational events.

Start with Reliability History; much more user friendly and the time line format can reveal patterns.

Event Viewer requires more time and effort to navigate and understand.

To help:

How To - How to use Windows 10 Event Viewer | Tom's Hardware Forum (tomshardware.com)

See what, if anything, you can discover. Post accordingly.

 

[Gazza_1988]

Debuggers and mini-dumps have their purposes and there are some members here ( I, full disclosure, am not one of them) who regularly work with mini-dumps for diagnostic purposes.

One or more of those members may provide additional comment and suggestions.

In the meantime, take a look in Reliability History/Monitor and Event Viewer.

Either one or both tools may be capturing some related error codes, warnings, or even informational events.

Start with Reliability History; much more user friendly and the time line format can reveal patterns.

Event Viewer requires more time and effort to navigate and understand.

To help:

How To - How to use Windows 10 Event Viewer | Tom's Hardware Forum (tomshardware.com)

See what, if anything, you can discover. Post accordingly.

Hi Ralston,

Firstly, thank you for taking the time to respond.

I did what you mentioned and checked the Reliability History and seen something odd. When comparing the Critical Event timeline as compared with the Informational Event Timeline, the same informational event occurs at the same time of the crash/BSOD. The event is as per below

Microsoft GameInput Successful Application Reconfiguration.

Windows Installer reconfigured the product. Product Name: Microsoft GameInput. Product Version: 10.1.22621.3036. Product Language: 1033. Manufacturer: Microsoft Corporation. Reconfiguration success or error status: 0.

Yesterday, this event occurred 4 times and out of the 4, the PC crashed 3 of those.

I'll need to look into this event more. What it is and why its happening etc.

 

[Ralston18]

Good work!

Delve into Event Viewer as well.

Both tools (Reliability History and Event Viewer) support clicking any given entry for more details.

The details may or may not prove helpful. Specific error codes likely, but not always, a possible clue.

Take a close look at everthing being launched at start up or perhaps being triggered later on via Task Scheduler.

Objective being to discover what, if anything, may be attempting to reconfigure "Game Input".

Other possible actions:

Run the built-in Windows Troubleshooters. The troubleshooters may find and fix something.

Also run "sfc /scannow" and "dism".

FYI:

https://www.lifewire.com/how-to-use-sfc-scannow-to-repair-windows-system-files-2626161

How to use DISM command tool to repair Windows 10 image | Windows Central

 

[Gazza_1988]

Good work!

Delve into Event Viewer as well.

Both tools (Reliability History and Event Viewer) support clicking any given entry for more details.

The details may or may not prove helpful. Specific error codes likely, but not always, a possible clue.

Take a close look at everthing being launched at start up or perhaps being triggered later on via Task Scheduler.

Objective being to discover what, if anything, may be attempting to reconfigure "Game Input".

Other possible actions:

Run the built-in Windows Troubleshooters. The troubleshooters may find and fix something.

Also run "sfc /scannow" and "dism".

FYI:

https://www.lifewire.com/how-to-use-sfc-scannow-to-repair-windows-system-files-2626161

How to use DISM command tool to repair Windows 10 image | Windows Central

Hi Ralston,

Thanks again!

Okay, so, I made an attempt to look at the event viewer but I honestly have no idea what I'm looking at/for. Around the time of the crashes, there are multiple errors, warnings and information logs however none make any sense or appear to help in solving this puzzle. So backtracking to the original Reliability History results.

A quick use of Google appears to show the event ''Microsoft GameInput Successful Application Reconfiguration.'' has something to do with the Xbox or Gamebar applications. I do use these however, not at the time in which I have recently had crashes although as I understand this runs in the background. So, I have uninstalled these applications and I have crossed my fingers that this is the culprit. Although quite possibly the crash has a Domino effect on this application so may not be relevant at all.

I have also reached out to the Microsoft forums and supplied 3 recent crash dumps in the hope they can enlighten me.

I will of course look into the sfc and Windows repair tools and pray this burden is lifted. I will post any updates as and when I can.