my win10 x64 computer crashed when i wasn't using ...

0x00000139 is KERNEL_SECURITY_CHECK_FAILURE. It means Windows detected corruption of an important kernel data structure. Seeing ntfs.sys in the dump does not automatically mean your SSD, HDD, or NTFS filesystem is defective. ntfs.sys may simply have been the component that noticed earlier corruption. Microsoft specifically notes that this corruption may be introduced earlier and detected later in an unrelated component. (Microsoft Learn)

Most likely causes in your case

In approximate order of likelihood:

1. A third-party kernel driver corrupted memory

   VMware Workstation installs several host drivers for virtualization, virtual disks, USB, and networking. Clash Verge may install or use TUN/Wintun and network-filter components. Either program, or an interaction between their drivers, could corrupt kernel memory even though the final stack points to ntfs.sys.

   ManicTime is less suspicious unless it has installed a filesystem-monitoring driver, because its ordinary activity is mainly user-mode database and file I/O.

2. A filesystem-filter or storage-filter driver

   Antivirus, backup software, encryption software, cloud-sync utilities, disk-monitoring applications, snapshot tools, and virtual-disk software can insert drivers above or below NTFS. A defect in one of those filters can make ntfs.sys appear responsible.

3. Transient RAM corruption or memory instability

   SMART and CHKDSK do not test RAM. XMP, CPU undervolting, overclocking, marginal RAM, or an unstable memory controller can produce exactly this type of apparently random one-off corruption.

4. Storage-controller or power-state problem

   An NVMe/SATA controller driver, chipset driver, SSD firmware, cable, power transition, or sleep/idle-state issue can cause a transient problem without producing bad SMART values.

5. Windows component corruption

   Possible, but less likely after a single isolated crash, particularly when CHKDSK is clean.

If the first bugcheck parameter was 3, that specifically means a corrupted LIST_ENTRY, often caused by a driver double-removing an entry, using freed memory, or modifying a kernel list without correct synchronization. (Microsoft Learn)

The most useful information you can provide

The best option is the compressed dump file:

• C:\Windows\Minidump\<date>.dmp, or
• C:\Windows\MEMORY.DMP

A minidump is normally sufficient for an initial assessment. Dumps can contain fragments of system information, so avoid publicly posting a full memory dump.

Alternatively, open the dump in WinDbg and provide the complete output of:

text
.symfix
.reload
!analyze -v
.bugcheck
kv
lmvm ntfs
!blackboxntfs
!blackboxpnp
!blackboxbsd

WinDbg is Microsoft's debugger for kernel crash dumps, and !analyze -v is the standard starting point for identifying the responsible stack and driver. (Microsoft Learn)

The most important lines are:

text
Arg1:
PROCESS_NAME:
MODULE_NAME:
IMAGE_NAME:
SYMBOL_NAME:
FAILURE_BUCKET_ID:
STACK_TEXT:

Also useful:

cmd
fltmc filters

That lists filesystem filter drivers currently installed. Copy the entire output.

And:

cmd
driverquery /v /fo csv > "%USERPROFILE%\Desktop\drivers.csv"
pnputil /enum-drivers > "%USERPROFILE%\Desktop\third-party-drivers.txt"

What I would do now

Because it has happened only once, I would not immediately replace hardware or enable aggressive debugging.

First:

1. Save the dump before Windows cleanup removes it.
2. Check Reliability Monitor by running:

cmd
perfmon /rel

3. Check Event Viewer around the crash for these sources:

text
WHEA-Logger
Disk
Ntfs
stornvme
storahci
volmgr
Kernel-Power

4. Update, from their official sources:

   • VMware Workstation
   • Clash Verge and its TUN/Wintun component
   • motherboard chipset driver
   • storage/NVMe driver and SSD firmware
   • network adapter driver

5. Verify Windows components:

cmd
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

6. If you use XMP, overclocking, undervolting, or custom RAM timings, temporarily return everything to stock settings.

If another crash occurs, temporarily test without one kernel-heavy program at a time. I would start by disabling Clash Verge’s TUN mode or removing its virtual adapter, followed by testing without VMware’s virtual networking components.

Do not enable Driver Verifier against all drivers yet. It deliberately forces crashes and can cause a boot loop. Microsoft recommends selecting particular suspect drivers rather than indiscriminately testing everything. (Microsoft Learn)

The single most useful next item is the complete !analyze -v output or the .dmp file.

I examined the dump itself. It gives a more specific result than “ntfs.sys crashed.”

What the dump shows

text
Bugcheck: 0x00000139  KERNEL_SECURITY_CHECK_FAILURE

Arg1: 000000000000001d
Arg2: ffff82051cbc51b0
Arg3: ffff82051cbc5108
Arg4: 0000000000000000

Arg1 = 0x1D means:

An RTL_BALANCED_NODE red-black-tree entry was corrupted.

Windows uses these trees internally for memory, object, cache, filesystem, and other kernel bookkeeping. This is kernel-memory/data-structure corruption, not an NTFS consistency error such as a bad index, MFT corruption, or bad sector. Microsoft defines parameter 29 this way. (Microsoft Learn)

The exception record is:

text
Exception code:    0xC0000409
Exception address: ntoskrnl.exe + 0x4186B5
Fast-fail reason:  0x1D

The saved crash context is inside ntoskrnl.exe, and the immediate stack contains Windows kernel addresses. No third-party driver appears directly in the active failure chain. I also do not see a genuine ntfs.sys+offset return address in the recovered stack; there is an NTFS module-base pointer present as data. Therefore, an analyzer naming ntfs.sys is probably identifying the subsystem active when corruption was detected, not proving that NTFS created the corruption.

My assessment

This dump does not provide evidence that an HDD/SSD is failing. Your clean SMART and CHKDSK results are consistent with the dump.

The likely categories are:

1. A kernel driver corrupted an RB-tree node earlier, with the corruption later detected during filesystem activity.
2. Transient RAM corruption or unstable RAM/CPU settings.
3. Less likely, a genuine defect in Windows/NTFS.

The dump contains a fragment of a DisplayCAL/Python 2.7 path in the relevant stack area, suggesting the system was processing a filename or directory entry when it detected the damage. That does not make DisplayCAL the culprit; another program may simply have been scanning or accessing that path.

Drivers present that deserve attention

Your system has an unusually large number of third-party virtualization, virtual-storage, filesystem, and network drivers loaded simultaneously.

Notable groups include:

VMware

text
vmci.sys
vsock.sys
VMNET.SYS
vmnetadapter.sys
vmnetbridge.sys
vmnetuserif.sys
vmx86.sys
hcmon.sys

VirtualBox

text
VBoxSup.sys
VBoxUSBMon.sys
VBoxNetLwf.sys
VBoxNetAdp6.sys

So VMware and VirtualBox drivers are both active on the host.

Virtual disks/filesystem-related drivers

text
cbdisk3.sys
phdskmnt.sys
dokan.sys
deviodrv.sys
imdisk.sys
vhdaccess.sys

Other third-party kernel components

text
kprocesshacker.sys
wintun.sys
npcap.sys
USBPcap.sys
idmwfp.sys

For this particular bugcheck, I would be more suspicious of the virtual-disk/filesystem drivers than wintun.sys. VMware remains relevant because a running VM generates heavy virtual-disk activity, but Clash Verge is not strongly implicated by this dump.

Some of these drivers may belong to old software that is no longer actively used. Legacy virtual-disk and filesystem drivers can remain loaded long after their applications are forgotten.

Recommended order of action

1. Do not replace a disk based on this dump

There is no current evidence requiring that.

2. Identify the unfamiliar virtual-storage drivers

Run these in an elevated Command Prompt:

cmd
sc qc cbdisk3
sc qc phdskmnt
sc qc dokan
sc qc deviodrv
sc qc imdisk
sc qc vhdaccess

Also run:

cmd
driverquery /v /fo csv > "%USERPROFILE%\Desktop\drivers.csv"
fltmc filters > "%USERPROFILE%\Desktop\filters.txt"
pnputil /enum-drivers > "%USERPROFILE%\Desktop\driver-packages.txt"

fltmc filters is especially useful because it will show filesystem minifilters layered around NTFS.

3. Remove—not merely close—unused low-level utilities

Closing an application does not unload all of its drivers.

Pay particular attention to:

• unused virtual-disk or mounting software;
• old backup/imaging utilities;
• old Dokan or ImDisk installations;
• Process Hacker 2’s kernel driver;
• whichever hypervisor you no longer use.

Having VMware and VirtualBox installed together is supported in some configurations, but it adds several overlapping virtualization and network drivers. If VirtualBox is no longer needed, uninstalling it is a reasonable cleanup step.

4. Update VMware and Clash/TUN components

Use current official versions. Reinstalling or updating VMware refreshes its storage, USB, and network drivers. For Clash Verge, update both the application and its TUN/Wintun component.

5. Test memory properly

Windows Memory Diagnostic is not a strong exclusion test. Use a bootable test such as MemTest86 for multiple passes, preferably overnight.

Before testing:

• disable XMP temporarily;
• remove CPU undervolting or overclocking;
• restore custom RAM timings to automatic/default;
• update the motherboard BIOS if it is substantially outdated.

A single random 0x139/1D can result from one transient bad memory write.

6. Preserve the next dump

One dump shows the detector but not the original writer. Microsoft notes that these corruptions may be discovered after they were introduced, so comparing multiple dumps is often necessary. (Microsoft Learn)

Set Windows to create a kernel memory dump, rather than only a small dump:

text
System Properties
→ Advanced
→ Startup and Recovery
→ Settings
→ Write debugging information
→ Kernel memory dump

The resulting C:\Windows\MEMORY.DMP would provide much more information about the damaged tree and surrounding allocations.

Useful WinDbg output from this exact dump

Open it in WinDbg and run:

text
.symfix
.reload /f
!analyze -v
.exr ffff82051cbc5108
.trap ffff82051cbc51b0
kv
lm t n
!blackboxntfs
!blackboxpnp
!fltkd.filters

The outputs most likely to add information are kv, lm t n, and !fltkd.filters.

Bottom line

This was a real kernel data-structure corruption event, but the dump does not establish that ntfs.sys or a physical disk caused it. My current ranking is:

1. old or conflicting virtual-disk/filesystem driver;
2. VMware/VirtualBox driver interaction or another third-party kernel driver;
3. transient RAM instability;
4. Windows/NTFS bug;
5. physical storage failure.

Because it has happened only once, clean up/update the suspicious low-level drivers and monitor it. Driver Verifier is not justified yet; with this many third-party drivers, enabling it broadly could create a boot loop without identifying the original intermittent fault.

That information shifts the diagnosis further away from hardware.

A 24-hour MemTest86+ pass, no overclocking, no recent hardware changes, clean SMART, and clean CHKDSK make defective RAM or storage substantially less likely. They do not mathematically exclude intermittent hardware faults, but I would no longer treat hardware as the leading explanation.

The main suspects are now:

1. An old or conflicting kernel driver
2. An old Windows 10 build interacting with newer applications/drivers
3. A rare idle/power-transition race condition
4. A one-time transient software corruption

Your dump’s 0x139, parameter 0x1D, specifically means corruption of a kernel red-black-tree entry. That generally indicates that some kernel component wrote to or reused an object incorrectly; ntfs.sys can be the component that eventually notices the corruption rather than the original writer. (Microsoft Learn)

The disabled Windows Update is significant

This does not mean Windows Update directly caused the crash. It means your Windows kernel and storage stack may be missing years of reliability fixes while applications such as VMware and Clash have continued changing.

Windows 10’s normal support ended on October 14, 2025, but if you disabled updates long before that, your system may also be missing pre-October-2025 kernel, filesystem, networking, and servicing fixes. (Microsoft Support)

Please run:

cmd
winver

Record the version and OS build. Also run:

cmd
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

For Windows 10 22H2, the final normal-support cumulative update was OS build 19045.6456 in October 2025. A much older build would materially increase my suspicion of a software compatibility problem. (Microsoft Support)

You do not necessarily need to enable automatic updates permanently, but for diagnosis I would install the last applicable cumulative update for your Windows edition, or use Windows 10 ESU if applicable.

No antivirus helps, but several filter drivers remain

Disabling Defender and having no third-party antivirus removes one common source of filesystem-filter crashes. However, your dump showed several other low-level components that can interact with filesystems, virtual disks, networking, or kernel memory:

text
VMware drivers
VirtualBox drivers
Dokan
ImDisk
phdskmnt
cbdisk3
deviodrv
vhdaccess
Process Hacker kernel driver
Wintun
Npcap
IDM network filter

Those drivers matter more than whether the corresponding application window was open. Kernel drivers may load at boot and remain active continuously.

In particular, I would investigate the virtual-storage group:

text
cbdisk3.sys
phdskmnt.sys
dokan.sys
deviodrv.sys
imdisk.sys
vhdaccess.sys

Some may be left over from old disk-mounting, backup, imaging, ISO, RAM-disk, or virtual-drive software.

Run these as administrator:

cmd
sc qc cbdisk3
sc qc phdskmnt
sc qc dokan
sc qc deviodrv
sc qc imdisk
sc qc vhdaccess

For each one, look at:

text
DISPLAY_NAME
BINARY_PATH_NAME
START_TYPE

You can also locate their files:

cmd
where /r C:\Windows\System32\drivers cbdisk3.sys
where /r C:\Windows\System32\drivers phdskmnt.sys
where /r C:\Windows\System32\drivers dokan.sys
where /r C:\Windows\System32\drivers deviodrv.sys
where /r C:\Windows\System32\drivers imdisk.sys
where /r C:\Windows\System32\drivers vhdaccess.sys

Then inspect signatures and versions in each file’s Properties → Digital Signatures and Details tabs.

Why it happened while idle

“I wasn’t using it” does not mean the computer was inactive. During idle time, Windows and applications may perform:

• NTFS cache cleanup
• filesystem metadata updates
• TRIM/Optimize Drives operations
• search indexing
• application database maintenance
• VMware virtual-disk flushing or snapshot work
• ManicTime database/file monitoring
• sleep or display-power transitions
• network adapter power-state transitions

A race condition may only occur during one very specific combination of background I/O and driver activity. That explains why an old driver can work for years and then crash once without any new hardware.

VMware is still relevant

Determine your exact version from VMware Workstation:

text
Help → About VMware Workstation

Old VMware releases have had host and guest BSOD issues fixed in later Workstation releases. Broadcom documents several such fixes, although the documented examples do not exactly match your 0x139/0x1D crash. (Support Portal)

I would update VMware before blaming Clash or ManicTime.

Also check whether both VMware and VirtualBox are actually needed. Your dump showed drivers from both products loaded. If you no longer use VirtualBox, uninstalling it is preferable to merely disabling its application.

Lenovo-specific checks

Use Lenovo’s support page or Lenovo Vantage to check only these categories:

• BIOS/UEFI
• chipset/Intel Management Engine or AMD chipset
• Intel Rapid Storage Technology, if installed
• NVMe/storage controller
• Ethernet and Wi-Fi drivers
• Lenovo power-management components

An old OEM power or storage driver is especially relevant because the crash occurred unattended.

Also run:

cmd
powercfg /lastwake
powercfg /waketimers
powercfg /requests

And check whether the machine was entering sleep around the crash time:

cmd
powercfg /systemsleepdiagnostics

This generates an HTML report.

What to check in Event Viewer

Open:

cmd
eventvwr.msc

Inspect Windows Logs → System during the five minutes before the crash. Look for:

text
Disk
Ntfs
stornvme
storahci
iaStorA
iaStorAC
WHEA-Logger
volmgr
Kernel-Power
Kernel-PnP
Display

Interpretation:

• Repeated Disk, Ntfs, stornvme, or controller errors would revive storage/controller suspicion.
• WHEA-Logger errors would revive hardware suspicion.
• Only Kernel-Power 41 after the BSOD is expected and not the cause.
• No preceding hardware/storage errors supports a driver corruption theory.

What I would do, in order

1. Check winver.
2. Update Windows to the latest applicable Windows 10 build.
3. Update VMware.
4. Update Lenovo BIOS, chipset, storage, network, and power drivers.
5. Identify and remove unused virtual-disk drivers/software.
6. Remove VirtualBox if you no longer use it.
7. Keep using the computer normally and see whether it repeats.
8. Configure a kernel memory dump for the next crash.

I would not run Driver Verifier yet. Microsoft warns that Driver Verifier intentionally stresses drivers and can itself crash the system; it is most appropriate on a test/debugging machine. (Microsoft Learn)

At this point, my revised probability ranking is approximately:

• Old/conflicting third-party driver: high
• Outdated Windows/driver compatibility issue: moderate to high
• Power-state transition bug: moderate
• RAM/CPU instability: low
• Physical disk failure: low
• ManicTime itself: low
• Clash/Wintun alone: low to moderate
• VMware or another virtual-storage component: moderate to high

That changes the balance further.

The absence of preceding Disk, Ntfs, storage-controller, or WHEA events makes a physical storage or hardware fault less likely. Old software can still crash after years of stability because this type of corruption can require an extremely rare timing condition, power transition, unusual file operation, or interaction between two drivers. No recent update is required for a latent race or use-after-free bug to occur.

Because Clash Verge is the only recently changed component, it deserves attention—especially if it installed or replaced a TUN/Wintun driver. However, the minidump did not directly identify Wintun, Clash, VMware, or another third-party driver, so uninstalling Clash solely on that evidence would be premature.

The 2 GB MEMORY.DMP is much more useful

Please preserve it. Do not run Disk Cleanup or delete dump files.

Copy it from:

text
C:\Windows\MEMORY.DMP

to another folder, then compress it with 7-Zip. Kernel dumps often compress considerably. Upload the compressed file here if the resulting size is accepted.

Be aware that a kernel memory dump can contain filenames, system information, fragments of process memory, and other potentially private data. Sharing it privately here is preferable to posting it publicly.

Why the larger dump matters

The minidump established:

text
0x139 KERNEL_SECURITY_CHECK_FAILURE
Arg1 = 0x1D

That means a red-black-tree node was found corrupted. But a minidump normally contains only the crashing thread, limited stack memory, and the module list. It often cannot answer:

• what pool allocation contained the damaged tree node;
• which driver owned that allocation;
• whether the object had already been freed;
• which filesystem filters were active on the operation;
• what other threads were doing immediately before the crash;
• whether VMware, Wintun, virtual-disk, or other drivers had suspicious pending operations.

The kernel dump may allow those questions to be investigated.

If the dump is too large to upload

Open it in WinDbg Preview and run:

text
.symfix
.reload /f
!analyze -v
.bugcheck
.exr -1
.ecxr
kv
lm t n
!thread
!process 0 0
!blackboxntfs
!blackboxpnp
!blackboxbsd
!fltkd.filters

Then run these using the addresses from the bugcheck:

text
.trap ffff82051cbc51b0
.exr ffff82051cbc5108

For the corrupted structure address, try:

text
!address ffff82051cbc51b0
!pool ffff82051cbc51b0
!poolval ffff82051cbc51b0

Some commands may say the address is not in pool or that the information is unavailable. That is still useful. Save the complete output:

text
.logopen /t C:\dump-analysis.txt

Run the commands, then:

text
.logclose

Upload dump-analysis.txt.

Also provide these small diagnostic files

Run Command Prompt as administrator:

cmd
fltmc filters > "%USERPROFILE%\Desktop\filters.txt"
driverquery /v /fo csv > "%USERPROFILE%\Desktop\drivers.csv"
pnputil /enum-drivers > "%USERPROFILE%\Desktop\driver-packages.txt"
systeminfo > "%USERPROFILE%\Desktop\systeminfo.txt"

For Clash specifically:

cmd
sc query type= driver | findstr /i "wintun tap tun clash"
sc query wintun

The service name may not literally be wintun, so an error from the second command does not prove it is absent.

Current likelihood ranking

Based on everything so far:

1. Rare corruption by an old third-party kernel driver
2. Compatibility issue involving the newly changed Clash Verge/TUN component
3. Interaction among VMware, VirtualBox, virtual-disk, or filesystem drivers
4. One-time unexplained kernel corruption
5. Hardware instability
6. Physical disk failure

I would analyze the MEMORY.DMP before uninstalling several programs or enabling Driver Verifier. It is the best chance of identifying the allocation owner rather than merely the component that detected the corruption.

I could resolve the WeTransfer link, but this environment cannot complete WeTransfer’s session-based/API download, so I have not obtained the 2 GB dump and should not pretend to have analyzed it.

Please compress and split it, then upload the parts directly here. With 7-Zip:

cmd
mkdir C:\CrashDump
copy C:\Windows\MEMORY.DMP C:\CrashDump\

"C:\Program Files\7-Zip\7z.exe" a -t7z -mx=3 -v500m ^
C:\CrashDump\MEMORY.7z C:\CrashDump\MEMORY.DMP

This will create files such as:

text
MEMORY.7z.001
MEMORY.7z.002
MEMORY.7z.003

Upload every part. A kernel dump often compresses substantially, so there may be fewer parts than expected.

Alternatively, in 7-Zip’s graphical interface:

1. Right-click MEMORY.DMP → 7-Zip → Add to archive
2. Archive format: 7z
3. Compression level: Normal
4. Split to volumes: 500M
5. Upload all resulting files

The dump may contain system paths, usernames, filenames, process details, and fragments of kernel memory, so avoid posting it on a public forum.

Once the split archive is directly available, the main checks will be the damaged tree node’s memory region, pool ownership, active filesystem filters, pending IRPs, process/thread context, and the versions/timestamps of VMware, Wintun, virtual-disk, and other third-party drivers.

The compressed file itself is fine, but I still can’t retrieve it from that WeTransfer page: WeTransfer generates the actual file URL through a browser-session POST request, while my download interface only receives the HTML landing page. (GitHub)

The quickest workaround is:

1. Open the WeTransfer link in Chrome or Firefox.
2. Click Download and let it begin.
3. Open the browser’s Downloads page and pause/cancel the download.
4. Right-click the download and choose Copy download link.
5. Send me that copied address. It should begin with something like:

text
https://download.wetransfer.com/...

That is the temporary direct file URL, rather than the we.tl landing page, and should be downloadable here. This method is also commonly used for command-line WeTransfer downloads. (Stack Overflow)

Alternatively, place the same archive in Google Drive, Dropbox, OneDrive, or upload it directly here, with public link access enabled. No further recompression is necessary.

At present, I have not accessed or analyzed the 2 GB dump, so the earlier 0x139 / Arg1 0x1D assessment remains the latest supported conclusion.

That is still a browser-local handoff URL, not the archive itself. It contains the transfer ID and security token, but it requires a browser-side POST request to WeTransfer’s /api/v4/transfers/.../download endpoint; the response then contains the real direct_link. The open-source WeTransfer downloader uses that same flow. (GitHub)

To obtain the usable link in Chrome/Edge:

1. Press F12 → Network.
2. Enable Preserve log.
3. Open the original WeTransfer page and click Download.
4. In Network, search for download.
5. Select the request ending in:

   text
   /api/v4/transfers/.../download

6. Open its Response tab.
7. Copy only the full value after:

   json
   "direct_link": "https://..."

8. Send that link here.

Do not copy the local-bartender URL again—it returns 404 outside your browser session, which is what happened when I tested it. (Website Name Not Provided)

The reliable alternative is uploading the archive to Google Drive, OneDrive, or Dropbox with public-link access, or splitting it into roughly 400 MB parts and attaching them directly here. I still have not received any bytes from the full dump, so no full-dump conclusions have been drawn yet.

I can see the Google Drive viewer link, but this environment cannot turn that viewer page into the underlying archive download. The Google Drive connector available here also does not expose Drive-file fetching.

Please send this exact direct-download form as a new message:

text
https://drive.usercontent.google.com/download?id=1Nck0reb7hPdkd1i8BNrVWsg1u9azb9Kc&export=download&confirm=t

Before sending it, confirm the Drive sharing setting is:

text
General access → Anyone with the link → Viewer

If that direct address still fails, split the compressed archive into parts and attach them directly:

cmd
"C:\Program Files\7-Zip\7z.exe" a -t7z -mx=0 -v500m MEMORY-split.7z MEMORY.7z

Because MEMORY.7z is already compressed, -mx=0 avoids wasting time recompressing it. Upload every resulting .001, .002, and later part.

I tested that exact URL, but this environment still cannot retrieve the binary file: the direct downloader failed, and the network endpoint could not be resolved. I have not received any bytes of the archive, so I cannot honestly analyze the full dump yet.

Please attach the compressed archive directly in this chat rather than sending another cloud link. If it exceeds the attachment limit, split the already-compressed file without recompressing it:

cmd
"C:\Program Files\7-Zip\7z.exe" a -t7z -mx=0 -v500m MEMORY-parts.7z MEMORY.7z

This produces:

text
MEMORY-parts.7z.001
MEMORY-parts.7z.002
MEMORY-parts.7z.003
...

Attach all parts directly here. Once they are present as chat attachments, I can extract the dump and inspect it.

I tried both:

• files.catbox.moe/id3aql.001 — the hostname cannot be resolved from this runtime.
• LimeWire — the share page cannot be fetched here.

So I still cannot access the full dump. This appears to be an access limitation on my side, not necessarily a problem with your files.

The most reliable route now is to generate a small WinDbg text report locally.

1. Install WinDbg

Open PowerShell and run:

powershell
winget install Microsoft.WinDbg

Microsoft lists that as the official WinDbg installation command, and current WinDbg supports Windows 10 version 1607 and later. (Microsoft Learn)

2. Open the dump

Start WinDbg, then select:

text
File → Open dump file → C:\Windows\MEMORY.DMP

WinDbg is specifically designed to analyze crash dumps and supports the same debugger commands as classic WinDbg. (Microsoft Learn)

3. Paste these commands into the Command window

text
.symfix
.reload /f
.logopen /t C:\Users\Public\dump-analysis.txt
!analyze -v
.bugcheck
.exr ffff82051cbc5108
.trap ffff82051cbc51b0
kv
!thread
!process 0 0
lm t n
!blackboxntfs
!blackboxpnp
!blackboxbsd
!fltkd.filters
.logclose

Some commands may print errors such as “extension not found” or “unable to read”; that is okay. Let the remaining commands continue.

Then upload this small file directly here:

text
C:\Users\Public\dump-analysis.txt

Also upload these outputs if possible:

cmd
fltmc filters > "%USERPROFILE%\Desktop\filters.txt"
driverquery /v /fo csv > "%USERPROFILE%\Desktop\drivers.csv"

The report should be only a few hundred kilobytes and will provide much more useful evidence than repeatedly trying file-sharing sites.

Full-dump result

I successfully joined all four archive parts, extracted the approximately 1.9 GB MEMORY.DMP, and examined the kernel state. The full dump gives a much clearer result than the minidump.

What actually crashed

text
Bugcheck: 0x139 — KERNEL_SECURITY_CHECK_FAILURE
Parameter 1: 0x1D
Exception: 0xC0000409

0x1D means Windows detected corruption in an internal red-black tree node, represented by RTL_BALANCED_NODE.

The relevant call sequence is approximately:

text
nt!RtlRbRemoveNode
    ↓
internal kernel pool-free routines
    ↓
nt!ExFreePoolWithTag
    ↓
object/file-name query
    ↓
nt!ObQueryNameString

The kernel was trying to remove an entry from an internal tree while freeing memory. The tree’s links were inconsistent, so Windows deliberately stopped with bugcheck 0x139.

This is a kernel memory/pool metadata corruption, not evidence of an invalid NTFS volume, bad MFT, or damaged file.

ntfs.sys is not established as the culprit

The full stack does not contain a convincing execution frame such as:

text
ntfs.sys+some_offset

An NTFS module address appeared among stack data, which probably caused the simpler analyzer to attribute the crash to ntfs.sys.

The more accurate interpretation is:

Corruption was discovered during a file-object/name operation, but the component that originally corrupted the tree probably ran earlier.

This is consistent with:

• clean CHKDSK;
• clean SMART;
• no preceding disk/controller errors;
• no WHEA events;
• 24-hour MemTest86+ pass.

I would not replace any storage device based on this crash.

What Windows was doing when it detected the corruption

The active process context was:

text
WerFault.exe

That is Windows Error Reporting.

The dump also contains this file path in the relevant context:

text
\Device\HarddiskVolume7\Program Files (x86)\DisplayCAL\python27.dll

This indicates that WerFault.exe was querying or processing information associated with DisplayCAL’s python27.dll when the damaged kernel structure was encountered.

This does not mean DisplayCAL corrupted kernel memory. DisplayCAL and python27.dll are user-mode components. More likely:

1. DisplayCAL or one of its processes had an error or generated a report.
2. WerFault examined its executable/module files.
3. The kernel performed a file-object name operation.
4. Previously corrupted kernel bookkeeping was freed or modified.
5. RtlRbRemoveNode detected the inconsistent tree and triggered the BSOD.

DisplayCAL was probably the trigger that exposed the corruption, not the original cause.

Third-party drivers present in the dump

The strongest concern is the number of old low-level drivers loaded simultaneously.

VMware drivers

text
vmci.sys             2019
vsock.sys            2020
VMNET.SYS            2021
vmnetadapter.sys     2021
vmnetbridge.sys      2021
vmnetuserif.sys      2021
vmx86.sys            2021
hcmon.sys             2021

VirtualBox drivers were also loaded

text
VBoxSup.sys
VBoxUSBMon.sys
VBoxNetLwf.sys
VBoxNetAdp6.sys

These appear to be from VirtualBox 6.1.40, dated 2022.

Using VMware while VirtualBox drivers remain installed is not automatically invalid, but it creates overlapping virtualization, USB, and network-filter components.

Old virtual-disk/filesystem/kernel drivers

text
cbdisk3.sys          2013
dokan.sys            2015
imdisk.sys           2015
kprocesshacker.sys   2016
deviodrv.sys         2020
vhdaccess.sys        2020
phdskmnt.sys         2021

This group deserves the most attention. Several of these drivers manipulate virtual storage, filesystem paths, virtual disks, mounted images, or kernel objects—the categories most relevant to this crash mechanism.

Network-related drivers

text
wintun.sys           2021
npcap.sys            2024
idmwfp.sys           2023

Clash Verge processes were active:

text
clash-verge-service
clash-verge.exe
verge-mihomo.exe

So its Wintun/TUN path is relevant. However, neither wintun.sys nor another Clash component appears on the crashing stack. The dump therefore supports:

Clash Verge is a reasonable diagnostic suspect because it is the only recently changed software, but it is not proven to be the cause.

ManicTime was active, but I did not find an obvious ManicTime kernel driver implicated in the crash.

Most likely cause ranking

Based on the full dump and your hardware testing:

1. An old virtual-disk, filesystem, or kernel utility driver corrupted pool metadata earlier
2. Interaction between multiple virtualization/filter drivers, particularly VMware plus installed VirtualBox components
3. Clash Verge’s TUN/Wintun path or an interaction with another network filter
4. A rare Windows kernel defect
5. Intermittent RAM/CPU hardware fault
6. Physical storage failure

The first three are considerably more likely than the last two.

What to do now

1. Identify the old storage/filesystem drivers

Run these commands as administrator:

cmd
sc qc cbdisk3
sc qc dokan
sc qc imdisk
sc qc phdskmnt
sc qc deviodrv
sc qc vhdaccess
sc qc kprocesshacker

Also run:

cmd
fltmc filters

The important fields are:

text
DISPLAY_NAME
BINARY_PATH_NAME
START_TYPE

Do not manually delete any .sys file. Uninstall the parent software through Programs and Features or its proper uninstaller.

The highest-priority cleanup candidates are:

text
cbdisk3
dokan
imdisk
phdskmnt
deviodrv
vhdaccess
kprocesshacker

especially where you no longer recognize or use the associated application.

2. Remove VirtualBox if it is no longer used

VirtualBox’s kernel, USB, and network-filter drivers were loaded even though you were using VMware.

If VirtualBox is not needed, uninstall it completely and reboot. Merely closing VirtualBox does not unload all of its boot-start or system-start drivers.

3. Perform an A/B test without Clash TUN

Because Clash Verge is the only recently changed application:

• first disable TUN mode and reboot;
• if possible, uninstall its Wintun/TUN adapter temporarily;
• continue using VMware and ManicTime normally.

Closing the Clash window alone is not sufficient because its service and adapter driver can remain active.

A recurrence without Clash would weaken the Clash hypothesis. No recurrence does not prove Clash caused it after only one event, but it is the cleanest first experiment.

4. Review VMware installation

Your VMware host drivers are mostly from 2019–2021. Reinstalling the same VMware version may replace damaged or partially upgraded drivers, but a supported newer version would be preferable if compatible with your system.

Your environment is not entirely “old and unchanged”: the dump also contains drivers dated 2023–2024, including Npcap, IDM’s network filter, graphics, audio, and network drivers. Therefore, interactions between old kernel components and newer filter/device drivers remain possible.

5. Do not use broad Driver Verifier yet

The dump identifies the mechanism but not the driver that performed the original overwrite. If crashes recur after removing unused drivers, targeted Driver Verifier may identify the writer.

Do not select “all drivers.” Driver Verifier deliberately stresses drivers and can itself cause repeated BSODs or boot problems. (Wikipedia)

Before using it, ensure you know how to enter Safe Mode and run:

cmd
verifier /reset

Bottom line

The full dump materially changes the diagnosis:

This was not an NTFS disk-integrity failure. It was corruption of an internal kernel pool/red-black-tree structure, detected while WerFault.exe queried a DisplayCAL file object.

The exact driver that performed the earlier corrupting write is no longer present on the active stack. The best-supported suspects are the old virtual-disk/filesystem drivers and the combined VMware/VirtualBox/filter-driver environment. Clash/Wintun is worth testing first because it is the only recent change, but the dump does not directly blame it.

Yes—there is a connection, but it is most likely indirect, not proof that the large file caused the BSOD.

I checked the full dump for that exact GUID. It appears in two places:

1. The full filename 9{3808876b-c176-4e48-b7ae-04046e6cc752} appears only inside ManicTime’s RecentSearches data, reflecting that you had searched for or viewed that filename.
2. The GUID itself appears in the Windows SYSTEM registry data as:

text
\System Volume Information\*{3808876B-C176-4e48-B7AE-04046E6CC752} /s

It is associated with the registry entry named:

text
VSS Default Provider

What that means

The wildcard *{3808876B-C176-4e48-B7AE-04046E6CC752} matches your file:

text
9{3808876b-c176-4e48-b7ae-04046e6cc752}

So the file is almost certainly an internal file belonging to Microsoft’s Volume Shadow Copy Service (VSS) default provider, rather than an arbitrary application file or obvious malware.

The registry entry is under Windows’ BackupRestore\FilesNotToBackup configuration. Microsoft documents that this key identifies system-managed files that backup programs should exclude; the /s syntax means include subdirectories. It does not mean the file is corrupt or safe to delete manually. (Microsoft Learn)

VSS creates and maintains shadow-copy data for features such as System Restore, Previous Versions, and backup software. VSS stores changed-block information in a shadow-copy storage area, also called the diff area, which can grow substantially. Microsoft notes that shadow storage may have no size limit if no maximum has been configured. (Microsoft Learn)

Is it directly responsible for the crash?

The evidence says probably not directly:

• The crash stack does not execute inside volsnap.sys, vssvc.exe, or a VSS provider.
• The dump does not show that 9{GUID} was the file being accessed when the BSOD occurred.
• The relevant file-object operation involved DisplayCAL’s python27.dll.
• The exact 9{GUID} filename in memory came from ManicTime’s search history, not an active kernel file object.
• The BSOD was caused by corrupted kernel red-black-tree/pool bookkeeping, not by Windows reporting a corrupt shadow-copy file.

So I would not say:

“The huge VSS file caused the crash.”

A more defensible conclusion is:

VSS created the large file, and VSS/NTFS activity might have exercised an old filesystem, virtual-disk, or volume-filter driver that had already corrupted kernel memory.

That would fit the presence of your old Dokan, ImDisk, Paragon/virtual-disk, VMware, and VirtualBox-related drivers. VSS often interacts with storage filters and snapshot drivers, so it can expose bugs in them without VSS itself being defective.

When the connection becomes more suspicious

The file is more relevant if one or more of these are true:

• it was created or expanded rapidly immediately before the crash;
• its timestamp closely matches the BSOD;
• it reappears and grows unusually quickly;
• VSS or volsnap events occurred shortly before the crash;
• a backup, disk-image, snapshot, or restore-point operation was running;
• the volume was nearly full;
• old imaging software installed one of the suspicious storage drivers.

A huge file alone is not abnormal if shadow storage was configured as unbounded. Running low on disk space may cause VSS failures or removal of old snapshots, but it would not normally explain a 0x139/0x1D kernel tree corruption.

Check the current VSS state

Run these in an elevated Command Prompt:

cmd
vssadmin list providers
vssadmin list shadows
vssadmin list shadowstorage
vssadmin list writers

The important output is list shadowstorage, particularly:

text
Used Shadow Copy Storage space
Allocated Shadow Copy Storage space
Maximum Shadow Copy Storage space

If the maximum says UNBOUNDED, that explains how the file became extremely large.

Check the relevant logs that were not in the earlier list:

cmd
wevtutil qe Application /q:"*[System[Provider[@Name='VSS']]]" /f:text /c:50
wevtutil qe System /q:"*[System[Provider[@Name='volsnap']]]" /f:text /c:50

Also inspect the registry entry directly:

cmd
reg query "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\FilesNotToBackup" /s

Do not manually delete it

Do not take ownership of System Volume Information and delete that file directly. If it is VSS-managed, manual deletion can invalidate restore points or leave inconsistent VSS metadata.

Shadow-copy space should instead be managed through:

text
System Properties → System Protection → Configure

or through vssadmin, but Microsoft warns that resizing shadow storage can cause existing shadow copies to disappear. (Microsoft Learn)

Revised conclusion

The large file is definitely relevant to VSS and storage activity, because its GUID is explicitly registered as a VSS Default Provider file pattern. However, the dump contains no evidence that the file itself was corrupt or that VSS directly caused the crash. It strengthens the possibility of an interaction with an old volume/filesystem filter driver, particularly if the file was actively growing near the crash time.

There is no contradiction with the earlier analysis. Your local WinDbg run confirms it, but it sharpens two points and slightly changes the suspect ranking.

What the local log confirms

The crash is unequivocally:

text
0x139 / parameter 0x1D
FAST_FAIL_INVALID_BALANCED_TREE

So Windows detected a corrupted red-black-tree entry in kernel memory—not an NTFS consistency error. (dump-analysis_1910_2026-07-11_19-06-45-922.txt)

The precise sequence is:

text
RtlRbRemoveNode
RtlpHpVsChunkCoalesce
RtlpHpVsContextFree
ExFreeHeapPool
ExFreePool
IopQueryNameInternal
ObQueryNameStringMode
MmQueryVirtualMemory
NtQueryVirtualMemory

This means a corrupted tree was found while the kernel heap was coalescing adjacent chunks during a memory-free operation. WerFault.exe initiated a virtual-memory query that caused Windows to query an object name and free a temporary kernel allocation. (dump-analysis_1910_2026-07-11_19-06-45-922.txt)

Therefore:

WerFault.exe triggered detection, but almost certainly did not originally corrupt the heap.

The corruption could have occurred seconds, minutes, or longer before the crash.

Important difference: no third-party filesystem minifilter

Your !fltkd.filters output lists only Microsoft filters:

text
bindflt
storqosflt
wcifs
CldFlt
FileCrypt
luafv
npsvctrig
Wof
FileInfo

There is no antivirus, backup, Dokan, VMware, or other third-party Filter Manager minifilter in that list. (dump-analysis_1910_2026-07-11_19-06-45-922.txt)

That means my earlier category of “third-party filesystem minifilter” should be narrowed:

• An active third-party minifilter is now less likely.
• Old legacy filesystem, virtual-disk, network, USB, or general kernel drivers remain possible.
• Drivers such as cbdisk3.sys, dokan.sys, imdisk.sys, and vhdaccess.sys can be loaded kernel drivers without appearing in !fltkd.filters.

So those drivers are not cleared, but there is no evidence that they were attached as modern NTFS minifilters at the crash.

NTFS is even less suspicious

WinDbg reports:

text
No NTFS Blackbox dump file data found

(dump-analysis_1910_2026-07-11_19-06-45-922.txt)

This does not prove NTFS was uninvolved, because blackbox data is not always available. But combined with:

• no ntfs.sys frame in the executing stack;
• clean CHKDSK;
• clean SMART;
• no storage events;
• heap corruption detected in RtlRbRemoveNode;

there remains no good reason to suspect disk corruption or the large VSS file as the direct cause.

Clash/Wintun becomes slightly more interesting

The dump confirms all three Clash components were active:

text
clash-verge-service.exe
clash-verge.exe
verge-mihomo.exe

(dump-analysis_1910_2026-07-11_19-06-45-922.txt) (dump-analysis_1910_2026-07-11_19-06-45-922.txt)

It also shows a loaded wintun.sys dated October 13, 2021. (dump-analysis_1910_2026-07-11_19-06-45-922.txt)

Additionally, another wintun.sys entry appears in the unloaded-module list. This suggests that at least one Wintun driver instance had been unloaded and another was loaded during that Windows session. That can be normal when Clash enables, disables, or recreates a TUN adapter; it is not evidence of a crash by itself.

Still, because:

• Clash Verge is the only recently changed application;
• Wintun was actively being loaded/unloaded;
• the crash is compatible with an earlier driver use-after-free or invalid memory write;

Clash/Wintun is a sensible first A/B test. But there is no Wintun function on the crash stack, so it is still circumstantial rather than proven.

VMware versus Hyper-V

The log says:

text
Hypervisor.Flags.AnyHypervisorPresent = 0
Hypervisor.RootFlags.IsHyperV = 0
HVCI = 0

(dump-analysis_1910_2026-07-11_19-06-45-922.txt)

That means Microsoft Hyper-V/VBS was not running underneath VMware. Therefore, a VMware-versus-Hyper-V compatibility problem is unlikely.

This does not clear VMware’s own drivers, but it removes one common source of VMware problems.

DisplayCAL clarification

The local log confirms that:

• DisplayCAL-apply-profiles.exe was active;
• the faulting process was WerFault.exe.

However, this text report does not identify which process WerFault was handling. My earlier reference to DisplayCAL\python27.dll came from strings and memory context in the raw dump, not from this WinDbg report.

Therefore, the strongest defensible statement is:

WerFault was inspecting process memory and querying a mapped-object name; DisplayCAL may have been the target, but this log alone does not establish that.

Even if DisplayCAL was the target, a user-mode DisplayCAL failure cannot directly corrupt kernel heap metadata without a kernel driver or Windows defect being involved.

Revised suspect ranking

Based on the local output:

1. Rare memory corruption by an old third-party kernel driver
2. Clash Verge/Wintun interaction, because it is the recent change and Wintun was cycled during the session
3. Old virtual-disk or legacy filesystem drivers, especially cbdisk3, imdisk, dokan, phdskmnt, deviodrv, and vhdaccess
4. VMware/VirtualBox or network-filter interaction
5. A bug in your old Windows kernel heap/object-name path
6. RAM or CPU fault
7. NTFS or physical storage failure

The local report still cannot identify the original writer of the corrupted memory.

Best next WinDbg commands

The stack gives us several concrete addresses that may provide more information. With the same dump open, run:

text
.logopen /t C:\Users\Public\dump-analysis-2.txt

!object ffffbf83bfab8b40
!fileobj ffffbf83bfab8b40

!pool ffffbf83b5468400
!poolval ffffbf83b5468400

!address ffffcf85497e7000
!pool ffffcf85497e7000
!poolval ffffcf85497e7000

dq ffffcf85497e7f80 L40
!verifier 3

vertarget
lmvm nt
lmvm wintun

.logclose

Possible errors such as “not a valid pool allocation” are useful results rather than failures.

The most valuable commands are:

• !fileobj ffffbf83bfab8b40 — may identify the exact file object WerFault was querying.
• !pool ffffbf83b5468400 — may reveal the tag or owner of the allocation being freed.
• !poolval ffffcf85497e7000 — may show the nature and extent of the damaged heap segment.
• lmvm wintun — provides the exact Wintun version, path, and vendor data.
• vertarget — gives a more reliable OS build than the generic 10.0.19041.1 shown by !analyze.

For now, the practical first test remains: disable Clash Verge TUN mode, remove/recreate its TUN adapter, reboot, and monitor, without changing VMware or the other variables simultaneously.

Yes. This second log adds meaningful detail, although it still does not identify the original corrupting driver.

What it proves

1. WerFault was definitely examining DisplayCAL

The queried kernel file object is:

text
\Program Files (x86)\DisplayCAL\python27.dll

The file was opened read-only/shared, its handle had already been cleaned up, and Windows was querying information about the mapped file. (dump-analysis-2_182c_2026-07-11_19-14-38-451.txt)

More importantly, the memory at ffffcf85'497e8000 contains:

text
0x58
\Program Files (x86)\DisplayCAL\python27.dll

The path contains 44 UTF-16 characters:

text
44 × 2 bytes = 88 bytes = 0x58

So this is a structurally correct file-name result buffer. The corrupted heap region was directly associated with the temporary buffer used to return that path.

The sequence is therefore:

text
WerFault queries mapped-image information
→ Windows resolves python27.dll's file-object name
→ temporary kernel name buffer is released
→ kernel heap tries to coalesce free chunks
→ corrupted red-black tree is detected
→ 0x139 / 0x1D

2. This looks like heap metadata corruption, not a bad DLL

Both examined kernel pool regions were reported as invalid:

text
Pool page [...] is INVALID.
Scanning for single bit errors...
None found

(dump-analysis-2_182c_2026-07-11_19-14-38-451.txt)

That pattern is more compatible with:

• a double free;
• use-after-free;
• overwrite of adjacent heap metadata;
• an incorrect tree insertion/removal;
• broader corruption by a kernel driver.

It is less suggestive of a simple isolated RAM bit flip. That agrees with your 24-hour MemTest86+ result, although no software analysis can absolutely exclude intermittent hardware.

There is also no sign that python27.dll itself is corrupt. DisplayCAL is best understood as the user-mode process whose file information exposed the damaged kernel heap, not necessarily the source of the damage.

Does \Driver\volmgr implicate VSS or the huge file?

The file object is associated in the dump with:

text
Device Object: ... \Driver\volmgr

and the surrounding allocation has the generic pool tag:

text
Devi — Kernel device objects

(dump-analysis-2_182c_2026-07-11_19-14-38-451.txt)

This does not establish that Volume Manager caused the corruption. Devi only says that allocation contains a kernel DEVICE_OBJECT; it does not identify who damaged its surrounding pool metadata.

It also does not create a direct connection to:

text
C:\System Volume Information\9{3808876b-...}

For a stronger VSS connection, I would expect evidence involving volsnap.sys, a VSS provider, shadow-copy operations, or the actual System Volume Information file. Instead, the exact file object being queried was DisplayCAL’s python27.dll.

So the large VSS file remains, at most, an indirect source of additional volume activity, not a demonstrated cause.

Wintun result

The active Wintun driver was:

text
\SystemRoot\System32\drivers\wintun.sys
Timestamp: October 13, 2021
ImageSize: 0xA000

(dump-analysis-2_182c_2026-07-11_19-14-38-451.txt)

This confirms that the recent Clash Verge installation is using an old Wintun binary, or at least a Wintun build dating from 2021. That is not inherently defective, and it does not appear in the crashing call stack.

It remains a diagnostic suspect because:

• Clash Verge is your only recent software change;
• a Wintun instance was unloaded and another was loaded during the session;
• network drivers can corrupt unrelated kernel memory asynchronously.

But there is still no direct evidence naming Wintun.

Driver Verifier was not active

text
Verify Flags Level 0x00000000

(dump-analysis-2_182c_2026-07-11_19-14-38-451.txt)

Therefore, the dump contains no pool-allocation history or special-pool guard data capable of identifying which driver performed the original bad write.

One caution about 19041.1

WinDbg reports:

text
Windows 10 Kernel Version 19041
Edition build lab: 19041.1

(dump-analysis-2_182c_2026-07-11_19-14-38-451.txt)

That output identifies the base Windows 10 kernel branch but does not reliably show the installed cumulative-update revision. It does not by itself prove that your computer is still running the original 2020 release.

Use:

cmd
winver

or:

cmd
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" ^
 /v DisplayVersion

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" ^
 /v CurrentBuildNumber

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" ^
 /v UBR

The actual build is CurrentBuildNumber.UBR, for example 19045.xxxx.

Most likely mechanism now

The evidence points to this:

Windows was freeing a valid-looking temporary file-name buffer for DisplayCAL’s python27.dll. During heap-chunk coalescing, it found corrupted free-tree metadata. Either the buffer or adjacent heap metadata had previously been freed incorrectly or overwritten.

This raises the relative likelihood of two possibilities:

1. A bug in the old Windows kernel/object-name/heap path, possibly already fixed by a cumulative update.
2. Earlier corruption by an unrelated third-party kernel driver, detected later during the DisplayCAL/WerFault operation.

It does not make DisplayCAL, ntfs.sys, the disk, or the VSS file the leading culprit.

One final useful WinDbg check

The region we inspected at ffffcf85'497e7000 is the freed path-buffer area. The trap registers contain two other addresses that are more likely to be the actual corrupt tree links:

text
ffffcf85`44702038
ffffcf85`47cd9038

Run:

text
.logopen /t C:\Users\Public\dump-analysis-3.txt

!pool ffffcf8544702038
!poolval ffffcf8544702038
dt nt!_RTL_BALANCED_NODE ffffcf8544702038
dq ffffcf8544702000 L40

!pool ffffcf8547cd9038
!poolval ffffcf8547cd9038
dt nt!_RTL_BALANCED_NODE ffffcf8547cd9038
dq ffffcf8547cd9000 L40

!devstack ffffbf83b5468460
!vpb ffffbf83b31ddf00

.logclose

Those commands may reveal whether one tree pointer refers to a recognizable allocation or obviously invalid/freed memory. Even then, the original writer may remain unrecoverable.

Practical conclusion

Do not uninstall DisplayCAL or delete the VSS file based on this dump. The most sensible order remains:

1. determine the exact Windows build and update it if very old;
2. disable Clash Verge TUN mode and reboot as an A/B test;
3. remove unused VirtualBox and old virtual-disk drivers;
4. leave kernel dumps enabled;
5. use targeted Driver Verifier only if the crash recurs.

This second report strengthens the conclusion that it was a kernel heap/free-tree corruption discovered during a DisplayCAL file-name query, not an NTFS or physical-disk failure.

Yes—this new information changes the probability ranking significantly.

What the latest log adds

The two addresses involved in the red-black tree are both located inside freed 0xFB0 kernel-heap chunks. WinDbg reports both pool pages as invalid and identifies corrupt linked regions:

text
ffffcf85`44702030 — Free, size 0xFB0
ffffcf85`47cd9030 — Free, size 0xFB0

Pool page is INVALID
Corrupt region
Scanning for single bit errors...
None found

The two nodes are also linked together as parent/child entries in the free-chunk tree. (dump-analysis-3_182c_2026-07-11_19-30-17-205.txt) (dump-analysis-3_182c_2026-07-11_19-30-17-205.txt)

This strengthens the conclusion that the failure was:

corruption of the kernel heap’s bookkeeping for free memory chunks.

It is not simply a corrupt DisplayCAL filename buffer. The DisplayCAL query triggered the heap-coalescing operation, but the allocator’s internal tree was already inconsistent.

The fact that WinDbg could not explain it as a single-bit error slightly reduces—but does not eliminate—the likelihood of a random RAM bit flip. It is more compatible with:

• double-free;
• use-after-free;
• writing past an allocation boundary;
• incorrect heap metadata written by a driver;
• a kernel heap bug.

The VSS file is now less suspicious

The volume device stack is:

text
volsnap
volume
iorate
fvevol
volmgr

and the volume is simply your mounted Win10x64 volume. (dump-analysis-3_182c_2026-07-11_19-30-17-205.txt)

These are standard Microsoft volume drivers. There is no third-party snapshot or filesystem-filter driver in that particular device stack.

volsnap being present does not mean a shadow-copy operation caused the crash; it is normally attached to volumes that support VSS. Therefore, the huge file in System Volume Information remains relevant only as background storage activity, not as the demonstrated cause.

Windows 19041.450 is now a major suspect

19041.450 is an extremely early Windows 10 version 2004 build from the 2020 period. Version 2004 eventually reached build 19041.1415 before servicing ended on December 14, 2021, meaning your installation is missing a very large number of kernel, memory-manager, filesystem, networking, virtualization, and reliability fixes. (Wikipedia)

That matters because the failing functions are internal Windows heap functions:

text
RtlRbRemoveNode
RtlpHpVsChunkCoalesce
RtlpHpVsContextFree
ExFreeHeapPool

A kernel bug that existed in an early 2020 build—or an incompatibility between that kernel and later drivers—becomes much more plausible.

Even though many of your applications are old, not all drivers are equally old. The dump contained components from 2021, 2022, 2023, and 2024 running on a kernel patched only through 2020. That mixed environment is more concerning than “everything is old together.”

I would now put updating Windows ahead of Driver Verifier or extensive hardware replacement.

If staying on Windows 10, move at minimum to Windows 10 22H2, after making a full system image. Note that normal Windows 10 22H2 support itself ended on October 14, 2025, so Windows 11 or an applicable Extended Security Updates arrangement would be preferable for an Internet-connected system. (Wikipedia)

The RX 570 history is important

A graphics card intermittently failing the BIOS/POST stage cannot be caused by Windows, Clash Verge, VMware, or a Windows display driver. That strongly indicates a real pre-OS problem involving one or more of:

• the RX 570 itself;
• VRAM;
• PCIe contact or slot;
• auxiliary GPU power connector;
• power supply instability;
• GPU firmware/VBIOS;
• motherboard PCIe initialization.

Chrome freezing specifically when GPU acceleration was enabled is consistent with either GPU hardware instability or an AMD driver problem.

Could the RX 570 have caused this particular BSOD?

It is possible, but the dump does not prove it.

A PCIe GPU and its kernel driver can access system memory through DMA. In principle, defective hardware, bad DMA addressing, or a driver bug could overwrite unrelated kernel memory and cause a later crash in the heap allocator.

However:

• no AMD driver function is on the crashing stack;
• there is no dxgkrnl, dxgmms2, or amdkmdag execution frame at the failure;
• there is no recorded display TDR preceding the crash;
• the immediate operation was a kernel heap free during a WerFault query.

So the GPU should now be considered a moderate hardware suspect, rather than the leading explanation for this exact dump.

The BIOS POST issue is nevertheless serious enough that I would not ignore the card merely because it has recently behaved normally.

Best diagnostic sequence now

1. Make a full disk image

Before updating such an old installation, make a restorable image with software you trust. Also preserve your current VMware virtual machines and application configurations separately.

2. Update the operating system

The current kernel is too old to meaningfully distinguish “Windows bug” from “driver bug.”

An in-place upgrade that keeps applications and files is reasonable, but a clean installation provides a stronger diagnostic result. If compatibility with old software is critical, image the system first so you can return to the original state.

Do not enable Driver Verifier on 19041.450 first. It may expose bugs that have already been fixed in later Windows builds and could make the old installation difficult to boot.

3. Test without the RX 570

Your dump shows an Intel graphics driver was also loaded, suggesting that integrated graphics may be available.

For the strongest test:

1. Shut down and disconnect power.
2. Physically remove the RX 570, or set integrated graphics as primary in BIOS.
3. Connect the monitor to the motherboard output.
4. Use the machine under normal workloads.

Disabling the RX 570 only in Device Manager is a weaker test because the card still initializes during POST and remains physically connected to PCIe and power.

While inspecting it:

• reseat the card;
• inspect the PCIe contacts;
• reconnect the PCIe power cable;
• avoid adapters or splitters;
• inspect for overheating or damaged fans;
• consider testing with a known-good PSU or GPU.

4. After updating Windows, reinstall the graphics driver cleanly

Use either Lenovo’s validated graphics package or an appropriate stable AMD package for the RX 570. Do not retain a partially upgraded 2020 AMD driver installation after changing the operating-system build.

Change only one major variable at a time if you want a meaningful diagnosis.

5. Test Clash Verge separately

After the OS and graphics situation are stabilized:

• disable TUN mode;
• reboot;
• confirm that Wintun is no longer loaded;
• continue using VMware and ManicTime normally.

This isolates Clash without simultaneously removing everything.

6. Remove unused kernel drivers

The dump still contained numerous old drivers:

text
cbdisk3.sys
dokan.sys
imdisk.sys
phdskmnt.sys
deviodrv.sys
vhdaccess.sys
kprocesshacker.sys
VirtualBox drivers
VMware drivers

Uninstall parent applications you no longer use, rather than deleting .sys files manually.

Revised probability ranking

My current ranking is:

1. Early Windows 10 kernel plus old/new driver incompatibility
2. An unrelated third-party driver corrupting the kernel heap
3. RX 570 hardware, power, PCIe, or AMD driver corruption
4. Clash Verge/Wintun interaction
5. VMware/VirtualBox or virtual-disk-driver interaction
6. Intermittent system RAM fault
7. Physical disk, NTFS, or the VSS file

The RX 570 moves upward because failure during BIOS POST is genuine hardware-level evidence. But the extremely outdated Windows build moves even higher because the crash occurred inside kernel heap-management code and your system is missing years of fixes.

At this point, further WinDbg commands on this same dump are unlikely to reveal the original writer. The dump shows what was corrupted and where it was detected, but not who performed the earlier bad write. Updating Windows and testing without the RX 570 are now the two highest-value steps.

It absolutely could—but your six years of stability makes a pure, deterministic Windows-only bug less likely than I implied earlier.

The better distinction is:

• “Windows contains a latent bug” does not mean it crashes every time.
• “This crash was caused only by Windows” is not established by the dump.

Why a bug can remain dormant for years

Many kernel bugs are timing- or state-dependent. They may require an unusual combination such as:

• one specific allocation size;
• two adjacent free heap blocks;
• one exact order of allocation and release;
• two threads acting within a tiny timing window;
• a particular filename length;
• memory pressure or fragmentation;
• a driver loading/unloading at the same moment;
• WerFault inspecting a process while other kernel activity occurs.

Your crash occurred while the kernel was merging free heap chunks and found an invalid red-black-tree relationship. The corruption may have been created much earlier and only detected when WerFault.exe queried the DisplayCAL DLL name. (dump-analysis_1910_2026-07-11_19-06-45-922.txt)

That type of rare allocator-state bug can theoretically run millions of times successfully and fail once.

A simplified analogy: a program can contain a race condition for ten years, but unless two events overlap within a few microseconds, nothing visibly fails.

But your system has not actually been unchanged for six years

The Windows kernel stayed at 19041.450, but the loaded-driver environment did not.

The dump contains, among others:

• wintun.sys from 2021;
• VMware drivers from 2021;
• VirtualBox drivers from 2022;
• idmwfp.sys from 2023;
• Realtek Ethernet driver from 2023;
• npcap.sys from 2024;
• Intel display and audio drivers from 2024. (dump-analysis_1910_2026-07-11_19-06-45-922.txt) (dump-analysis_1910_2026-07-11_19-06-45-922.txt) (dump-analysis_1910_2026-07-11_19-06-45-922.txt) (dump-analysis_1910_2026-07-11_19-06-45-922.txt) (dump-analysis_1910_2026-07-11_19-06-45-922.txt)

So the real combination at the time of the crash was roughly:

2020 Windows kernel + drivers spanning 2013–2024 + recently changed Clash Verge + VMware running + aging RX 570 hardware

That is different from the configuration that originally ran in 2020.

This matters because an old Windows build may work perfectly with its original drivers but encounter a compatibility edge case when a later driver assumes behavior fixed or changed in newer Windows builds.

The new Clash Verge can change heap timing without being directly faulty

Even if Clash/Wintun did not overwrite the kernel heap itself, adding a service, virtual adapter, network threads, handles, and allocations changes:

• system memory layout;
• allocation order;
• timing;
• interrupt activity;
• process startup order;
• driver load/unload behavior.

That can expose an old bug elsewhere.

So there are at least two possibilities:

1. Clash/Wintun contains the bug.
2. Clash merely changed timing sufficiently to expose a dormant bug in Windows, VMware, another driver, or aging hardware.

The dump cannot distinguish these because Wintun is not on the crashing stack.

Hardware aging also explains “why only now”

Your RX 570 failing POST on some occasions is important. POST occurs before Windows loads, so that symptom cannot be explained by a Windows kernel bug.

Electronic components can deteriorate gradually due to:

• thermal cycling;
• weakened solder joints;
• aging capacitors or voltage regulation;
• VRAM instability;
• marginal PCIe signal integrity;
• power-supply degradation.

A card can appear stable for months and still occasionally produce an invalid DMA write or system freeze. The fact that Chrome hardware acceleration previously froze the machine also keeps the GPU or GPU driver in consideration.

However, the dump does not directly implicate the AMD graphics stack, so this remains plausible rather than proven.

What six stable years actually tell us

They reduce the likelihood of:

A simple Windows bug that deterministically occurs during normal file-name queries.

They do not strongly reduce the likelihood of:

• a rare Windows race condition;
• interaction between an old kernel and newer drivers;
• a third-party use-after-free;
• a driver unloading/reloading edge case;
• aging GPU or PSU behavior;
• a one-time transient corruption.

Revised interpretation

I would no longer rank “Windows itself” alone as the clear number-one cause.

A more balanced ranking is:

1. Rare third-party driver interaction or memory overwrite
2. Old Windows kernel interacting with newer drivers
3. Clash Verge/Wintun, because it is the recent software change
4. RX 570 hardware, PCIe, power, or AMD driver instability
5. A rare Windows-only kernel heap bug
6. System RAM
7. Disk, NTFS, or VSS

The outdated Windows build is important mainly because it makes diagnosis unreliable and leaves known fixes absent—not because the dump proves Windows caused the damage.

Given that this happened only once, the rational response is not to assume a specific culprit. Preserve kernel dumps, temporarily run Clash without TUN, and prioritize testing the suspect RX 570 or using integrated graphics. Updating Windows would reduce the number of already-fixed kernel bugs, but it would not prove what caused this particular crash.