Job Type
Recovery+ full rebuild
The owner had been working the whole time under a terminated employee's Windows profile. Nobody had ever set the machine up properly. So this wasn't just "reinstall Windows" — the files that mattered lived inside an account belonging to someone who didn't work there anymore, on a drive the installer refused to see, on top of an OS too broken to boot.
Two of the three machines were clean installs, done and packed the same afternoon. This writeup is about the one that fought back.
The extended time on this machine was the complexity of the job, not spinning wheels. I'm writing it up with the dead ends left in on purpose — the failed commands are the part that shows the work. Anyone can post the one command that fixed it. The value is knowing which five things to try first, and why they didn't take.
So the repair path was dead. The MBR fix took, but /fixboot threw Access Denied because it was a GPT disk, and bcdboot failed outright. The OS wasn't where a healthy machine would have it — it had ended up on D: in the recovery environment, corrupted past the point of an in-place fix. Repair was off the table. Now the priority flips: get the files off before anything gets wiped.
/ZB falls back to backup mode when it hits a permission wall — critical when you're copying out of an account you don't own. /COPYALL keeps every attribute and ACL intact. /R:1 /W:1 means one retry, one-second wait — you don't let it hang for hours on the 17 locked system files that were never going to copy anyway. The 250 MB that failed was all OS-owned junk. Every user file came across.
Once the file tree was verified against the source and the client signed off, the drive was cleared for wipe. You get written authorization before you erase anyone's disk. Then the real fight started.
This is the moment that turns a 20-minute reinstall into a half-day job. When Windows setup can't see a disk, most people assume dead hardware and quote a new drive. That's usually wrong — and it was wrong here.
Modern Intel platforms front the NVMe behind VMD — Volume Management Device. The stock Windows install ISO doesn't carry the driver for it, so the installer is blind to the disk. The drive isn't broken. The RAID mode isn't wrong. The installer is just missing one .inf file — and it won't get it on its own. You have to hand it the driver yourself.
The black-screen boot pegged the RAM and never gave me a desktop; forcing explorer.exe as admin did nothing. The shell was gone. That path was a dead end — but it's the kind of thing you try before committing to the longer route, because if it had worked it would've saved an hour. It didn't. On to the real fix.
That was it. One .inf file — iaStorVD_467F.inf — and the drive that had been invisible for two hours showed up like nothing was ever wrong. Cleared the old partitions, pointed the installer at a clean volume, and Windows 11 finally took.
The USB stick has to be GPT-formatted for a UEFI install to read the driver off it cleanly. Small thing, easy to miss, and it'll cost you another twenty minutes of "why still nothing" if you get it wrong. Every machine on this job needed a GPT stick for the UEFI boot to behave.
The skipped firmware is the part I'm most deliberate about. The update was offered, and it did not match the drive's controller. Half the skill in this work is knowing which update to skip — running everything the vendor offers is how you turn a working machine into a paperweight. Restraint is a technical decision.
Every clean-up tool refused in turn — the volume was "in use," diskpart's override didn't override, the recovery environment couldn't see the internal drives without its own RST driver, and bcdedit couldn't even open the boot config. But msconfig showed only one real boot entry, which told me the second was a stale UEFI pointer, not a live install. A full clean restart cleared it. The machine now boots straight to login.
The old partitions technically still exist on the disk, inert. No functional impact, no performance cost, and forcing them out would've risked the working install for zero real gain. Left them dead rather than take a risk for cosmetics.
A rebuild is a one-time fix. What I documented on the way through is the stuff that would break again in six months without a real process behind it:
The boot corruption, the invisible drive, the ghost accounts — none of that is bad luck. It's what unmanaged consumer hardware looks like a few years in, when nobody owns the security posture. I got called for three broken computers. What was actually broken was the absence of any process. The repair was Phase 0. The real work — identity, access control, offboarding, actual management — is where it goes from here.
Data recovery, driver-level rebuilds, and the security cleanup that should come after — from one engineer who does all of it. If a shop already told you the drive was dead, it's worth a second look.
Start a Conversation →