Diagnostic update following the clean-boot test
Following the recommendation to perform a clean boot and rerun DISM /Online /Cleanup-Image /RestoreHealth, I carried out the following tests.
1. Clean boot
Using msconfig:
- Hid all Microsoft services.
- Disabled all remaining non-Microsoft services.
- Disabled all enabled startup applications in Task Manager.
- Restarted Windows successfully into the clean-boot configuration.
The remaining non-Microsoft services included Intel and NVIDIA services.
2. RestoreHealth in clean boot
I then ran:
DISM /Online /Cleanup-Image /RestoreHealth
The result was:
[===========================54.7%]
Error: 1726
The remote procedure call failed.
This is essentially the same result as under normal startup, where RestoreHealth previously failed at 55.2% with the same Error 1726.
Therefore, disabling the non-Microsoft services and startup applications did not resolve the RestoreHealth failure.
3. Unexpected reboot and BSOD
Following the clean-boot RestoreHealth failure, Windows unexpectedly rebooted.
I checked the System event log and found Event 41 (Kernel-Power), reporting that the system had rebooted without cleanly shutting down first.
I then found Event 1001 (Microsoft-Windows-WER-SystemErrorReporting), which recorded:
Bugcheck: 0x0000003B
Exception: 0xC0000005
A minidump was created:
C:\Windows\Minidump\092826-7984-01.dmp
The dump is 3,839,974 bytes and has been preserved.
4. Hardware-related checks
Because Event 41 can be associated with unexpected hardware or power events, I checked the System log for WHEA-Logger events covering approximately 10:20–10:30, including the period of the crash.
There were no WHEA-Logger events during this period.
I also checked for Disk, NTFS, storport, iaStor, volmgr and related storage events around the crash.
There were no Disk, storport or iaStor errors. NTFS reported the C:, D: and other volumes as healthy.
The relevant volmgr Event 162 simply confirmed that dump-file generation succeeded.
5. Preliminary examination of the crash dump
The dump confirms:
0x3B SYSTEM_SERVICE_EXCEPTION
with:
0xC0000005 STATUS_ACCESS_VIOLATION
The reported fault address is:
FFFFF8031195B776`
The module information places this address within:
FLTMGR.SYS
I have also obtained a copy of the installed FLTMGR.SYS for comparison.
The dump contains references to Windows servicing activity, including TiWorker.exe associated with the servicing stack.
I am not concluding that FLTMGR.SYS or TiWorker.exe caused the crash. At this stage, the evidence only establishes that the reported fault address is within FLTMGR.SYS and that servicing activity was occurring.
6. Current picture
The sequence now appears to be:
Windows 11 25H2 / 26200.8037 → DISM RestoreHealth → approximately 55% → Error 1726 → 0x3B / 0xC0000005 system crash → automatic reboot → minidump created
The RestoreHealth failure occurs at essentially the same point in both normal startup and clean boot:
- Normal startup: 55.2%
- Clean boot: 54.7%
The clean-boot test therefore did not identify ordinary third-party services or startup applications as the cause.
There are currently no WHEA hardware errors or storage errors associated with the crash.
The outstanding question is whether the minidump can identify the actual failing kernel path/driver, or whether the evidence points towards memory/hardware corruption.
I have not repeated RestoreHealth after the crash and have not made any further BIOS or hardware changes.
The minidump is preserved and available for further analysis.