How I Rescued My Dad's Work Files, Alvin Abyan

Human-friendly version? You might find this more interesting: My Dad’s Laptop Wouldn’t Start — And the 5‑Minute Fix That Saved Three Years of Work.

A day-long battle with blue screens, BitLocker, missing drivers, a Haiku-vs-Opus AI showdown, and the moment I finally stopped trying to save Windows and just saved what mattered.

The Problem

My dad's HP Laptop 14s-dq2614TU (669F1PA) wouldn't boot. It was stuck in a loop: a KMODE_EXCEPTION_NOT_HANDLED blue screen (STOP code 0x0000001E), followed by a failed Startup Repair screen pointing to SrtTrail.txt, followed by another crash. No Safe Mode. No recovery. Just a laptop full of work documents, including a folder called "Dokumen Kantor", and absolutely no way in.

The internal drive was a Samsung MZVLQ512HBLU-00BH1, a PM991a series OEM NVMe SSD. Not a consumer retail drive (like the 970 EVO or 960 PRO lines that Samsung provides drivers for), but an OEM part that relies on Microsoft's generic NVMe driver through the Intel RST controller. This distinction would matter later.

What followed was an entire day of troubleshooting, dead ends, and eventually a solution so simple I wish I'd tried it first. This article is my reflection on the whole experience: what went wrong, what I learned about how modern PCs actually work under the hood, and the approach that finally got my dad's files back.

Preparing the Tools: The Bootable USB Saga

Before I could do anything, I needed bootable media. I work on a MacBook Pro, so creating bootable USBs for Windows and Linux meant navigating macOS's quirks and limitations. I used Claude Code (Anthropic's terminal-based AI coding assistant) to help automate the process, which led to its own set of lessons.

Creating the Ubuntu Live USB (with `dd`)

The first USB I made was for Ubuntu. The idea was simple: boot a live Linux environment, mount the NVMe drive, and copy files off. Claude Code (running the Haiku model) helped me write the Ubuntu ISO to my HP v212w 15.5GB flash drive using dd:

sudo dd if=/Users/alvin/Downloads/ubuntu.iso of=/dev/rdisk6 bs=4m

A few things I learned here:

/dev/rdisk6 vs /dev/disk6: On macOS, /dev/rdisk is the raw disk device, which bypasses the buffer cache and writes significantly faster than /dev/disk. For large sequential writes like flashing an ISO, always use rdisk.

bs=4m (block size): This tells dd to read and write 4 megabytes at a time. Larger block sizes mean fewer I/O operations and faster throughput. The m suffix is lowercase on macOS's dd implementation (GNU dd uses M).

Monitoring progress with Ctrl+T: Unlike GNU dd on Linux (which supports status=progress or responds to SIGUSR1), macOS's dd shows progress when you send SIGINFO via Ctrl+T. It doesn't auto-update, you have to keep pressing it. Annoying, but functional.

The Ubuntu USB worked perfectly. Linux ISOs are hybrid images (thanks to isohybrid) designed to boot from both optical media and USB drives when written as raw block devices. This is why dd works flawlessly for Linux.

Creating the Windows 11 USB, Where Things Got Interesting

Windows ISOs are a different animal entirely. I initially tried the same dd approach with the Windows 11 ISO (Win11.iso, 7.2GB downloaded from Microsoft):

sudo dd if=/Users/alvin/Downloads/Win11.iso of=/dev/rdisk6 bs=4m

The write completed. The files were all there when I mounted the USB. But the laptop wouldn't boot from it, it got stuck at the manufacturer's logo after displaying "Press any key to boot from CD/DVD." This sent me down a rabbit hole.

Why dd doesn't work for Windows ISOs: Windows ISOs are not hybrid images. They're designed for optical media (UDF filesystem) and expect a proper bootloader setup on USB drives. When you dd a Windows ISO to a USB, you get a raw UDF image that lacks the FAT32/NTFS boot partition structure that UEFI firmware expects. The files are physically present but the boot chain is broken. Linux ISOs embed an MBR and a GPT in the ISO image itself; Windows ISOs don't.

The Haiku moment: I was running Claude Code with the Haiku 4.5 model at this point. Haiku confidently guided me through the dd approach, then when it failed, tried to install Balena Etcher (~400MB download) before I stopped it. When I asked Haiku to review what went wrong, it admitted: "That was my mistake, I should have known that dd doesn't work for Windows ISOs." I switched to the Opus model (claude --model opus) for the successful attempt.

The Correct Windows USB Method (with `wimlib`)

The Opus model immediately identified the real approach: format the USB as MBR/FAT32, mount the ISO, and copy the files over, with one critical extra step for the install.wim file.

The FAT32 4GB file size limit: FAT32 is the most universally bootable filesystem (both UEFI and Legacy BIOS can read it), but it caps individual files at 4GB (4,294,967,295 bytes, or 2³² - 1). The Windows 11 ISO contains install.wim, the Windows Image file containing the compressed OS, weighing in at 6.4GB. It doesn't fit.

The solution, wimlib-imagex split: Claude Code installed wimlib via Homebrew (brew install wimlib), then:

Formatted the USB as MBR/FAT32: diskutil eraseDisk FAT32 WIN11 MBRFormat /dev/disk6
Mounted the ISO (double-clicking on macOS mounts ISOs at /Volumes/CCCOMA_X64FRE_EN-US_DV9)
Copied all files except install.wim via rsync (862MB of bootloader, setup files, etc.)

Split install.wim into FAT32-compatible chunks:

wimlib-imagex split /Volumes/CCCOMA_X64FRE_EN-US_DV9/sources/install.wim \\
    /Volumes/WIN11/sources/install.swm 3800

This produced install.swm (3.7GB) and install2.swm (2.6GB). The .swm extension is the Split Windows Image format, the Windows installer recognizes it automatically and reassembles the image during setup.

MBR vs GPT for bootable USB: My first Haiku-guided attempt used GPT (GUID Partition Table), which is the modern standard for UEFI systems. But for maximum boot compatibility, especially on machines that might fall back to CSM/Legacy mode, MBR (Master Boot Record) with FAT32 is safer. Windows 11 requires UEFI for installation, but the USB boot media itself works better as MBR/FAT32 because every UEFI implementation can boot from FAT32, and MBR is a simpler boot path.

The Rabbit Hole: Everything I Tried (And Why It Failed)

Attempt 1: Windows Recovery Tools

The first instinct was to fix Windows itself. The built-in Windows Recovery Environment (WinRE) offers tools like Startup Repair, System File Checker (sfc /scannow), and DISM (Deployment Image Servicing and Management). The problem? My system was so corrupt that the recovery environment itself would either crash or fail silently.

What I learned: WinRE lives on a small hidden partition on your drive (typically 500MB–1GB, formatted as NTFS, with a winre.wim image inside). If the main Windows installation is severely corrupted, or if system files crash the scanner mid-way (mine froze at 18% repeatedly), WinRE can't help you. I also tried the old boot record repair commands from Command Prompt (bootrec /fixmbr, bootrec /fixboot, bootrec /rebuildbcd) and the offline system file check (sfc /scannow /offbootdir=C:\\ /offwindir=C:\\Windows). None survived long enough to complete.

Attempt 2: Reset This PC

Windows 11 has a "Reset this PC" feature that's supposed to reinstall the OS. I actually got to the "Getting connection ready" screen once, which felt like progress, but it failed too. The reset feature needs to either download a fresh copy of Windows from Microsoft's servers or use the local recovery image. My corrupted system couldn't sustain either process long enough.

What KMODE_EXCEPTION_NOT_HANDLED actually means: This is a kernel-mode crash. The "kernel" is the deepest layer of the operating system, it manages hardware, memory, and processes. When a driver or kernel-level program throws an exception (an unexpected error) that nothing catches, Windows has no choice but to stop everything. That's the blue screen. The error handler didn't catch it, indicating the fault was in Ring 0 code (kernel space), not Ring 3 (user space). In my case, something at the driver level was so broken that Windows couldn't even run long enough to repair itself.

Attempt 3: The Ubuntu Live USB Detour

Since Windows was a dead end, I pivoted to Linux. The plan was to boot the Ubuntu live USB I'd created earlier (the one made with dd, which did work correctly for Linux), browse the drive from outside Windows, and copy the files to an external drive. Simple in theory.

There were two problems.

Problem one: the drive was invisible. My dad's laptop has an 11th-gen Intel Core i3 processor (Tiger Lake architecture, codename TGL) with a technology called Intel Volume Management Device (VMD). VMD is an abstraction layer that sits between the NVMe SSD and the operating system, it virtualizes the storage controller so Intel can provide features like hot-plug support and LED management for NVMe drives. The Ubuntu kernel I was using didn't include the VMD driver (vmd kernel module), so it couldn't see the drive at all. I had to go into BIOS (F10 on HP laptops) and change the storage controller mode from RAID/RST to AHCI just so the operating system could talk to the hardware directly.

What's the difference between AHCI and RAID/RST? AHCI (Advanced Host Controller Interface) is the standard mode for SATA/NVMe drives, it lets the OS communicate with the drive directly via the standard NVMe/AHCI command set. Intel RST (Rapid Storage Technology) adds a layer on top for features like RAID arrays, Optane caching, and centralized management. When RST/VMD is enabled, the OS needs Intel's specific iaStorVD driver to see the drive. Disabling VMD and switching to AHCI removes that extra layer, making the drive visible to any OS with basic NVMe support (nvme kernel module).

Problem two: BitLocker. Once the drive appeared in Ubuntu, I discovered my dad's D: partition was encrypted. Windows 11 has a feature called "Device Encryption" that silently enables BitLocker-like encryption on many modern devices, even if you never asked for it. My dad never set up BitLocker manually, never logged into a Microsoft account (where the recovery key would normally be backed up), and the manage-bde -protectors -get D: command showed "No key protectors found." The partition was encrypted with no externally accessible key.

I tried dislocker (a Linux FUSE-based tool for mounting BitLocker volumes), it returned "Cannot parse volume header. Abort." The BitLocker metadata was corrupted.

The invisible encryption trap: This was the most frustrating discovery. Windows 11, on newer hardware with TPM 2.0 (Trusted Platform Module), can automatically enable Device Encryption during OOBE (Out-of-Box Experience) setup. The encryption key is silently sealed inside the TPM using Platform Configuration Registers (PCRs) and is supposed to be backed up to your Microsoft account. But if you set up Windows with a local account, that backup never happens. The encryption is there, it's protecting your data, and you might not even know it exists until you need to access the drive from outside Windows, at which point it becomes a wall. Check Settings → Privacy & Security → Device Encryption to see if it's on.

Attempt 4: Decrypt From Inside Windows

Since Ubuntu couldn't crack the BitLocker encryption, I went back to Windows. I changed the BIOS settings back to the original RST/VMD mode (because Windows was installed expecting that configuration, changing to AHCI after installation can cause a boot failure since the Windows registry still has the RST driver set as the boot-critical storage driver), forced my way into a barely-functional Windows desktop, and ran manage-bde -off D: to start decrypting the partition.

It started... and then the system crashed. Every time I tried to access the D: drive, the laptop would blue screen. The decryption got stuck at roughly 25%. I left it running overnight hoping it would inch forward, but the system was just too unstable.

Attempt 5: Clean Reinstall, Also Failed

At this point I thought: fine, I'll just wipe C: and do a fresh Windows install, then access D: from the new installation. But the Windows installer couldn't see my drive either, same VMD issue as Ubuntu. The installer doesn't ship with Intel VMD drivers.

I clicked "Load driver," browsed to the Intel RST driver I'd downloaded from HP's support page (sp111776.exe, extracted with 7-Zip into nested subfolders), selected the Intel RST VMD Controller 9A0B (TGL), TGL stands for Tiger Lake, and 9A0B is the PCI device ID for the Tiger Lake VMD controller, and the drive appeared. But the actual installation kept failing. It would get to 15% and crash. Corrupted partitions, bad sectors from all the forced shutdowns (the SMART diagnostic showed 63 unsafe shutdowns), or perhaps a storage space issue, I'm still not entirely sure.

I even considered using diskpart from Shift+F10 to clean the disk and repartition, but that would have destroyed the D: partition I was trying to save.

What iaStorVD means: During this process I kept seeing this filename in the driver folders. iaStorVD stands for Intel (i) Advanced (a) Storage (Stor) Volume Management Device (VD), it's the actual driver file (iaStorVD.inf / iaStorVD.sys) that tells the Windows installer how to communicate with your NVMe drive through Intel's VMD layer. The driver folders had three versions:

F6, For use during Windows Setup, named after the legacy F6 key shortcut from the floppy disk era when you'd press F6 to load SCSI/RAID drivers at install time. Contains just the bare .inf and .sys files.
dchu_VMD, The full VMD driver for installing after Windows is running. DCHU stands for Declarative, Componentized, Hardware Support Apps, and Universal, Microsoft's modern driver packaging standard (introduced with Windows 10 1809).
dchu_Hsa, The Hardware Support App component. This is the companion service layer that enables Intel Optane Memory and Storage Management UI on top of the driver.

The F6 version is what you need during installation.

The Solution That Actually Worked

After a full day of failed attempts, I woke up the next morning and decided to stop trying to rescue Windows. I didn't need the operating system. I just needed the files.

Step 1: Boot the Windows Installer

I booted from the Windows 11 USB installer I'd created with wimlib, not to install Windows, but to get access to its environment. The Windows Setup program is actually a minimal version of Windows called Windows PE (Preinstallation Environment). It's essentially a stripped-down Windows kernel with a basic shell, running entirely from RAM after loading from the USB. It has a command prompt, basic file management, and, crucially, the ability to load third-party drivers.

Step 2: Load the Intel VMD Driver

When the installer reached the "Where do you want to install Windows?" screen, my dad's NVMe drive was invisible, just like before. I clicked "Load driver," browsed to the F6 folder containing the Intel RST VMD driver (iaStorVD.inf), and selected Intel RST VMD Controller 9A0B (TGL). The drive appeared immediately.

Tip: If you see both Intel RST VMD Controller 9A0B (TGL) and Intel RST VMD Managed Controller 09AB in the driver list, pick the first one. The 9A0B device ID matches Tiger Lake (11th gen). The 09AB is a different platform.

Why this matters: The Windows installer environment, once you load the right driver, can see and interact with your drive, even if the Windows installation on that drive is completely broken. You're essentially borrowing the installer's mini-operating system to do file operations.

Step 3: Open Command Prompt

Instead of proceeding with the installation (which I knew would fail), I pressed Shift + F10. This opens a Command Prompt window directly from the Windows installer. From here, I had full access to the file system.

Step 4: Copy the Files

I plugged in my external SSD, which appeared as F:. My dad's files were on E: (drive letters in the Windows PE environment don't always match what they were inside Windows, PE assigns letters sequentially based on partition order and type). I ran:

xcopy "E:\\Dokumen Kantor" "F:\\Dokumen Kantor" /E /H /I

The flags: /E copies all subdirectories including empty ones, /H includes hidden and system files, and /I tells xcopy the destination is a directory (suppressing the "Is this a file or directory?" prompt). You could also use robocopy "E:\\Dokumen Kantor" "F:\\Dokumen Kantor" /E for the same result, robocopy (Robust File Copy) is generally more reliable for large transfers and can resume if interrupted, with automatic retry logic.

Scrolling in Windows PE Command Prompt: You can use Page Up / Page Down to scroll, or Ctrl+Home to jump to the top of the buffer. If you need more scrollback, right-click the title bar → Properties → Layout → increase the Screen Buffer Size height.

The files copied successfully. Three years of my dad's work documents, recovered in under five minutes once I had the right approach.

But Wait, What About the Encryption?

This is the part that surprised me. Remember, Ubuntu couldn't read the D: partition because of BitLocker. But the Windows installer environment, running from the USB, with the VMD driver loaded, could see the files on the encrypted partition without asking for a recovery key.

Here's why: the TPM chip. BitLocker Device Encryption uses the TPM to automatically unlock the drive during a trusted boot sequence. The TPM stores the Volume Master Key (VMK) sealed against specific PCR (Platform Configuration Register) values, measurements of the boot chain including the UEFI firmware, bootloader, and early boot components. The Windows PE environment on the USB, combined with the laptop's own TPM hardware, was apparently sufficient to satisfy the trust chain. The TPM recognized the hardware as legitimate and released the encryption key transparently. This wouldn't have worked from Ubuntu because Linux doesn't participate in the Windows TPM trust chain, the PCR measurements don't match.

This is also why the files were accessible even though manage-bde had shown "No key protectors found", the TPM-based protector was handling things silently at the hardware level, below what the software-level commands could report in the laptop's degraded state.

The Bigger Picture: A Day of Technical Rabbit Holes

The file recovery wasn't the only thing I was doing on February 7th. Between troubleshooting sessions, I was also:

Scanning my home network using arp -a (which reads the ARP cache, the mapping of IP addresses to MAC addresses on the local subnet) and nmap (Network Mapper, installed via Homebrew) to discover devices on my 192.168.100.0/24 network. Found 27 active devices. Each MAC address's first three octets (the OUI, Organizationally Unique Identifier) identify the manufacturer: dc:a6:32 maps to Raspberry Pi Foundation (Broadcom).

Setting up a Raspberry Pi 4 Model B that I'd forgotten the password to. Found it at 192.168.100.56 via mDNS (raspberrypi.local). The Pi 4 uses a Broadcom BCM2711 SoC (System on Chip), you can confirm the model by checking the .dtb (Device Tree Blob) files on the boot partition: bcm2711-rpi-4-b.dtb = Pi 4 Model B. I reflashed the SD card using Raspberry Pi Imager. The SD card has two partitions: a FAT32 boot partition (~537MB, containing the kernel, device tree, and config.txt) and a Linux ext4 root partition (~5.9GB, containing the actual OS filesystem). macOS can mount FAT32 natively but cannot read ext4 without third-party drivers.

Installing Claude Code on the Raspberry Pi via npm, which turned into its own debugging session. The global npm install failed with permissions issues (a classic Linux problem), fixed by creating a custom prefix directory (mkdir ~/.npm-global && npm config set prefix '~/.npm-global'), then adding the bin directory to $PATH in .bashrc. Hit a nested directory bug where bin/ and lib/ ended up in ~/.npm-global/npm-global/ instead of ~/.npm-global/, fixed with mv npm-global/* . && rm -rf npm-global. A reminder that even simple package installations on ARM Linux can have unexpected PATH and permissions quirks.

The point of mentioning all this: every one of these tasks exercised the same fundamental skill, understanding the layers between software and hardware. Whether it's dd writing raw blocks to a disk, VMD abstracting NVMe controllers, BitLocker sealing keys in TPM PCRs, or npm resolving PATH lookups through shell configuration, it's all about knowing which layer you're operating at and what each layer expects.

Key Takeaways

Don't get tunnel vision on fixing the OS. I spent hours trying to repair, reset, and reinstall Windows. The goal was never to have a working Windows, it was to get the files out. Once I reframed the problem, the solution was straightforward.
The Windows installer is a powerful recovery tool. You don't need Linux, third-party tools, or a second computer running a specialized recovery OS. The Windows installer's PE environment + Command Prompt + the right storage drivers can do the job.
Intel VMD is the silent gatekeeper. On modern Intel laptops (11th gen / Tiger Lake and newer), VMD acts as a middleman between your NVMe drive and the OS. Without the right driver (iaStorVD), your drive is invisible, to the Windows installer, to Linux, to everything. Always have the Intel RST driver handy. You can get it from your laptop manufacturer's support page (for my HP, it was sp111776.exe) or directly from Intel. Extract with 7-Zip, look for the F6 subfolder.
Windows 11 silently encrypts your drive, and that can bite you. Device Encryption activates automatically on hardware with TPM 2.0. If you use a local account instead of a Microsoft account, your recovery key may never get backed up anywhere. The TPM-sealed key is invisible to manage-bde when the system is degraded. Check Settings → Privacy & Security → Device Encryption to see if it's on. If it is, back up your recovery key immediately.
dd works for Linux ISOs but NOT for Windows ISOs. Linux ISOs are hybrid images with embedded MBR/GPT structures. Windows ISOs are UDF optical disc images. For Windows, you need to format the USB (FAT32 with MBR), mount the ISO, copy the files, and handle install.wim splitting if it exceeds 4GB. Use wimlib-imagex split on macOS.
Shift + F10 is the most underrated shortcut in Windows. During any Windows Setup screen, Shift + F10 opens Command Prompt. From there you can run diskpart, xcopy, robocopy, chkdsk, manage-bde, or pretty much anything else. It's your emergency Swiss Army knife.
Keep a Windows installer USB in a drawer. It costs nothing. A 16GB flash drive with the Windows 11 installer is the single most useful recovery tool you can have for a Windows PC. On macOS: install wimlib via Homebrew, format the USB as MBR/FAT32 with diskutil eraseDisk, mount the ISO, rsync everything except install.wim, then wimlib-imagex split the WIM file into .swm chunks under 4GB.
Know your models. I used Claude Haiku 4.5 for the initial USB creation, it led me down the dd path that works for Linux but not Windows, and then tried to download Balena Etcher when that failed. Switching to Claude Opus gave me the wimlib approach immediately. For complex multi-step technical tasks, the reasoning capability of the model matters. (Though Haiku was perfectly fine for the Ubuntu USB and Raspberry Pi setup.)
SMART data tells you the truth. Running smartctl -a /dev/nvme0n1 from Ubuntu confirmed that my dad's SSD was physically healthy, 100% available spare, zero data integrity errors, only 1% wear. The 63 unsafe shutdowns explained the file system corruption. The hardware was fine; it was the software that broke. That gave me confidence to keep trying rather than give up and send it to a professional data recovery service.

Technical Glossary

KMODE_EXCEPTION_NOT_HANDLED: Kernel-mode BSOD: an unhandled exception in Ring 0 code
SrtTrail.txt: Startup Repair Trail log, indicates WinRE repair failed
NVMe: Non-Volatile Memory Express, protocol for SSDs via PCIe
VMD: Volume Management Device, Intel's NVMe abstraction layer
AHCI: Advanced Host Controller Interface, standard storage mode
RST / IRST: (Intel) Rapid Storage Technology, Intel's storage driver layer
iaStorVD: Intel Advanced Storage Volume Device driver
TPM 2.0: Trusted Platform Module, hardware security chip for key sealing
PCR: Platform Configuration Register, TPM measurement slots
VMK: Volume Master Key, BitLocker's per-volume encryption key
BitLocker: Windows full-disk encryption, can be TPM-sealed
WinRE: Windows Recovery Environment
Windows PE: Windows Preinstallation Environment, minimal Windows from USB
wimlib: Open-source library for manipulating WIM (Windows Image) files
.swm: Split Windows Image, WIM chunks for FAT32 compatibility
.wim: Windows Image format, compressed OS image
MBR: Master Boot Record, legacy partition table scheme
GPT: GUID Partition Table, modern UEFI partition table
FAT32: File Allocation Table (32-bit), 4GB file size limit
exFAT: Extended FAT, no practical file size limit, cross-platform
NTFS: New Technology File System, Windows native
ext4: Fourth Extended Filesystem, Linux native
UDF: Universal Disk Format, optical disc filesystem
dd: Data Duplicator, raw block-level copy tool
/dev/rdisk: macOS raw disk device, bypasses buffer cache for faster I/O
bs=4m: Block size parameter for dd (4MB per read/write op)
SIGINFO / Ctrl+T: macOS signal to query process status (dd progress)
isohybrid: Tool that makes ISOs bootable from both optical and USB media
DCHU: Declarative, Componentized, Hardware Support Apps, Universal
TGL: Tiger Lake, Intel's 11th-gen CPU microarchitecture
9A0B: PCI device ID for Tiger Lake VMD controller
diskpart: Windows CLI disk partitioning tool
diskutil: macOS CLI disk management utility
manage-bde: BitLocker Drive Encryption CLI management tool
dislocker: Linux FUSE tool for mounting BitLocker volumes
FUSE: Filesystem in Userspace, Linux kernel module for custom FS
nmap: Network Mapper, network discovery and security scanning
arp -a: Display ARP cache (IP ↔ MAC address mappings)
OUI: Organizationally Unique Identifier, first 3 MAC octets
mDNS: Multicast DNS, .local hostname resolution (Bonjour/Avahi)
BCM2711: Broadcom SoC used in Raspberry Pi 4 Model B
.dtb: Device Tree Blob, hardware description file for ARM Linux
SMART: Self-Monitoring, Analysis and Reporting Technology (disk health)
OOBE: Out-of-Box Experience, Windows initial setup wizard
CSM: Compatibility Support Module, UEFI legacy BIOS fallback
UEFI: Unified Extensible Firmware Interface, modern BIOS replacement
Ring 0 / Ring 3: CPU privilege levels, kernel mode vs user mode
rsync: Remote (and local) file synchronization tool
robocopy: Robust File Copy, Windows advanced file copy utility
xcopy: Extended Copy, Windows file copy with subdirectory support
sfc /scannow: System File Checker, scans and repairs Windows system files
DISM: Deployment Image Servicing and Management
bootrec: Boot Record repair utility (fixmbr, fixboot, rebuildbcd)
chkdsk: Check Disk, Windows filesystem integrity checker
7zz: 7-Zip CLI, archive extraction (used for .exe driver packages)
npm prefix: npm config setting that controls global install location
$PATH: Shell environment variable listing executable search directories
.bashrc: Bash shell configuration file, sourced on interactive login

Final Thoughts

Looking back, the successful approach was almost embarrassingly simple compared to everything else I tried. Boot from USB. Load driver. Open command prompt. Copy files. Done.

But I don't regret the long road. I now understand what VMD does and why drives disappear. I understand that BitLocker Device Encryption can be invisible and dangerous. I know the difference between AHCI and RST mode, between the F6 driver and the DCHU driver, between iaStorVD.inf and the management layers above it. I know that dd writes raw blocks and that's why it works for Linux ISOs (which are hybrid images) but not Windows ISOs (which are UDF). I know that SrtTrail.txt means Startup Repair has given up, and that a system crashing at the same SFC percentage every time means the corruption is in the specific files being scanned at that point.

I also learned that AI models aren't interchangeable for complex tasks, Haiku is fast and great for straightforward operations, but for multi-step technical troubleshooting with edge cases, Opus's deeper reasoning made the difference. And I learned that sometimes the most productive thing you can do is sleep on it and reframe the problem in the morning.

Most importantly: I got my dad's files back. The "Dokumen Kantor" folder is safe on my external SSD. And the next time a Windows PC goes down, mine, my dad's, anyone's, I know exactly where to start.

How I Rescued My Dad's Work Files From a Broken Windows 11 Laptop, And What I Learned Along the Way