PC Troubleshooting Case Notes

My role

Mohamad owns the PC, reported the symptoms and approved each change. Claude (AI) ran the measurements, wrote the storage plan and executed the moves under his direction; he ran a couple of steps himself. No root cause for the crashes is recorded, so none is claimed.

What it is

These are three real troubleshooting records from a gaming and development PC. The first is a set of three blue screens whose crash dumps were analysed; the second is a storage emergency where the system drive had only 52 GB free; the third is a pair of memory exhaustion lockups that led to a written rule.

The common method is measure first, change one thing, then check. For storage, every move was verified by file count and size before anything was removed, and system files like the page file were left alone.

The crash analysis is output only: it shows what each dump pointed at, but no final fix is documented, so this page reports the findings and leaves the cause open.

How it was built

1. Collect the crash dumpsThree kernel minidumps from 2026-10-19, 2026-10-24 and 2026-10-29 were analysed and the output saved to a single text file (crash-analysis.txt, generated 2026-10-29 02:30).
2. Read the bugchecksTwo dumps show bugcheck 0x13A (kernel mode heap corruption) with the same stack in ntkrnlmp.exe version 10.0.26100.9711, failing inside the heap compaction work item. The third shows bugcheck 0x1E (unhandled kernel exception) blamed on BEDaisy.sys, the BattlEye anti-cheat driver, in an unloaded state.
3. Note the patternIdentical stacks on 10-19 and 10-24 point to one repeating fault rather than random events. The dump output records no conclusion or fix.
4. Measure the full system driveOn 2026-10-28 the 930 GB system NVMe drive had 52 GB free. Folder sizes were measured with robocopy list mode (junctions skipped), and a target of at least 300 GB free was set.
5. Rank by safetyItems were grouped: A (rebuildable caches and temp data), B (developer caches and Windows files), C (games, owner's choice). What must stay was written down too: the page file (16 GB), shader cache and Desktop project folders.
6. Move, don't delete, where possibleDeveloper caches (uv, pip, Go, npm) were redirected to the D: drive with environment variables; the After Effects disk cache path was changed by editing its preferences file with a backup; VirtualBox VMs moved with VBoxManage.
7. Verify every game moveThe Finals (943 files) and Escape from Tarkov (11,034 files) were copied and checked byte-identical before the originals were removed. Tarkov's registry path needed admin rights, so a junction was left at the old path.
8. Leave risky items to the ownerThe hibernation file needs admin rights, and live session temp folders (42 GB belonging to running sessions) were left alone.
9. Record the resultFree space went from 52 GB to 93 GB after the first batch and 355 GB after the After Effects cache and two games moved. The target of 300 GB was met.
10. Turn lockups into a ruleAfter PC freezes from memory exhaustion on 2026-10-07 and 2026-10-09, a rule was set to check committed memory headroom before opening Studio or starting heavy tests. A later lockup on 2026-11-05 happened with 53 GB committed against a limit near 26 GB; its cause is recorded as unproven.

Decisions and why

Move or redirect caches instead of deleting where possible

Caches are rebuildable and moving them keeps behaviour the same while freeing the fast drive.

Verify with file count and size before removing a source

A failed copy followed by a delete would lose data.

Keep the page file, shader cache and daily-use games on the fast drive

Moving them to the slower hard drive would cause stutter and slow loads.

Leave the hibernation file and live-session folders alone

One needs admin rights, the other is in use and deleting it could break running work.

Hardest problems

A game launcher stored its install path in a protected registry key that could not be changed without admin rights

Left a directory junction at the old path pointing to the new location on D:.

An old package cache was locked by a running process

Left for later with the exact clean command noted, rather than killing the process.

Repeated heap corruption bugchecks with an identical stack

Not recorded as fixed. Open question: whether a memory test or driver update was done.

Numbers

Timeline

• 2026-10-07 and 2026-10-09PC hard-froze from memory exhaustion with several apps open
• 2026-10-19Bugcheck 0x13A, kernel heap corruption
• 2026-10-24Bugcheck 0x13A again with the same stack
• 2026-10-28Storage plan written and run; free space 52 GB to 355 GB
• 2026-10-29Bugcheck 0x1E blamed on the anti-cheat driver; dumps analysed into one file
• 2026-11-05Memory lockup after starting parallel jobs; cause recorded as unproven

What I took from it

• Measure before changing anything, and write down what must not be touched as carefully as what can move.
• Verify copies by count and size before deleting the original.
• A repeated identical crash stack is a pattern worth chasing, but without a recorded fix it is an open case, not a success.