My Windows PC Died at 1% SSD Life — Here's How Linux + AI Saved Everything

My Windows laptop crashed hard and never came back. No boot device. Black screen. Nothing. I pulled the SSD, plugged it into my Linux machine via a USB enclosure, and opened a terminal with Devin running GLM-5.2 — a frontier AI model that would guide me through every step of this recovery.

What followed was a 6-hour adventure: SMART diagnosis, a crashed backup, an NTFS resize, a disk-to-disk clone, and three separate boot errors that each required a different fix. No Windows recovery media. No commercial tools. Just Linux, an AI assistant, and stubbornness.

The diagnosis: the SSD was dying

The disk showed up as /dev/sda with a standard UEFI Windows layout — EFI partition, MSR, and a 118.7 GB NTFS data partition. Everything read fine. The Windows folder was there, Users folder was there, all my files intact.

The AI suggested running SMART:

smartctl -A /dev/sda

Attribute 173 (Erase_Count) read 001 — one percent remaining write endurance. 34,644 power-on hours. 701 unexpected power-offs. No crash dumps written. The SSD had hit its write-endurance limit and was silently failing. Many SSDs go read-only at this point as a self-protection measure — which explains why Windows couldn't boot (it couldn't write boot state) but Linux could still read everything.

"1% write capacity is end of life, right? Should I clone?" I asked. The AI confirmed: yes, clone immediately, before the drive locks completely.

The plan: backup, shrink, clone

I had a replacement Kingston 120 GB SSD and a 3.6 TB IronWolf HDD on my Proxmox server (pve1). But the Kingston was 8 GB smaller than the dying Toshiba. A raw dd wouldn't fit. The AI laid out the plan:

1. Backup the dying disk to an image file on the IronWolf
2. Backup the Kingston's existing data (drone footage + photos) to the IronWolf as tar files
3. Shrink the NTFS filesystem and partition in the backup image
4. Clone the resized image to the Kingston
5. Fix the GPT backup header for the smaller disk

Step 1: dd the dying disk to the IronWolf

Connected all three disks to pve1 and ran:

dd if=/dev/sdd of=/mnt/ironwolf/windows-backup/windows_backup.img bs=64M conv=sync,noerror status=progress

Halfway through, the IronWolf's FUSE mount died — a USB device re-plug caused a brief controller reset that killed the ntfs-3g process. The dd died with 'Transport endpoint is not connected'. The AI diagnosed the FUSE crash, remounted the IronWolf, and resumed from the exact byte offset:

dd if=/dev/sdd of=...img bs=64M conv=sync,noerror iflag=skip_bytes skip=83217858560 oflag=append conv=notrunc

Full 128 GB image saved. Never restart a dd from zero if you can resume — the dying disk might not survive a second full pass.

Step 2: tar the Kingston's data

The Kingston had 67 GB of drone footage and photos. I was worried about wear on the IronWolf — it's a spinning HDD, and writing thousands of small files causes unnecessary head seeking. The AI suggested packaging each folder as a single uncompressed tar — two large sequential writes instead of thousands of random ones:

tar -cf /mnt/ironwolf/kingston_drone-jul.tar -C /mnt/sdc drone-jul
tar -cf /mnt/ironwolf/kingston_to-backup.tar -C /mnt/sdc to-backup

Verified with tar -tf — file counts matched the source. Safe to overwrite.

Step 3: shrink the NTFS in the backup image

Loop-mounted the image and shrank the NTFS filesystem from 118.7 GB to 110 GB:

losetup -f --show -P windows_backup.img  # -> /dev/loop0
ntfsresize -f -s 110G /dev/loop0p4

The NTFS only used 100 GB of data, so shrinking to 110 GB was safe. Then shrank the partition in the GPT from 118.7 GB to 105 GB using sgdisk:

sgdisk -d 4 /dev/loop0
sgdisk -n 4:1161216:221262175 /dev/loop0
sgdisk -t 4:0700 /dev/loop0

Step 4: clone to the Kingston

dd if=/dev/loop0 of=/dev/sdc bs=64M conv=sync,noerror status=progress

113 GB at ~40 MB/s over USB — about 47 minutes. Then fixed the GPT backup header:

sgdisk -e /dev/sdc

Boot error #1: 0xc0000225

Put the Kingston in the Windows laptop. Booted. Got error 0xc0000225 — Windows Recovery, 'Your PC needs to be repaired'.

The AI knew exactly what happened: when I recreated partition 4 with sgdisk, it got a new partition GUID. The Windows BCD still referenced the original partition GUID. The AI had read the BCD earlier with hivexget and remembered the original GUID. The fix was one command back on Linux:

sgdisk -u 4:CBBCF158-F7FE-468C-BFBE-8FB1D738FA41 /dev/sda

Put the Kingston back in the laptop. Booted. It worked! ...or so I thought.

Boot error #2: stuck at Welcome

Windows loaded past the boot manager, showed the "Welcome" screen, and just stayed there. For 20+ minutes. Fans going loud. Then a black screen with just a mouse cursor. Task Manager wouldn't open.

I plugged the Kingston back into Linux. The AI read the Windows registry using hivexget and found the problem: the PagingFiles registry key referenced pagefiles on three drives:

PagingFiles:
  - c:\pagefile.sys 16000 32000
  - d:\pagefile.sys 0 0
  - e:\pagefile.sys 16000 32000

Drives D: and E: no longer existed — they were on the old disk geometry. Windows was hanging trying to create pagefiles on phantom drives.

The fix: delete the stale pagefile.sys from the disk, then edit the registry to only reference C:. We used reged (from the chntpw package) to import a .reg file that replaced the PagingFiles value:

reged -I /tmp/SYSTEM_hive_reg 'HKEY_LOCAL_MACHINE\SYSTEM' /tmp/fix_pagefile.reg -C

Copied the fixed hive back to the disk. Booted. Windows got past "Welcome"... but then another surprise.

Boot error #3: black screen with working apps

Windows booted to a black screen with just a cursor. But this time, other apps worked. I could open Edge, watch YouTube, run commands. Just Explorer wouldn't load. The explorer.exe trick via Task Manager didn't work either.

I rebooted. And that did it. Windows loaded normally. The third boot was clean — Explorer loaded, desktop appeared, everything functional.

The theory: the first boot after the registry fix had run chkdsk and reconfigured the storage stack. The second boot was still processing those changes. The third boot was the clean one. Sometimes you just need to let Windows do its thing.

What I learned

• SMART attribute 173 (Erase_Count) is the one to watch on SSDs. When it hits 001, the drive is about to die. Back up immediately.
• Linux can read a dying SSD that Windows can't boot from. The data was 100% intact — only the boot chain was broken by the SSD going read-only.
• You can dd-resume from a byte offset with iflag=skip_bytes and oflag=append. Don't restart from zero.
• ntfsresize + sgdisk can shrink a Windows partition offline, letting you clone to a smaller disk without Windows.
• sgdisk recreates partitions with new GUIDs. The BCD references the old GUID. Always restore the original partition GUID after recreating, or you'll get 0xc0000225.
• Stale pagefile references in the registry can cause Windows to hang at "Welcome" after a disk clone. Check ControlSet001\Control\Session Manager\Memory Management\PagingFiles for drives that no longer exist.
• Sometimes you just need three boots. First boot runs chkdsk, second boot reconfigures, third boot is clean. Don't panic.
• tar with no compression is the kindest way to back up many small files to a spinning HDD — one sequential write, minimal wear.
• An AI assistant that can read SMART data, parse BCD hives, edit Windows registry from Linux, and diagnose boot errors is genuinely useful. Not because it knows everything, but because it can hold the entire state of the problem in its context and reason through each failure methodically.

The toolkit

All of this was done with tools available on any Linux system: smartctl, dd, ntfsresize, ntfsfix, sgdisk, losetup, tar, hivexget for reading the BCD, reged from chntpw for editing the registry. No Windows recovery media needed. No commercial tools. Just Linux, an AI assistant, and patience.

The dying SSD? It's in a drawer now. The Kingston is in the laptop, running Windows, with 6 GB of free space I can extend into later. And the full 128 GB image is on the IronWolf if I ever need it again.

Credit where it's due

This recovery was done with Devin running GLM-5.2 — a frontier AI model that guided each step: reading SMART attributes, diagnosing the FUSE mount crash, calculating partition sector offsets, reading the BCD with hivexget, identifying the GUID mismatch, parsing the Windows registry to find stale pagefile references, and knowing when to say "just reboot one more time." The AI didn't touch the hardware — I did. But having an assistant that could reason through three cascading boot failures without losing context was the difference between a 6-hour recovery and a trip to the repair shop.