Question Repeated BSOD WHEA_UNCORRECTABLE_ERROR (124) on Device Driver Error ?

[niv13]

Hi! This is absolutely driving me crazy.

I'm running numerous video editing and emulators on my PC and recently the PC starts dropping BOSD bomb out of no where.

The only thing I can say is the GPU fan seems to go nuts before the BOSD happens.

The fault is very repeatable. I just have to open as much emulators (ie. BlueStack) as possible to summon the BOSD.

There wasn't such problem previously, not sure what happened.

Can anyone help?

I've posted the minidump file below


************* Preparing the environment for Debugger Extensions Gallery repositories **************
ExtensionRepository : Implicit
UseExperimentalFeatureForNugetShare : true
AllowNugetExeUpdate : true
NonInteractiveNuget : true
AllowNugetMSCredentialProviderInstall : true
AllowParallelInitializationOfLocalRepositories : true
EnableRedirectToChakraJsProvider : false

-- 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.032 seconds
----> Repository : UserExtensions, Enabled: true, Packages count: 0
----> Repository : LocalInstalled, Enabled: true, Packages count: 42

Microsoft (R) Windows Debugger Version 10.0.27704.1001 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\Minidump\102224-14656-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (16 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Kernel base = 0xfffff804`4a600000 PsLoadedModuleList = 0xfffff804`4b22a7c0
Debug session time: Tue Oct 22 21:33:59.191 2024 (UTC - 6:00)
System Uptime: 0 days 12:30:23.569
Loading Kernel Symbols
...............................................................
................................................................
................................................................
...............................................
Loading User Symbols

Loading unloaded module list
..................................................
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff804`4a9fe310 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:fffff88e`ccb573e0=0000000000000124
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: 0000000000000010, Device Driver Error
Arg2: ffffe30e2de09028, Address of the nt!_WHEA_ERROR_RECORD structure.
Arg3: ffffe30de78e7b5c
Arg4: ffffe30de798e1a0

Debugging Details:
------------------


KEY_VALUES_STRING: 1

Key : Analysis.CPU.mSec
Value: 2343

Key : Analysis.Elapsed.mSec
Value: 7860

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

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

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

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

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

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

Key : Analysis.Version.DbgEng
Value: 10.0.27704.1001

Key : Analysis.Version.Description
Value: 10.2408.27.01 amd64fre

Key : Analysis.Version.Ext
Value: 1.2408.27.1

Key : Bugcheck.Code.LegacyAPI
Value: 0x124

Key : Bugcheck.Code.TargetModel
Value: 0x124

Key : Failure.Bucket
Value: 0x124_16_GenuineIntel__UNKNOWN_IMAGE_GenuineIntel.sys

Key : Failure.Hash
Value: {37af9407-4a3e-0b08-acdd-dadffdc34c3c}

Key : WER.OS.Branch
Value: vb_release

Key : WER.OS.Version
Value: 10.0.19041.1


BUGCHECK_CODE: 124

BUGCHECK_P1: 10

BUGCHECK_P2: ffffe30e2de09028

BUGCHECK_P3: ffffe30de78e7b5c

BUGCHECK_P4: ffffe30de798e1a0

FILE_IN_CAB: 102224-14656-01.dmp

FAULTING_THREAD: ffffe30e12ecb640

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT: 1

PROCESS_NAME: System

STACK_TEXT:
fffff88e`ccb573d8 fffff804`4abbc91f : 00000000`00000124 00000000`00000010 ffffe30e`2de09028 ffffe30d`e78e7b5c : nt!KeBugCheckEx
fffff88e`ccb573e0 fffff804`4abbd389 : ffffe30e`2927a290 ffffe30e`2927a290 ffffe30d`e78e7b30 ffffe30e`22bf71b8 : nt!WheaReportHwError+0x4cf
fffff88e`ccb574b0 fffff804`4abbd4a5 : 00000000`00000000 00000000`00000062 ffffe30e`2927a290 00000000`00000000 : nt!WheaHwErrorReportSubmitDeviceDriver+0xe9
fffff88e`ccb574e0 fffff804`4e263791 : 00000000`00000000 fffff88e`ccb57700 ffffe30d`e798e1a0 ffffe30d`e79870ff : nt!WheaReportFatalHwErrorDeviceDriverEx+0xf5
fffff88e`ccb57540 fffff804`4e25cb70 : 00000000`00000000 ffffe30d`e798e1a0 ffffe30d`e78721a0 00000000`00000000 : storport!StorpWheaReportError+0x9d
fffff88e`ccb575d0 fffff804`4e22f0cc : fffff804`4e289000 00000000`00000062 00000000`00000000 fffff88e`ccb57970 : storport!StorpMarkDeviceFailed+0x358
fffff88e`ccb57860 fffff804`4e2eb57d : 00000000`00000100 ffffe30d`e7987020 00000000`00000000 00000000`00000000 : storport!StorPortNotification+0x91c
fffff88e`ccb57930 fffff804`4e2ee78e : ffffe30d`c1000002 00000000`00000000 ffffe30d`e7987020 00000000`00000003 : stornvme!ControllerReset+0x1a1
fffff88e`ccb579b0 fffff804`4e2ed6ef : ffffe30d`e7987020 ffffe30d`e798e050 ffffe30e`1cf15fb0 80000000`00002000 : stornvme!NVMeControllerReset+0x10a
fffff88e`ccb579e0 fffff804`4e25a246 : ffffe30e`1cf15fb0 ffffe30d`e798e050 ffffe30e`1dca8640 ffffe30d`e38e6cc0 : stornvme!NVMeControllerAsyncResetWorker+0x3f
fffff88e`ccb57a10 fffff804`4a943ea5 : ffffe30e`14c021b0 ffffe30e`14c021b0 ffffe30d`e798e050 fffff804`63f45480 : storport!StorPortWorkItemRoutine+0x46
fffff88e`ccb57a40 fffff804`4a822525 : ffffe30e`12ecb640 ffffe30e`12ecb640 fffff804`4a943d70 00000000`00000000 : nt!IopProcessWorkItem+0x135
fffff88e`ccb57ab0 fffff804`4a929905 : ffffe30e`12ecb640 00000000`00000080 ffffe30d`e38d7140 00000000`00000000 : nt!ExpWorkerThread+0x105
fffff88e`ccb57b50 fffff804`4aa07318 : ffff9b00`2e5c9180 ffffe30e`12ecb640 fffff804`4a9298b0 00000000`00000246 : nt!PspSystemThreadStartup+0x55
fffff88e`ccb57ba0 00000000`00000000 : fffff88e`ccb58000 fffff88e`ccb51000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28


MODULE_NAME: GenuineIntel

IMAGE_NAME: GenuineIntel.sys

STACK_COMMAND: .process /r /p 0xffffe30de38d7140; .thread 0xffffe30e12ecb640 ; kb

FAILURE_BUCKET_ID: 0x124_16_GenuineIntel__UNKNOWN_IMAGE_GenuineIntel.sys

OS_VERSION: 10.0.19041.1

BUILDLAB_STR: vb_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {37af9407-4a3e-0b08-acdd-dadffdc34c3c}

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

6: kd> lmvm GenuineIntel
Browse full module list
start end module name
6: kd> !blackboxbsd
Version: 0xb0
Product type: 1

Auto advanced boot: FALSE
Advanced boot menu timeout: 30
Last boot succeeded: TRUE
Last boot shutdown: FALSE
Sleep in progress: FALSE

Power button timestamp: 0x0
System running: TRUE
Connected standby in progress: FALSE
User shutdown in progress: FALSE
System shutdown in progress: FALSE
Sleep in progress: 0
Connected standby scenario instance id: 0
Connected standby entry reason: 0
Connected standby exit reason: 0
System sleep transitions to on: 0
Last reference time: 0x1db249396255fd9
2024-10-22T15:03:43.538Z
Last reference time checksum: 0x25b0e101
Last update boot id: 109

Boot attempt count: 1
Last boot checkpoint: TRUE
Checksum: 0x83
Last boot id: 109
Last successful shutdown boot id: 102
Last reported abnormal shutdown boot id: 108

Error info boot id: 0
Error info repeat count: 0
Error info other error count: 0
Error info code: 0
Error info status: 0x0

Power button last press time: 0x0
Power button cumulative press count: 0
Power button last press boot id: 0
Power button last power watchdog stage: 0
Power button watchdog armed: FALSE
Power button shutdown in progress: FALSE
Power button last release time: 0x0
Power button cumulative release count: 0
Power button last release boot id: 0
Power button error count: 0
Power button current connected standby phase: 0
Power button transition latest checkpoint id: 0
Power button transition latest checkpoint type: 0
Power button transition latest checkpoint sequence number: 0

Power transition Shutdown Device Type: 0
Power transition Setup In Progress: FALSE
Power transition OOBE In Progress: FALSE
Power transition Sleep Checkpoint Source: 0
Power transition Sleep Checkpoint: 0
Power transition Connected Standby Entry Reason Category: 0
Power transition Connected Standby Exit Reason Category: 0
Power transition Connected Standby Entry Scenario Instance Id: 0x0

Feature Configuration State : Uninitialized

 

[KingLoki]

A few things to try, as it could be quite a few different causes for this error.
Try software/drivers/damaged,corrupted files.

Open a Command Prompt (in Administrator Mode) and type the following commands & press "Enter" for each command to run each check.

1. "chkdsk /f c:" to check hard drive. (no quotes)
2. "sfc /scannow"
3. "DISM.exe /Online /Cleanup-image /Restorehealth"

If the checks don't find and repair the problem, then look at Device Manager, as it could be caused by corrupt/faulty/incorrect drivers for the system hardware/devices. Look to see if any yellow exclamation marks show on any devices in Device Manager.

Alternatively, it may be faulty memory(RAM), or even faulty hard drive, CPU etc. There are more tests if needed.
Try these possible fixes first and check back in to let us know. Cheers.

 

[Ralston18]

And also check Reliability History/Monitor and Event Viewer for any related error codes, warnings, or even informational events being captured just before or at the time of the BSODs.

 

[ubuysa]

From the dump, which indicates a device driver error, and which failed whilst accessing an NVMe storage drive, then focussing on the NVMe drive(s) in your rig would be the sensible first step.

Can you please upload to the cloud all the recent dumps that you have. Dump analysis is way more involved than just analyze -v.

Download the management tool provided by your SSD drive vendor, check the SMART data in there, perform a full diagnostics test on the drive, and look for driver and firmware updates for the drive using that tool.

If you use a third-party anti-virus product it's entirely possible that this may be the root cause (even though we don't see it in the dump). I would uninstall that product if I were you and see whether the problem remains.

Since it happens with Bluestacks started I would also enable Driver Verifier and see whether that catches a misbehaving driver when you start Bluestacks....

Driver Verifier subjects selected drivers (typically all third-party drivers) to extra tests and checks every time they are called. These extra checks are designed to uncover drivers that are misbehaving. If any selected driver fails any of the Driver Verifier tests/checks then Driver Verifier will BSOD. The resulting minidump should contain enough information for us to identify the flaky driver. It's thus essential to keep all minidumps created whilst Driver Verifier is enabled.

To enable Driver Verifier do the following:

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...

• Special Pool
• Force IRQL checking
• Pool Tracking
• Deadlock Detection
• Security Checks
• Miscellaneous Checks
• Power framework delay fuzzing
• DDI compliance checking

Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...

• Wdf01000.sys
• ndis.sys
• fltMgr.sys
• Storport.sys

These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running for 48 hours, use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing. The Driver Verifier generated BSODs are these...

• 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
• 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
• 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
• 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
• 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
• 0xE6: DRIVER_VERIFIER_DMA_VIOLATION

If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query. If drivers are listed then it's enabled, if no drivers are listed then it's not.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).

 

[johnbl]

here is another user with a similar bugcheck: (not fixed yet)

Question - getting this BSOD every week or 2 for months, nothing has worked please help !

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...

forums.tomshardware.com

note: if you have a kernel dump I will take a look at it. file is memory.dmp
at least I can see if it is the same problem I have been looking at. Or see what issues both dumps have in common.

 

[niv13]

A few things to try, as it could be quite a few different causes for this error.
Try software/drivers/damaged,corrupted files.

Open a Command Prompt (in Administrator Mode) and type the following commands & press "Enter" for each command to run each check.

1. "chkdsk /f c:" to check hard drive. (no quotes)
2. "sfc /scannow"
3. "DISM.exe /Online /Cleanup-image /Restorehealth"

If the checks don't find and repair the problem, then look at Device Manager, as it could be caused by corrupt/faulty/incorrect drivers for the system hardware/devices. Look to see if any yellow exclamation marks show on any devices in Device Manager.

Alternatively, it may be faulty memory(RAM), or even faulty hard drive, CPU etc. There are more tests if needed.
Try these possible fixes first and check back in to let us know. Cheers.

disc check is fine, no issue with scannow

device manager shows no "!" beside anything only the Bluetooth Peripheral Device has a "?"

 

[niv13]

And also check Reliability History/Monitor and Event Viewer for any related error codes, warnings, or even informational events being captured just before or at the time of the BSODs.

how exactly do I do this? Where exactly am I looking for in Event Viewer?

 

[niv13]

Posting all the BOSD crashes that I've been getting here via the Event Viewer Logs
https://drive.google.com/file/d/1cwrHr4u2JIwvMT81xNY335ya3ciSeRkj/view?usp=sharing

 

[niv13]

Posting Reliability History and the Technical Details
https://drive.google.com/file/d/1DBpfAUbSA8GHcTL7Oi-9JAmrm5AoaKOK/view?usp=sharing
https://drive.google.com/file/d/1xuxn7JEoEfEADiXYkoITS56H4ZR0oOsm/view?usp=sharing

 

[niv13]

From the dump, which indicates a device driver error, and which failed whilst accessing an NVMe storage drive, then focussing on the NVMe drive(s) in your rig would be the sensible first step.

Can you please upload to the cloud all the recent dumps that you have. Dump analysis is way more involved than just analyze -v.

Download the management tool provided by your SSD drive vendor, check the SMART data in there, perform a full diagnostics test on the drive, and look for driver and firmware updates for the drive using that tool.

If you use a third-party anti-virus product it's entirely possible that this may be the root cause (even though we don't see it in the dump). I would uninstall that product if I were you and see whether the problem remains.

Since it happens with Bluestacks started I would also enable Driver Verifier and see whether that catches a misbehaving driver when you start Bluestacks....

Driver Verifier subjects selected drivers (typically all third-party drivers) to extra tests and checks every time they are called. These extra checks are designed to uncover drivers that are misbehaving. If any selected driver fails any of the Driver Verifier tests/checks then Driver Verifier will BSOD. The resulting minidump should contain enough information for us to identify the flaky driver. It's thus essential to keep all minidumps created whilst Driver Verifier is enabled.

To enable Driver Verifier do the following:

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...

• Special Pool
• Force IRQL checking
• Pool Tracking
• Deadlock Detection
• Security Checks
• Miscellaneous Checks
• Power framework delay fuzzing
• DDI compliance checking

Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...

• Wdf01000.sys
• ndis.sys
• fltMgr.sys
• Storport.sys

These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running for 48 hours, use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing. The Driver Verifier generated BSODs are these...

• 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
• 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
• 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
• 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
• 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
• 0xE6: DRIVER_VERIFIER_DMA_VIOLATION

If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query. If drivers are listed then it's enabled, if no drivers are listed then it's not.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).

Uploading all my dump files into this Google Drive Cloud Folder: 5x Dump Files

https://drive.google.com/drive/folders/1lok-rdLG95kZ2GwR8quUOc7sdNxt-T6j?usp=sharing

This is a hefty list of actions, I will attempt to go through all of them. Please give me a bit more time to get through everything. Thank you!

 

[niv13]

I'm posting the latest crash dump file report in full here:


************* Preparing the environment for Debugger Extensions Gallery repositories **************
ExtensionRepository : Implicit
UseExperimentalFeatureForNugetShare : true
AllowNugetExeUpdate : true
NonInteractiveNuget : true
AllowNugetMSCredentialProviderInstall : true
AllowParallelInitializationOfLocalRepositories : true
EnableRedirectToChakraJsProvider : false

-- 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.063 seconds
----> Repository : UserExtensions, Enabled: true, Packages count: 0
----> Repository : LocalInstalled, Enabled: true, Packages count: 42

Microsoft (R) Windows Debugger Version 10.0.27725.1000 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Windows\MEMORY.DMP]
Kernel Bitmap Dump File: Kernel address space is available, User address space may not be available.


************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (16 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Edition build lab: 19041.1.amd64fre.vb_release.191206-1406
Kernel base = 0xfffff800`4a000000 PsLoadedModuleList = 0xfffff800`4ac2a7c0
Debug session time: Sun Oct 27 09:49:00.228 2024 (UTC - 6:00)
System Uptime: 0 days 7:13:53.116
Loading Kernel Symbols
...............................................................
................................................................
................................................................
.................................................
Loading User Symbols

Loading unloaded module list
..................................................
For analysis of this file, run !analyze -v
nt!KeBugCheckEx:
fffff800`4a3fe310 48894c2408 mov qword ptr [rsp+8],rcx ss:0018:ffff9003`ea8773e0=0000000000000124
0: 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: 0000000000000010, Device Driver Error
Arg2: ffffac06675f3028, Address of the nt!_WHEA_ERROR_RECORD structure.
Arg3: ffffac06245372cc
Arg4: ffffac06244a01a0

Debugging Details:
------------------

*** WARNING: Check Image - Checksum mismatch - Dump: 0xd94f, File: 0xcaa1 - C:\ProgramData\Dbg\sym\hal.dll\1A7BE8E96000\hal.dll

KEY_VALUES_STRING: 1

Key : Analysis.CPU.mSec
Value: 1250

Key : Analysis.Elapsed.mSec
Value: 2800

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

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

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

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

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

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

Key : Analysis.Version.DbgEng
Value: 10.0.27725.1000

Key : Analysis.Version.Description
Value: 10.2408.27.01 amd64fre

Key : Analysis.Version.Ext
Value: 1.2408.27.1

Key : Bugcheck.Code.KiBugCheckData
Value: 0x124

Key : Bugcheck.Code.LegacyAPI
Value: 0x124

Key : Bugcheck.Code.TargetModel
Value: 0x124

Key : Failure.Bucket
Value: 0x124_16_GenuineIntel__UNKNOWN_IMAGE_GenuineIntel.sys

Key : Failure.Hash
Value: {37af9407-4a3e-0b08-acdd-dadffdc34c3c}

Key : Hypervisor.Enlightenments.Value
Value: 0

Key : Hypervisor.Enlightenments.ValueHex
Value: 0

Key : Hypervisor.Flags.AnyHypervisorPresent
Value: 0

Key : Hypervisor.Flags.ApicEnlightened
Value: 0

Key : Hypervisor.Flags.ApicVirtualizationAvailable
Value: 1

Key : Hypervisor.Flags.AsyncMemoryHint
Value: 0

Key : Hypervisor.Flags.CoreSchedulerRequested
Value: 0

Key : Hypervisor.Flags.CpuManager
Value: 0

Key : Hypervisor.Flags.DeprecateAutoEoi
Value: 0

Key : Hypervisor.Flags.DynamicCpuDisabled
Value: 0

Key : Hypervisor.Flags.Epf
Value: 0

Key : Hypervisor.Flags.ExtendedProcessorMasks
Value: 0

Key : Hypervisor.Flags.HardwareMbecAvailable
Value: 1

Key : Hypervisor.Flags.MaxBankNumber
Value: 0

Key : Hypervisor.Flags.MemoryZeroingControl
Value: 0

Key : Hypervisor.Flags.NoExtendedRangeFlush
Value: 0

Key : Hypervisor.Flags.NoNonArchCoreSharing
Value: 0

Key : Hypervisor.Flags.Phase0InitDone
Value: 0

Key : Hypervisor.Flags.PowerSchedulerQos
Value: 0

Key : Hypervisor.Flags.RootScheduler
Value: 0

Key : Hypervisor.Flags.SynicAvailable
Value: 0

Key : Hypervisor.Flags.UseQpcBias
Value: 0

Key : Hypervisor.Flags.Value
Value: 16908288

Key : Hypervisor.Flags.ValueHex
Value: 1020000

Key : Hypervisor.Flags.VpAssistPage
Value: 0

Key : Hypervisor.Flags.VsmAvailable
Value: 0

Key : Hypervisor.RootFlags.AccessStats
Value: 0

Key : Hypervisor.RootFlags.CrashdumpEnlightened
Value: 0

Key : Hypervisor.RootFlags.CreateVirtualProcessor
Value: 0

Key : Hypervisor.RootFlags.DisableHyperthreading
Value: 0

Key : Hypervisor.RootFlags.HostTimelineSync
Value: 0

Key : Hypervisor.RootFlags.HypervisorDebuggingEnabled
Value: 0

Key : Hypervisor.RootFlags.IsHyperV
Value: 0

Key : Hypervisor.RootFlags.LivedumpEnlightened
Value: 0

Key : Hypervisor.RootFlags.MapDeviceInterrupt
Value: 0

Key : Hypervisor.RootFlags.MceEnlightened
Value: 0

Key : Hypervisor.RootFlags.Nested
Value: 0

Key : Hypervisor.RootFlags.StartLogicalProcessor
Value: 0

Key : Hypervisor.RootFlags.Value
Value: 0

Key : Hypervisor.RootFlags.ValueHex
Value: 0

Key : SecureKernel.HalpHvciEnabled
Value: 0

Key : WER.OS.Branch
Value: vb_release

Key : WER.OS.Version
Value: 10.0.19041.1


BUGCHECK_CODE: 124

BUGCHECK_P1: 10

BUGCHECK_P2: ffffac06675f3028

BUGCHECK_P3: ffffac06245372cc

BUGCHECK_P4: ffffac06244a01a0

FILE_IN_CAB: MEMORY.DMP

FAULTING_THREAD: ffffac06560f1040

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

PROCESS_NAME: System

STACK_TEXT:
ffff9003`ea8773d8 fffff800`4a5bc91f : 00000000`00000124 00000000`00000010 ffffac06`675f3028 ffffac06`245372cc : nt!KeBugCheckEx
ffff9003`ea8773e0 fffff800`4a5bd389 : ffffac06`6875ba10 ffffac06`6875ba10 ffffac06`245372a0 ffffac06`67b3b128 : nt!WheaReportHwError+0x4cf
ffff9003`ea8774b0 fffff800`4a5bd4a5 : 00000000`00000000 00000000`00000062 ffffac06`6875ba10 00000000`00000000 : nt!WheaHwErrorReportSubmitDeviceDriver+0xe9
ffff9003`ea8774e0 fffff800`4d663791 : 00000000`00000000 ffff9003`ea877700 ffffac06`244a01a0 ffffac06`244990ff : nt!WheaReportFatalHwErrorDeviceDriverEx+0xf5
ffff9003`ea877540 fffff800`4d65cb70 : 00000000`00000000 ffffac06`244a01a0 ffffac06`245531a0 00000000`00000000 : storport!StorpWheaReportError+0x9d
ffff9003`ea8775d0 fffff800`4d62f0cc : fffff800`4d689000 00000000`00000062 00000000`00000000 ffff9003`ea877970 : storport!StorpMarkDeviceFailed+0x358
ffff9003`ea877860 fffff800`4d6eb57d : 00000000`00000300 ffffac06`24499020 00000000`00000000 00000000`00000000 : storport!StorPortNotification+0x91c
ffff9003`ea877930 fffff800`4d6ee78e : ffffac06`c1000002 00000000`00000000 ffffac06`24499020 00000000`00000003 : stornvme!ControllerReset+0x1a1
ffff9003`ea8779b0 fffff800`4d6ed6ef : ffffac06`24499020 ffffac06`244a0050 ffffac06`62202280 80000000`00002000 : stornvme!NVMeControllerReset+0x10a
ffff9003`ea8779e0 fffff800`4d65a246 : ffffac06`62202280 ffffac06`244a0050 ffffac06`56621040 ffffac06`214a8c80 : stornvme!NVMeControllerAsyncResetWorker+0x3f
ffff9003`ea877a10 fffff800`4a343ea5 : ffffac06`6553fa30 ffffac06`6553fa30 ffffac06`244a0050 ffffac06`4e4d1080 : storport!StorPortWorkItemRoutine+0x46
ffff9003`ea877a40 fffff800`4a222525 : ffffac06`560f1040 ffffac06`560f1040 fffff800`4a343d70 ffffac06`00000000 : nt!IopProcessWorkItem+0x135
ffff9003`ea877ab0 fffff800`4a329905 : ffffac06`560f1040 00000000`00000080 ffffac06`2149c140 fffff800`4a25cb58 : nt!ExpWorkerThread+0x105
ffff9003`ea877b50 fffff800`4a407318 : ffffd381`92a55180 ffffac06`560f1040 fffff800`4a3298b0 00000000`00000000 : nt!PspSystemThreadStartup+0x55
ffff9003`ea877ba0 00000000`00000000 : ffff9003`ea878000 ffff9003`ea871000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28


MODULE_NAME: GenuineIntel

IMAGE_NAME: GenuineIntel.sys

STACK_COMMAND: .process /r /p 0xffffac062149c140; .thread 0xffffac06560f1040 ; kb

FAILURE_BUCKET_ID: 0x124_16_GenuineIntel__UNKNOWN_IMAGE_GenuineIntel.sys

OS_VERSION: 10.0.19041.1

BUILDLAB_STR: vb_release

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {37af9407-4a3e-0b08-acdd-dadffdc34c3c}

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

 

[niv13]

here is another user with a similar bugcheck: (not fixed yet)

Question - getting this BSOD every week or 2 for months, nothing has worked please help !

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...

forums.tomshardware.com

note: if you have a kernel dump I will take a look at it. file is memory.dmp
at least I can see if it is the same problem I have been looking at. Or see what issues both dumps have in common.

the file itself is 6.5GB big is this a normal size for such file?

I'm uploading it right now to my google drive and can take a while as I don't have a fast internet

 

[johnbl]

the file itself is 6.5GB big is this a normal size for such file?

I'm uploading it right now to my google drive and can take a while as I don't have a fast internet

yes, but it can be compressed. or there are ways to remove things from memory before the kernel memory dump is made.
ie use rammap64.exe from Microsoft and clear the standby list. Will make a smaller kernel dump.

 

[johnbl]

the file itself is 6.5GB big is this a normal size for such file?

I'm uploading it right now to my google drive and can take a while as I don't have a fast internet

just looked at a minidump.
you have
cbfsconnect2017.sys Tue Jun 28 09:42:00 2022
CBFS Connect is a software that allows developers to create virtual file systems and disks directly in their applications without writing device drivers.

ssdevfactory.sys Thu Mar 2 12:22:11 2023 (check for update)

it might be making a mistake.
the kernel dump was not there yet. I will check again.
debugger thinks all of your windows files have been modified. some are clearly modified, but all have check sum mismatches..

the kernel dump might have logs that are useful

note: in the mini dump I see a bunch of issues but I think they are unrelated to the problem. (controller not responding.)
I kind of expect the problem to be a windows bug having to do with a update. I am not sure how windows update will handle all of your modified windows files. I can figure out more from the kernel dump.

 

[niv13]

just looked at a minidump.
you have
cbfsconnect2017.sys Tue Jun 28 09:42:00 2022
CBFS Connect is a software that allows developers to create virtual file systems and disks directly in their applications without writing device drivers.

it might be making a mistake.
the kernel dump was not there yet. I will check again.
debugger thinks all of your windows files have been modified. some are clearly modified, but all have check sum mismatches..

the kernel dump might have logs that are useful

I'm not sure if I'm doing this correctly, is this the kernel dump that you are looking for?

https://drive.google.com/file/d/1gftw2WIYYRXq1sMlDkH4-HioUG-Q8ys6/view?usp=sharing

The MEMORY.DMP file has just finished uploading too:

https://drive.google.com/file/d/1O99buULGV8RZGsRrswSqhxxgzZ5B_Rls/view?usp=sharing

 

[johnbl]

I'm not sure if I'm doing this correctly, is this the kernel dump that you are looking for?

https://drive.google.com/file/d/1gftw2WIYYRXq1sMlDkH4-HioUG-Q8ys6/view?usp=sharing

The MEMORY.DMP file has just finished uploading too:

https://drive.google.com/file/d/1O99buULGV8RZGsRrswSqhxxgzZ5B_Rls/view?usp=sharing

not shared for public access

 

[niv13]

not shared for public access

My apologies, I didn't check the permission for one of the files.

Should be okay now

These are my NVME devices if it may help
Samsung SSD 970 EVO Plus 2TB
- Serial Number S6S2NS0W216486J
- Firmware 4B2QEXM7 (latest)
Samsung SSD 970 EVO Plus 2TB
- Serial Number S6S2NS0W219840T
- Firmware 4B2QEXM7 (latest)
Samsung SSD 980 Pro 500GB
- Serial Number S5NYNG0R911569N
- Firmware 5B2QGXA7 (latest)

 

[johnbl]

looks like some service running under svchost.exe made some calls to the filesystem to make some file. it passed through a filter and various components but when it got to the system cache manager the function faulted. This left the lock and everything else could not access the drive.
( BlueStacksServices.exe) Contention Count = 255905

brave browser is running a very high thread count (hundreds)
I will add some more notes: as i read info.

My guess is the system was writing to a block on the electronic storage, the block failed its write endurance and the drive firmware needed to move the block to another good block and it did not happen in time and the proper signal never told windows it was completed)

here is what I would do:
1. turn off system virtual memory reboot into bios and leave the machine powered on but in the bios screen for a hour or so. after 5 minutes of idle the drive firmware should start repairs.

2. boot windows and turn virtual memory back on. you might put the pagefile.sys on a secondary non boot drive. if you still get the bug, I would turn off virtual memory and windows will make a pagefile.sys in RAM and you should not hit this issue.

it looked like when the memory manager tried to access the file, it looked in the cache manager and the cache manager tried to look in the pagefile for the info and faulted. it could be some filter driver that is being paged to disk. I expect it to be related drive firmware getting starved out and not running fast enough. (blocks fail pretty often and get swapped with new blocks on the drive , it makes the size of the drive kind of shrink over time as blocks are marked bad)

normally, a bad block can still be read, just not written to, so the process should work.
the fault in the windows cache manager is what screwed up everything.

normally, you would update the firmware, the bios, the chipset drivers and hope for a fix.
(update anything related to the drive or the drive controller, also look for windows special updates for your machine. )
then make sure the drive firmware garbage collection is run ( boot into bios)

you might also google " how to have windows delete your pagefile.sys on reboot"
and make the registry changes and reboot. this will delete the pagefile for you and it can delay the problem. (workaround rather than a fix)

make sure windows error reporting is turned on. this will send your minidumps to Microsoft so they can make fixes or send you a fix via windows update if there is a known fix)
they might not look at your case because of all the modified windows files. I think the modifications are unrelated to the problem since I see the problem on two other systems that do not have the same modifications or programs running. your system had a huge number of threads running it might prevent the drive from going idle which would prevent the drive firmware running.

 

[johnbl]

I would also download and run Microsoft rammap64.exe find the empty menu item and run each of the menu items once. mainly to clear standby memory.



PolyPop-Setup-1.0.293.0 was running you might complete and exit the program.
kernel allocations failed but you had plenty of pagefile space.

drive controller:

Samsung Electronics Co Ltd

144d

NVMe SSD Controller PM9A1/PM9A3/980PRO

a80a

you might be able to tell window control panel device manager not to let this device sleep.
it indicates that it can wake from d3 sleep. if you don't let it sleep its firmware will run 5 mins after the system goes idle. it could prevent the problem (maybe)

maybe the default sleep state was changed and exposed this problem.

all of the storage controller drivers are running except this one is at d3 sleep
iaStorVD I think it is an intel raid controller driver.
iaStorVD.sys Thu Aug 25 04:53:02 2022
(i would not expect this driver to be in a deep sleep update it from intel)
i think it is related to intel vdm controller setting bios with a bios update you need to update the driver iaStorVD.sys Thu Aug 25 04:53:02 2022 to a version that matches the bios version.
(from motherboard vendor or directly from intel)
try the intel driver update utility:
https://www.intel.com/content/www/us/en/support/detect.html
and see if it picks up the update.

 

[johnbl]

on 9/30/2024 there were a bunch of updates for your motherboard.
bios update, usb firmware update, and cpu patch update
then pick up the chipset drivers update and I think it will have the fix for your problem with the old intel rapid storage driver (not waking)
You have to pick up all the firmware/bios updates then apply the chipset driver and sata driver update after windows boots again. I would pickup all the driver updates but do not install the
Armoury Crate & Aura Creator Installer (just causes a bunch of issues)

https://www.asus.com/motherboards-c...p-d4/helpdesk_bios?model2Name=PRIME-Z690-P-D4

looks like there was a bug in the old intel driver involving how it processed bad blocks.
bug number 22011073918
the bug can result in "silent loss of data"
I did not see a D3 sleep failure in the fix list (or the current buglist, but it might be in a old buglist)

 

[niv13]

here is what I would do:
1. turn off system virtual memory reboot into bios and leave the machine powered on but in the bios screen for a hour or so. after 5 minutes of idle the drive firmware should start repairs.

2. boot windows and turn virtual memory back on. you might put the pagefile.sys on a secondary non boot drive. if you still get the bug, I would turn off virtual memory and windows will make a pagefile.sys in RAM and you should not hit this issue.

I've done this and realized that:
1) I don't even have virtual memory turned on in the first place so there's no pagefile.sys
2) Is it possible that I'm just not having sufficient RAM in the first place?

I would also download and run Microsoft rammap64.exe find the empty menu item and run each of the menu items once. mainly to clear standby memory.

okay I've done this

drive controller:

Samsung Electronics Co Ltd

144d

NVMe SSD Controller PM9A1/PM9A3/980PRO

a80a

you might be able to tell window control panel device manager not to let this device sleep.
it indicates that it can wake from d3 sleep. if you don't let it sleep its firmware will run 5 mins after the system goes idle. it could prevent the problem (maybe)

I'm not sure how I can tell it to never go to sleep, do you have a guide I can foolow?

try the intel driver update utility:
https://www.intel.com/content/www/us/en/support/detect.html
and see if it picks up the update.

Thank you for sending me that update utility, I never knew that I had out of date intel drivers. I assumed that windows update was usually good enough to pick up out of date drivers (I guess not anymore)

Only 2 drivers were updated from this:
- Wi-Fi package drivers 23.80.1 for the Intel® Wi-Fi 7/Wi-Fi 6E/Wi-Fi 6 and Intel® 9000 series Wireless Adapters Version:23.80.1.3 Release date: October 1, 2024
- Intel® Wireless Bluetooth® version 23.70.3 Driver version varies depending on the wireless adapter installed. Version: 23.80.0.3 Release date: October 2, 2024

You have to pick up all the firmware/bios updates then apply the chipset driver and sata driver update after windows boots again. I would pickup all the driver updates but do not install the

Once again, thank you for checking for newer available drivers. I have grabbed the newer drivers on the support page (BIOS included) and updated.

LATEST UDPATE
- BOSD is less frequent than before, but now triggers even without the use of BlueStack
- The previous BOSD was caused by launching WARFRAME

Additionally, I went into Power Options to change the Plan Settings such that I don't allow anything to go into idle-sleep state. I don't quite know what is "D3 Sleep", is this how you disable it?

As per usual, the minidump file is here:
https://drive.google.com/file/d/1USL2_IaifGlFGtaA2kDvBkHOrpOVuKNw/view?usp=sharing

Any other file I should upload?

 

[johnbl]

I've done this and realized that:
1) I don't even have virtual memory turned on in the first place so there's no pagefile.sys
2) Is it possible that I'm just not having sufficient RAM in the first place?


okay I've done this


I'm not sure how I can tell it to never go to sleep, do you have a guide I can foolow?


Thank you for sending me that update utility, I never knew that I had out of date intel drivers. I assumed that windows update was usually good enough to pick up out of date drivers (I guess not anymore)

Only 2 drivers were updated from this:
- Wi-Fi package drivers 23.80.1 for the Intel® Wi-Fi 7/Wi-Fi 6E/Wi-Fi 6 and Intel® 9000 series Wireless Adapters Version:23.80.1.3 Release date: October 1, 2024
- Intel® Wireless Bluetooth® version 23.70.3 Driver version varies depending on the wireless adapter installed. Version: 23.80.0.3 Release date: October 2, 2024


Once again, thank you for checking for newer available drivers. I have grabbed the newer drivers on the support page (BIOS included) and updated.

LATEST UDPATE
- BOSD is less frequent than before, but now triggers even without the use of BlueStack
- The previous BOSD was caused by launching WARFRAME

Additionally, I went into Power Options to change the Plan Settings such that I don't allow anything to go into idle-sleep state. I don't quite know what is "D3 Sleep", is this how you disable it?

As per usual, the minidump file is here:
https://drive.google.com/file/d/1USL2_IaifGlFGtaA2kDvBkHOrpOVuKNw/view?usp=sharing

Any other file I should upload?

windows has 3 sleep s0,s1,s2 but devices also have sleep levels d0,d1,d3 and d3 has two levels d3 hot, d3 cold.
your outdated intel driver indicated it was in d3 while all of the actual drives indicated d0
0 indicates not asleep (fully awake) while level 3 is a very low power mode or no power mode.
sometimes in old drivers these low power mode drivers never get tested and are off by default. Later after a year or two Microsoft turns the function on by default and a bunch of drivers fail.
I am hoping the updated intel driver fixes the problem. we just have to fix anything you can until you find the actual problem that causes the bugcheck.
info on device power states:
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/device-power-states

 

[johnbl]

the minidump looks like the same bugcheck.
bios was updated ok:
BIOS Version 3410
BIOS Starting Address Segment f000
BIOS Release Date 09/27/2024

the intel driver has been updated:
iaStorVD.sys Sun Jul 21 23:36:10 2024
============
problem: minidumps do not include the proper info to debug this problem. You have to provide a kernel dump (memory.dmp) file
==========
problem: many of your core windows files have been modified, some program has removed the checksum from the files so that they can not be checked for modifications.
normally you would run cmd.exe as an admin and fix the file by running
sfc.exe /scannow
dism.exe /online /cleanup-image /restorehealth
and turn off the system pagefile.sys and turn it back on to dump the saved memory image on disk.
then reboot. you had a lot of software running. I do not know if one of your programs need the changes but these type of changes are not really allowed now. it was pretty common in windows 7 and earlier. now it is assumed that malware has made the modifications.
most people will not debug with the modified windows core files installed. often modifications also block windows updates at the same time and run a program in the task scheduler to reinstall the changes right after you fix them.

you also have various older drivers that could be causing the problem:
I can give you a list of some: (google each driver, find the software and try to update, check the older ones first)
(note: msio64.sys is a common malware attack point)

NDivert.sys Mon Jun 27 23:48:03 2022
MsIo64.sys Wed Apr 5 18:54:11 2023
wireguard.sys Tue Oct 12 09:09:12 2021
RzCommon.sys Wed Aug 3 03:34:16 2022
RzDev_00b2.sys Thu May 19 21:09:42 2022
nvvhci.sys Fri Apr 22 04:37:06 2022
this nvidia file is 2 years older than all of your other nvidia files
see https://forums.tomshardware.com/threads/driver-power-state-failure-bsod-upon-cold-boot.3782983/
it is the nvidia usb driver for the usb built into the GPU card. use ddu to remove and reinstall the current version. USB connects directly to the PCI/e bus now and could cause this bug.
(this should be your next fix attempt)

SteamStreamingMicrophone.sys Fri Jul 28 08:33:15 2017
SteamStreamingSpeakers.sys Thu Jul 20 17:56:15 2017
iVCam.sys Mon Dec 5 23:42:50 2022
rt640x64.sys Tue Jun 14 23:03:01 2022
https://www.realtek.com/Download/List?cate_id=584

ssdevfactory.sys Thu Mar 2 12:22:11 2023
ovpn-dco.sys Tue Sep 4 04:29:25 2018
nordlwf.sys Tue Jul 7 23:53:44 2020

after you get as many things cleaned up as you can, the next step is to run the dism command
and clean up the windows files. (it will break anything that needs the modifications)
after the windows files are fixed you would then turn on verifier flags and that will cause a bugcheck if a driver violates the current driver rules. often with many 3rd party drivers you system will bugcheck during the boot up process so you need to know how to get into safe mode to turn off verifier by running the command
verifier.exe /reset
while in safe mode, then you can boot and get the memory dump file to look at.

note: you only have a few windows core files that are not modified.
it could be something broken in how the minidump was saved but many of the core files have had the checksum actually removed. most just have the wrong checksums for the build version.
Ie Microsoft debugger finds the correct file and checks the one on the Microsoft server and the data from your memory dump and they have the same internal version number but the code has been changed. I can see if there is a pattern of changes.

 

[johnbl]

your cpu came out in late 2021
you should make sure you have applied the intel ME patch.
it should be here just under the bios update:
https://www.asus.com/motherboards-c...p-d4/helpdesk_bios?model2Name=PRIME-Z690-P-D4

(update the intel ME, updates a processor inside the CPU chip)
and update the firmware for your

USB PD controller FW update
Version -
2.18 MB
2021/11/24
(in case you have not done so)

note: cpu reports it is running at a strange speed. bios reports a different speed
3686MHz reported for cpu
4600MHz reported by bios
strange speed can mean incorrect voltage table, or throttling of cpu because of heat
voltage table is just a lookup for converting voltage to clock frequency. These are used to synchronize data flowing thru the various levels of cpu cache. wrong voltages lead to data collisions/ corruptions in cache and internal cpu errors. I generally suspect something when I see a speed that does not end with the last two digits of 00. Ie 3600Mhz might be ok, 3686 is unexpected and I would want to know why you have 86 extra Hz reported.



note: the bios does some updates, the intel me update should be also updated, as well as the the firmware for the USB controller.
after windows loads it will try to load
this file mcupdate_GenuineIntel.dll to do another level of patches for people that did not do the bios and cpu firmware update. (not sure what happens if you do the bios update and skip the cpu firmware update. )

more info:
4: kd> lmDvmmcupdate_GenuineIntel
Browse full module list
start end module name
fffff802`69670000 fffff802`698ff000 mcupdate_GenuineIntel (deferred)
Mapped memory image file: C:\ProgramData\Dbg\sym\mcupdate_GenuineIntel.dll\9FB1DE4628f000\mcupdate_GenuineIntel.dll
Image path: \SystemRoot\system32\mcupdate_GenuineIntel.dll
Image name: mcupdate_GenuineIntel.dll
Browse all global symbols functions data Symbol Reload
Image was built with /Brepro flag.
Timestamp: 9FB1DE46 (This is a reproducible build file hash, not a timestamp)
CheckSum: 0028C60B
ImageSize: 0028F000
File version: 10.0.19041.1030
Product version: 10.0.19041.1030
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 3.A Driver
File date: 00000000.00000000
Translations: 0409.04b0
Information from resource tables:
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: mcupdate.dll
OriginalFilename: mcupdate_GenuineIntel.dll
ProductVersion: 10.0.19041.1030
FileVersion: 10.0.19041.1030 (WinBuild.160101.0800)
FileDescription: Intel Microcode Update Library
LegalCopyright: © Microsoft Corporation. All rights reserved.
4: kd> !sysinfo cpuinfo
[CPU Information]
~MHz = REG_DWORD 3686
Component Information = REG_BINARY 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
Configuration Data = REG_FULL_RESOURCE_DESCRIPTOR ff,ff,ff,ff,ff,ff,ff,ff,0,0,0,0,0,0,0,0
Identifier = REG_SZ Intel64 Family 6 Model 151 Stepping 2
ProcessorNameString = REG_SZ 12th Gen Intel(R) Core(TM) i5-12600K
Update Status = REG_DWORD 2
VendorIdentifier = REG_SZ GenuineIntel
MSR8B = REG_QWORD 3500000000
4: kd> !sysinfo cpumicrocode
Initial Microcode Version: 00000035:00000000
Cached Microcode Version: 00000035:00000000
Processor Family: 06
Processor Model: 97
Processor Stepping: 02

 

[johnbl]

i think this is the intel csme detection tool to check if you need the ME firmware update:

https://www.intel.com/content/www/u...ine-version-detection-tool-intel-csmevdt.html