CRITICAL_PROCESS_DIED (0xEF) BSOD during heavy GPU/VRAM load and Shared Memory allocation

Problem
I am experiencing recurring CRITICAL_PROCESS_DIED (Bug Check 0xEF / 239) BSODs. The crashes occur most frequently during heavy GPU and/or VRAM utilization, particularly when VRAM usage exceeds physical memory and begins utilizing shared system memory.

Environment & History
* System Age: Approximately 4 years old.
* Issue Duration: Approximately 18 months.
* System profile is completed with as much detail as possible.

What I tried
* Storage Testing:
* Temporarily replaced my primary Sabrent SSD with a borrowed 1TB SSD. The BSODs completely disappeared under the exact same workloads.
* Returned the borrowed drive, installed a spare 512GB SSD, and performed a clean Windows installation. The crashes returned.
* Reinstalled the original Sabrent SSD, performed another clean Windows installation, and added a new heatsink to improve SSD cooling. The issue persists.
* Memory Testing:
* Ran MemTest86 (multiple full passes completed approximately 6 months ago). No errors were detected.
* VRAM Testing:
* Ran FurMark's VRAM test with 16GB or 20GB memory allocation. This consistently triggers a crash after several minutes.
* Driver Testing:
* Tested both the latest NVIDIA drivers and an older release from mid-2024. The issue occurs regardless of the driver version.

Reproduction Steps
The most reliable way to trigger the crash is initiating a secondary GPU-related task while the GPU is already under heavy load:
1. Running a FurMark VRAM test at maximum VRAM utilization, then pressing the Windows key to open the Start menu or Search.
2. Opening and using applications like Discord or Task Manager during a FurMark VRAM test.
3. Opening browser tabs while gaming when VRAM usage is already high.

Actual Behavior
In some instances, applications like Discord (or other open windows) briefly become unresponsive while the rest of the system continues functioning normally. Shortly afterward, the system crashes with a CRITICAL_PROCESS_DIED BSOD.

Extra details
Given that the issue completely disappeared when using my brother's 1TB SSD but returned on both my original Sabrent SSD and the spare 512GB SSD (even after clean Windows installations), I am unsure if this points to a configuration/driver issue or something else entirely.

I can provide additional hardware details or logs as needed. Thank you for your time and assistance!

Please perform the following steps:




1) Turn off Windows fast startup:





2) Add WMIC:


DISM /Online /Add-Capability /CapabilityName:WMIC~~~~




3) Run Tuneup plus >post a share link







4) The BIOS Version/Date American Megatrends International, LLC. F11, 19/12/2566

Upgrade the BIOS: 5013 > 5031





5) Run Sea Tools Long generic test (all drives) > post images or share links





6) Run HD Sentinel (all drives) > post images or share links

Hard Disk Sentinel - HDD health and temperature monitoring
a) Overview
b) Temperature
c) SMART

@zbook

1) I turned off Windows fast startup
2) I added WMIC
3) I ran Tuneup plus, results here
4) I updated BIOS version to 5031
5) I Ran Sea Tools Long generic test on all drives, results: SSD, HDD
6) I ran HD Sentinel for all drives, here is a folder with the results

I could try removing the HDD until I find a replacement, as there is currently no important data stored on it. However, I'm not convinced it is the cause of the issue. When I was using the borrowed SSD, I experienced no crashes despite still having the HDD connected and using software that was installed on it at the time.

Update: I have transferred the data from the HDD to the SSD and have temporarily removed the hard drive from the system.

Nice progress.

Anton07 said:

@zbook

3) I ran Tuneup plus, results here

Click to expand...

results good

Anton07 said:

5) I Ran Sea Tools Long generic test on all drives, results: SSD, HDD

Click to expand...

results pass

Anton07 said:

6) I ran HD Sentinel for all drives, here is a folder with the results

I could try removing the HDD until I find a replacement, as there is currently no important data stored on it. However, I'm not convinced it is the cause of the issue.

Click to expand...

This drive ST3000DM001-1ER166 has problems per HDS: 464 bad sectors

Anton07 said:

Update: I have transferred the data from the HDD to the SSD and have temporarily removed the hard drive from the system.

Click to expand...

For any BSOD post a new V2 share link into the newest post.

If there are no new BSOD during 72 hrs then that will complete the troubleshooting.

I tested both a game and FurMark's 16GB VRAM stress test. In both cases, the system crashed with the same BSOD within a few minutes of starting the workload. You can view the most recent V2 Log Collector report here

Please let me know if there are any additional tests you would recommend, including tests for other hardware components or whether it would be worthwhile to swap the SSD again for troubleshooting purposes.

1) Please search for > zip > post a share link

LastWriteTime Size (MB) FullName
------------- --------- --------
6/30/2026 3:50:06 PM 3527.27 C:\WINDOWS\LiveKernelReports\WATCHDOG-20260630-1550.dmp



2) Run Memtest86+ for 8 or more passes > take pictures > post images or share links

Memtest86+ | The Open-Source Memory Testing Tool

Just 1 error is a test fail and testing can be aborted.

The more the passes the better the testing conditions.

It sometimes takes passes into the 20's to detect malfunctioning RAM.

The RAM can be tested all at one time or one at a time in the same DIMM.

Memtest86+ | The Open-Source Memory Testing Tool

MemTest86+ - Test RAM

1) Here is the zip file containing the .dmp file

2) Here are the results of Memtest86+:

Is the installation an insider build?

Run > post share links
reg query "HKLM\SOFTWARE\Microsoft\WindowsSelfHost\Applicability"
reg query "HKLM\SOFTWARE\Microsoft\WindowsSelfHost\UI\Selection"



If it is an insiders build then for testing purposes clean install Windows 10:

please have a look at this and see if increasing the max vram helps

i beleive the Windows kernel will be able to increase the vram to a max of (hex) 1024
best of luck Steve ..

@zbook

Here are the results of the two commands
It does not appear to me that I am running an Insider build

Here is also a screenshot of my Winver window

Please clean install Windows 10.