Daily Kernel-Power Event 41 & WHEA-Logger Event 17 Shuts Down HP Desktop After August Update

Question

Daily Kernel-Power Event 41 & WHEA-Logger Event 17 Shuts Down HP Desktop After August Update

Deborah Moyer 0

Hello,

I am seeking advanced engineering assistance for a persistent, severe kernel-power crash cycle on my system ([Moderator Note: Personal Info Removed] / Motherboard SSID 89B5 / Intel i7-12700F / Windows 11).

Ever since installing the August Windows Security Update, the computer experiences sudden, unexpected physical power cuts/crashes, a number of times directly after a windows update is installed (even when it says it's successful). This happens on a consistent daily cycle (occurring between 9:30 PM and 9:42 PM local time), alongside occasional daytime crashes with rotating Bugcheck codes (including 0x13a Kernel Mode Heap Corruption and 0xd1 Driver IRQL Not Less or Equal).

One example of a sequence in Event Viewer right before a power cut shows:

8:47 PM: Background installation components (like .NET frameworks) successfully finish.
9:08 PM: A critical WHEA-Logger (Event 17) error fires, reporting a corrected hardware error on the PCI Express Root Port.
9:17 PM: The system instantly loses physical power (subsequently logged as Kernel-Power Event 41 and volmgr Event 162 upon manual reboot).

Comprehensive Troubleshooting Already Completed:

Hardware Verification: Ran the full suite of HP UEFI Hardware Diagnostics (System Board, Processor, Hard Drive, RAM, and Thermal/Fan Speed tests). Everything passed 100% with no errors. The physical cooling vents have also been completely cleaned.
Firmware Updates: Successfully updated the Motherboard BIOS to the latest version and freshly updated the HP Fan Control Service and network drivers.
OS Repair: Performed a clean Windows Installation Repair using a fresh ISO file (keeping personal files), which rebuilt the core system files, but the kernel-level memory/power instability persists.
Current Adjustments: I have temporarily disabled Windows regular maintenance via the registry (MaintenanceDisabled set to 1) and turned PCI Express Link State Power Management to OFF in advanced power options to try and prevent the PCIe power state shifts from tripping the motherboard.

Because a full software rebuild and verified healthy physical hardware have not resolved this, this appears to be a direct kernel-level conflict between recent Windows Update power-state protocols and the PCIe root port firmware.

I need assistance from an engineer who can help analyze my system's Minidump logs to isolate the exact driver or memory address mismatch triggered by the August patch.

Thank you!

Deborah Moyer 0 Reputation points

2026-09-15T00:05:35.3366667+00:00
Thank you for the automated guidance. Every single one of these recommended steps has already been thoroughly completed and documented on this machine.

The issue started exactly after the August Update: This system had zero power issues until the August Security Update. Since then, it hits unexpected power drops on a daily cycle, alongside random daytime blue screens.

Every nightly crash is directly preceded by an active Update install: Looking at my saved Event Viewer logs, at 8:48 PM Windows successfully logs Event 19 installing update components (like .NET frameworks). Shortly after, at 9:08 PM, a critical WHEA-Logger Event 17 fires on the PCI Express Root Port. Minutes later, the system suffers a total power drop.

Hardware is verified 100% healthy: Full factory HP UEFI Diagnostics (RAM, CPU, Motherboard, and Thermal/Fan tests) have been run and passed with no errors. The physical tower has also been thoroughly cleaned of dust, and the Intel Overclock driver is disabled.

OS Repair has been completed: A clean Windows repair installation using a fresh ISO file was already performed, but the rotating bugchecks (0x13a and 0xd1) continue to happen.

The standard troubleshooting guides are not working because this is an active driver/firmware collision triggered by the update engine. I need an engineer to review the actual saved Minidump files to isolate which driver or kernel component is causing this PCIe power-state collapse right after an update runs.

2 answers

Your answer

Deborah Moyer 0 Reputation points

2026-09-15T00:05:35.3366667+00:00

Thank you for the automated guidance. Every single one of these recommended steps has already been thoroughly completed and documented on this machine.

The issue started exactly after the August Update: This system had zero power issues until the August Security Update. Since then, it hits unexpected power drops on a daily cycle, alongside random daytime blue screens.

Every nightly crash is directly preceded by an active Update install: Looking at my saved Event Viewer logs, at 8:48 PM Windows successfully logs Event 19 installing update components (like .NET frameworks). Shortly after, at 9:08 PM, a critical WHEA-Logger Event 17 fires on the PCI Express Root Port. Minutes later, the system suffers a total power drop.

Hardware is verified 100% healthy: Full factory HP UEFI Diagnostics (RAM, CPU, Motherboard, and Thermal/Fan tests) have been run and passed with no errors. The physical tower has also been thoroughly cleaned of dust, and the Intel Overclock driver is disabled.

OS Repair has been completed: A clean Windows repair installation using a fresh ISO file was already performed, but the rotating bugchecks (0x13a and 0xd1) continue to happen.

The standard troubleshooting guides are not working because this is an active driver/firmware collision triggered by the update engine. I need an engineer to review the actual saved Minidump files to isolate which driver or kernel component is causing this PCIe power-state collapse right after an update runs.

Answer 1

Event ID 41 does not identify the root cause by itself. It only confirms Windows did not shut down cleanly. For unexpected reboots, the useful pattern is to correlate Event IDs 41, 1001, 6008, 1074, and 7045 in Event Viewer to determine whether the restart was caused by a bugcheck, update activity, software installation, or a true power loss.

Given the reported pattern:

Check whether Event ID 1001 exists near each 9:30 PM–9:42 PM crash.
- If Event ID 1001 is present, the system rebooted from a bugcheck and Windows may have saved a dump in C:\Windows\MEMORY.DMP.
- If Event ID 1001 is absent and Event ID 41 is present, that points more strongly to an unexpected shutdown, hang, or power interruption.
Check whether Event ID 1074 appears before the reboot window.
- Event ID 1074 indicates an application, update, or user action initiated a restart.
- If there is no 1074 entry, that supports the case that the reboot was unexpected rather than a normal update-driven restart.
Check whether Event ID 6008 is logged.
- Event ID 6008 confirms the previous shutdown was unexpected.
- Use the timestamp from 6008 to inspect both System and Application logs for suspicious events immediately before the shutdown.
Review Event ID 7045 around the first occurrence of the issue.
- Event ID 7045 shows a service was installed.
- The documented guidance is to compare reboot history with recent driver, application, or OS update activity, especially if unexpected reboots started shortly after a new driver or update appeared.
If Event ID 41 shows BugcheckCode = 0, treat it as a Scenario 3 case.
- Microsoft documents that when Event ID 41 is missing useful bugcheck data or all values are zero, Windows may have been unable to write the error to disk before shutdown.
- This can indicate a power interruption, an unresponsive system, or shutdown happening too quickly for Windows to record the stop information.
Check for volmgr Event ID 46 if dump creation is failing.
- Microsoft documents that volmgr Event ID 46: “Crash dump initialization failed!” can occur when the system starts without a configured dump file.
- The default dump file is the pagefile, so pagefile configuration should be checked if dump generation is failing.
If a stop code appears on screen but Event ID 41 does not capture it, disable automatic restart.
- Go to My Computer > Properties > Advanced system settings > Advanced.
- Under Startup and Recovery, select Settings.
- Clear Automatically restart.
- This allows the stop code to remain visible instead of immediately rebooting.
Because the crashes are sudden physical power-offs, follow the hardware isolation steps Microsoft lists for this scenario:
1. Disable any overclocking and verify the system runs at the correct speed.
2. Check memory health and configuration, including that all memory runs at the same speed and is configured correctly.
3. Check the power supply capacity and stability. Microsoft specifically notes Event ID 41 with zeroed values can indicate an underpowered or faulty power supply, or interrupted power.
4. Check for overheating.
5. If this is a VM, consider heartbeat-related restarts, but that does not apply to a physical HP desktop.

For the specific request to isolate a driver from minidumps: the available guidance supports using Event ID 1001 to confirm whether a bugcheck dump was written and using the reboot/event history to correlate the first failures with recent driver or update changes. It does not provide a dump-analysis procedure or identify a specific August update, PCIe root port driver, or memory address mismatch.

References:

Answer 2

Clary-N 16,020 Microsoft External Staff Moderator

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi Deborah Moyer,

Thank you for sharing the troubleshooting you have already completed. Since the crashes are producing different bugcheck codes, the next useful step is to check the recent minidumps in WinDbg and see whether the same driver or module appears across multiple crashes.

Install WinDbg from Microsoft and open it as administrator. Select File > Open dump file, then open the most recent .dmp file from: C:\Windows\Minidump

Once the file has finished loading, enter: !analyze -v

Please copy the complete result and include it in your reply. If possible, repeat this with the three most recent minidumps so I can help compare the results and look for a consistent pattern.

Before posting, please remove any personal information from the output, including your name, Windows username, computer name, email address, account identifiers and personal folder paths. Leave the bugcheck details, driver and module names, failure bucket, stack entries and memory addresses visible, as these may be useful for the analysis.

Kindly also include the exact August update KB number from Settings > Windows Update > Update history, along with your Windows version and build shown by winver. Once you share the redacted WinDbg results, I can help take a closer look.

Deborah Moyer 0 Reputation points

2026-09-15T23:36:46.8+00:00
Thank you for the instructions! I successfully ran WinDbg as an Administrator on four of my most recent nightly crash dump files. I'm happy to send all four dump analysis details to you if you want them but all 4 results show a 100% consistent culprit across different bugcheck codes:

Dump File 1 (9/14 Crash - 9:40 PM):

Bugcheck: 13a (KERNEL_MODE_HEAP_CORRUPTION)

Failure Bucket: 0x13a_12_nt!ExAllocatePool2

Process Name: hp-plugin-exec

Stack Text: nt!ExAllocatePool2+8a

Dump File 2 (9/13 Crash - 9:39 PM):

Bugcheck: 50 (PAGE_FAULT_IN_NONPAGED_AREA)

Failure Bucket: AV_nt!ObReferenceObjectSafeWithTag

Process Name: hp-plugin-exec

Instruction Address: nt!ObReferenceObjectSafeWithTag+c -> nt!ExpGetNextProcessThread

System Specifications:

Windows Version: Windows 11 Home, Version 24H2 (Build 26100.9444)

August Update KB: KB5121003 that started this

Despite throwing different bugcheck codes (13a heap corruption vs 50 page fault), both nightly crashes are being explicitly executed by hp-plugin-exec as it queries system information. I would appreciate your engineering guidance on how to safely mitigate or block this specific HP plugin framework conflict with the Windows kernel.
Deborah Moyer 0 Reputation points

2026-09-16T00:41:38.4066667+00:00

Hi,

Following up on my previous message, I found an error in my earlier report. This is the corrected raw WinDbg data from all 4 recent crash dumps to help pinpoint the root cause.

While three of the crashes point directly to the HP component (hp-plugin-exec) corrupting the kernel mode heap via FLTMGR, the 2:43 PM dump reveals a secondary failure in the Realtek Wireless driver (rtwlane6.sys). Given the consistent 0x13a Heap Corruption across the sessions, it appears the HP plugin's memory execution behavior may be destabilizing the pool environment for adjacent drivers.

I have proactively disabled HpseuHostLauncher, HP System Tray, and hpwuschd2 in Task Manager to isolate the operating system. Please review the specific stack traces below:

DUMP #1 & #4 SUMMARY: Bugcheck: KERNEL_MODE_HEAP_CORRUPTION (13a) Process Name: hp-plugin-exec Faulting Component: nt!ExAllocatePool2+8a / FLTMGR!IoPerfInitializeEntityData Stack Trace Snippet: nt!RtlpHpVsSlotAllocate+0x2b3 nt!ExAllocatePool2+0x8a FLTMGR!IoPerfInitializeEntityData+0x17b FLTMGR!FltpInitInstance+0x6ff nt!NtCreateFile+0x79

DUMP #2 SUMMARY: Bugcheck: PAGE_FAULT_IN_NONPAGED_AREA (50) Process Name: hp-plugin-exec Faulting Component: nt!ObReferenceObjectSafeWithTag+c Stack Trace Snippet: nt!ObReferenceObjectSafeWithTag+0xc nt!ExpGetNextProcessThread+0xb9 nt!ExpQuerySystemInformation+0x89e nt!NtQuerySystemInformation+0x5d

DUMP #3 SUMMARY (2:43 PM Outlier): Bugcheck: KERNEL_MODE_HEAP_CORRUPTION (13a) Process Name: System Freed Pool Tag: O221 Image Name: rtwlane6.sys (Realtek Wireless LAN) Stack Trace Snippet: nt!ExFreePoolWithTag+0xc62 ndis!NdisFreeMemory+0x17 rtwlane6+0x3029e

Again, I can send you the full feed of the debug report via a Word file if you'd like more detail, but didn't see an upload option.

Please let me know your thoughts on whether updating the Realtek package is necessary, or if isolating the HP execution environment should fully mitigate the system instability. Thank you for your help!
Clary-N 16,020 Reputation points Microsoft External Staff Moderator

2026-09-16T08:08:34.3033333+00:00

Hi Deborah Moyer,

Thank you for the corrected dump details. The repeated hp-plugin-exec process is worth investigating, but the process running at the time of a crash is not necessarily the component that originally corrupted memory.

Because one dump directly names rtwlane6.sys in the pool-freeing stack, I recommend updating the Realtek wireless driver as well as continuing the HP software isolation. First check Settings > Windows Update > Advanced options > Optional updates. If no newer driver appears, use the latest compatible wireless driver from your PC manufacturer’s support page.

Please keep the HP startup entries disabled temporarily but avoid manually blocking or deleting HP files. If the crashes continue, temporarily uninstalling the related HP utility through Settings > Apps > Installed apps would provide a cleaner test.

There is no need to send the Word file yet. Please monitor the PC and share the next !analyze -v result if another crash occurs.
Deborah Moyer 0 Reputation points

2026-09-16T23:16:08.5566667+00:00

Hi,

I have completed the isolation and diagnostic steps you requested: I uninstalled the HP System Event Utility and successfully updated the Realtek wireless adapter to version 6001.10.356.3 via the standalone factory Softpaq.

Unfortunately, the system experienced an overnight black screen crash while idle. However, the resulting fresh dump analysis (091626-13437-01.dmp) reveals a significant shift in the failure path:

Bugcheck: KERNEL_SECURITY_CHECK_FAILURE (139) Subcode: 0x1d FAST_FAIL_INVALID_BALANCED_TREE Process Name: hp-plugin-exec Faulting Component: disk!DiskDeviceControl+f4 (disk.sys)

While hp-plugin-exec was the active context executing a device IO control query, the stack tracks a critical structural corruption within the storage stack context (storport!RaUnitStorageQueryDeviceProtocolSpecificPropertyIoctl -> nt!ExFreePoolWithTag -> disk!DiskDeviceControl).

I checked Device Manager and confirmed this machine utilizes an Intel RST VMD Controller 467F and an Intel RST VMD Managed Controller 09AB infrastructure to handle the storage subsystem. Both controllers, along with the advanced updates menu, report no newer drivers available.

To address the storage stack corruption shown in the log, I just ran a deep DISM /RestoreHealth cycle followed by sfc /scannow. The SFC scan completed successfully with a clean bill of health: "Windows Resource Protection did not find any integrity violations."

I am leaving the PC running tonight with automatic restarts disabled to monitor for further pool stability. Please let me know your thoughts on this storage stack vector. Stack trace details are attached below:

nt!KiRaiseSecurityCheckFailure+0x368 nt!RtlRbRemoveNode+0x133 nt!RtlpHpVsChunkFree+0xb0 nt!ExFreePoolWithTag+0xc62 storport!RaUnitStorageQueryDeviceProtocolSpecificPropertyIoctl+0x30b storport!RaUnitDeviceControlIrp+0xf5d disk!DiskDeviceControl+0xf4
Clary-N 16,020 Reputation points Microsoft External Staff Moderator

2026-09-17T08:12:23.5866667+00:00

Hi Deborah Moyer,

Thank you for the detailed update. You’ve done a thorough job isolating the HP utility, updating the Realtek driver and checking Windows system integrity.

The new dump does point to corruption being detected while the storage stack was processing a device-control request. However, seeing disk.sys and storport.sys in the stack does not by itself confirm that either Windows component, the Intel RST controller, or the physical drive caused the corruption. Another driver may have damaged the structure earlier, with the problem only being detected when the storage request was processed. Bug check 0x139 specifically indicates corruption of a critical kernel data structure.

Since SFC completed cleanly and no newer storage driver is being offered, I would avoid changing the VMD configuration or manually replacing the Intel RST driver. Please check the PC manufacturer’s support page for any newer BIOS, chipset, Intel RST/VMD or storage firmware specifically approved for this model.

It would also help to check Event Viewer > Windows Logs > System around the time of the crash for storage-related events such as 129, 153, 157, 55, or 98. These may show whether Windows recorded a controller timeout, device reset, unexpected removal or file-system issue.

For now, leaving automatic restart disabled and monitoring for another crash is reasonable. If it happens again, please share the new !analyze -v output and any storage-related events from the same time. A repeated pattern across multiple fresh dumps will be more useful than drawing a conclusion from this single storage-stack appearance.
Deborah Moyer 0 Reputation points

2026-09-17T23:13:33.09+00:00
Hi,

Following up with the exact diagnostic data requested from last night's idle black screen failure.

Per your instructions, I completed the clean test by completely uninstalling the HP System Event Utility and verified a clean system file baseline. Despite the software isolation, the system experienced another black screen crash while idle overnight.

Reviewing the Event Viewer logs inside Windows Logs > System around the exact crash boundary revealed a definitive pattern. The system is throwing a rapid succession of Event ID 129 (Reset to device, \Device\RaidPort0) and Event ID 153 (The I/O request was retried) disk controller resets, accompanied by secondary Event 55 and 98 filesystem alerts once the pipeline breaks.

Furthermore, the fresh WinDbg crash analysis captures the failure path directly inside the core Windows 11 Kernel structure (ntkrnlmp.exe build 26100.9457):

Bugcheck: Access Violation / Page Fault context

Process Name: hp-plugin-exec

Faulting Component: nt!RtlpHpVsSlotAllocate+131

Stack Trace Context: FLTMGR!FltpEnumerateRegistryInstances -> nt!ExAllocatePool2 -> nt!RtlpHpVsSlotAllocate Could these Event 129/153 disk resets indicate that the kernel memory allocation error (nt!RtlpHpVsSlotAllocate) is being triggered by a timing latency or power-state drop when the storage stack executes routine registry scans during system idle?

To help test this theory and keep the system stable, I have temporarily switched the Windows Power Plan from Balanced to High Performance to see if preventing the processor and storage controller from entering those low-power idle states stops the overnight crashes.If you don’t recommend that I try this, let me know and I’ll switch it back.

Please let me know your thoughts on this running pattern and if there are specific firmware or controller policies you recommend adjusting next.

Thank you!
Clary-N 16,020 Reputation points Microsoft External Staff Moderator

2026-09-18T09:16:42.7566667+00:00
Hi Deborah Moyer,

This additional information is very helpful. The repeated Event 129 and 153 entries confirm that the storage path is experiencing timeouts, resets and I/O retries. The Event 55 and 98 alerts that follow may be secondary file-system effects. However, this still does not prove that an idle power-state transition is triggering the crash, and hp-plugin-exec being the active process does not necessarily mean it is the cause.

Using High Performance temporarily is reasonable as a controlled test. I would leave the VMD configuration, Intel RST driver, registry timeout value, and other controller settings unchanged for now. If the overnight crashes and Event 129/153 entries stop while using High Performance, that would give us another useful clue, but it still would not identify the underlying component by itself.

I would also check the PC manufacturer's support page for any model-specific BIOS, chipset, Intel RST/VMD, storage controller or SSD firmware updates. Before making further storage changes, please make sure important data is backed up and run the manufacturer's full storage diagnostic along with chkdsk /scan.

*Disclaimer: Running chkdsk can check the file system and file system metadata of a volume for logical and physical errors. To avoid any trouble for you, do not cancel or interrupt chkdsk, and back up important data.

More information please refer to this chkdsk | Microsoft Learn.

If another crash occurs, please share the new dump analysis along with the Event 129/153 entries from the same time window, including their Source and full General/Details information. That should help show whether the same storage path continues to be involved.

For further investigation, I also recommend contacting Microsoft Support, as a support agent may be able to provide additional diagnostic assistance with the recurring crashes and storage-related events:

Go to Contact Microsoft Support and sign in with your Microsoft account.

Type Chat Support and select Get help.

Scroll down and select Contact support.

Under Products and services, choose Windows.

Under Category, select Technical support, then select Confirm.

Select "Chat with a support agent in your web browser".

When contacting support, I suggest having the latest crash dump analysis and the Event 129/153 logs available so they can review the diagnostic information you have already collected.

I hope this helps.
Deborah Moyer 0 Reputation points

2026-09-19T00:09:23.3233333+00:00
Hi,

Thank you for your continued help. I have completed the exact diagnostic, file system, memory, and firmware environment baseline checks you requested. Unfortunately, the overnight crash persisted under the High Performance plan, and the system experienced a major loop of silent background crashes this morning and afternoon while idle.

Here are the updates regarding the steps you outlined:

1.     File System, Disk, and Memory Integrity:

chkdsk /scan: I successfully ran the command which scanned the file system completely and returned: "Windows has scanned the file system and found no problems. No further action is required."

Storage Diagnostics: The full hardware storage diagnostics passed perfectly with a clean bill of health across all storage units, ruling out physical SSD cell or read degradation.

UEFI Memory Test: I ran this outside the Windows Operating System. The physical RAM modules passed completely with zero integrity issues found.

2.     BIOS, Chipset, and Storage Controller Firmware Status:

I verified these directly through the official manufacturer support engine. The system is completely up to date with the latest production BIOS, chipset architecture, and storage configuration. No firmware updates are outstanding.

3.     Targeted History of Event 129 / 153 Entries & Power Plan Context:

I isolated and reviewed the comprehensive filter log again for Event IDs 129 and 153 across the crash windows. The system is not throwing storage controller resets (storahci, iaStorVD, or IntelRST). Every single 129 and 153 entry inside the failure timeline belongs exclusively to standard, healthy OS startup initializations (Microsoft-Windows-Hyper-V-Hypervisor and Microsoft-Windows-Kernel-Boot).

Furthermore, when going to alter the power configurations as a controlled test, I discovered that the advanced PCIe Link State Power Management setting was already configured to "Off" under the previous plan.

This seems to confirm that the storage path is not timing out due to an idle power-state drop or a low-power transition, as those low-power states were already explicitly disabled when the crash occurred.

4. Fresh Crash Dump #7 Data:

While sitting idle, the system generated a sequential block of Windows Error Reporting events. The corresponding fresh crash dumps confirm the identical, persistent signature: a 0x13A: KERNEL_MODE_HEAP_CORRUPTION directly inside nt!ExAllocatePool2 and nt!RtlpHpVsSlotAllocate, triggered explicitly while hp-plugin-exec was the active process.

Since the physical hardware, memory, storage disks, file system, and firmware are all completely pristine, the data appears to point to this vendor process executing an invalid memory block allocation that actively corrupts the Windows 11 kernel heap manager.

Given that this software component is driving the system into an unrecoverable kernel heap panic while idle, what is the recommended method to safely disable or block this process/service within the OS environment?

Again, thanks for your insight and help!
Clary-N 16,020 Reputation points Microsoft External Staff Moderator

2026-09-19T08:43:14.0366667+00:00
Hi Deborah Moyer,

Thank you for the detailed update and for working through all of those checks. The additional results are helpful, particularly since the crash still occurred under the High Performance plan and your review shows the Event 129/153 entries were not coming from the storage-controller sources we were looking for.

Based on that, the earlier storage power-state theory now seems less likely. However, I would still be cautious about concluding that hp-plugin-exec itself is definitely responsible for the crashes. The 0x13A KERNEL_MODE_HEAP_CORRUPTION indicates that corruption was detected in the kernel-mode heap, but the process active when the corruption is detected is not necessarily the component that originally caused it.

Before disabling or blocking anything, I would first identify exactly what hp-plugin-exec belongs to. In Task Manager, right-click the process and select Open file location, then check Properties > Details and Digital Signatures. If possible, please share:

The full file path

Product name and file version

Digital signer/publisher

The corresponding application shown under Settings > Apps > Installed apps

I would avoid manually deleting, renaming or blocking the executable for now, since we have not yet confirmed exactly which installed component it belongs to or whether anything else depends on it.

Once the parent application is identified, a cleaner isolation test would be to temporarily uninstall that specific application through Installed apps, restart the computer and then test again under the same idle conditions.

If the crashes stop while that software is removed, that would be a useful clue, although I still would not treat it alone as definitive proof that the process itself caused the heap corruption. If the crashes continue, the complete dump files would likely need deeper analysis to identify what originally corrupted the memory.

You have already ruled out quite a few possibilities, so I think identifying the exact component behind hp-plugin-exec and testing its removal is a reasonable next step.
Deborah Moyer 0 Reputation points

2026-09-19T22:06:27.7766667+00:00

Hi,

Thank you for the quick weekend response! Per your request, I located/confirmed the parent component for the HP Plugin and have held off on altering any application states to preserve the baseline.

The system experienced another hard lockup last night (same window of time between 9:15 and 9:40 pm that previous crashes have occurred) when the computer was idle. Here is the data from the file properties and the latest minidump for your analysis:

1.     Verification of the hp-plugin-exec Parent Component:

·         File Name: hp-plugin-executor (runs actively as hp-plugin-exec)

·         Product Name: HP One Device Platform

·         File Version: 6.335.7620.0

·         Digital Signer: HP Inc.

·         Parent Application: HP One Agent (Listed under Settings > Installed Apps, with the background service running as hp-one-agent-service.exe).

2.     Latest Minidump Analysis Context (091926-17390-01.dmp) from this morning:

·         Bugcheck: 0x139: KERNEL_SECURITY_CHECK_FAILURE (Subcode: 0x1d - FAST_FAIL_INVALID_BALANCED_TREE)

·         Active Process: hp-plugin-exec

·         Stack Trace Execution Path: hp-plugin-exec -> FLTMGR!FltDeviceIoControlFile -> eamonm.sys (ESET Antivirus driver) -> nt!ExFreePoolWithTag -> nt!RtlRbRemoveNode -> FAST_FAIL_INVALID_BALANCED_TREE

3.     Concurrent System Log Baseline:

·         The physical hardware diagnostics, UEFI memory parameters, and chkdsk /scan remain completely clean.

·         Historical Code Context: It is worth noting that this system has encountered the 0x139 Bugcheck code previously during earlier failure windows. However, in all prior instances, the failure path pointed strictly to generic native Windows components (ntkrnlmp.exe / disk.sys) without ever implicating ESET's driver module. This is the first and only snapshot where a specific security driver has appeared in the execution trail.

·         Critical Timeline Event: Right at the 9:22 PM failure boundary, the very last entry successfully recorded in the System Event Log, prior to the hard freeze, was the initialization of a background Windows Update.

Given that this fresh snapshot captures hp-plugin-exec actively interacting with the security filter pipeline exactly as a Windows update sequence was initiated, I wanted to share this timeline with you before taking any further steps for uninstalling the HP One Agent.

Since you mentioned testing the removal of that program through Installed Apps as a reasonable next step, would you still recommend proceeding with that uninstallation test under these conditions, or do you have a different take based on this latest update?

Thank you again for all your help and insight!