I thought I was doing something simple: reset my Windows laptop and start fresh.
What followed wasn’t just troubleshooting. It was an unexpected education in how modern computers boot, how storage is abstracted, and why operating systems behave the way they do when even one assumption is violated.
By the time Windows finally installed, I didn’t just have a clean system. I had a mental model of how the whole stack fits together.
This is what I learned.
Resetting Windows is not the same as reinstalling it
I began with Reset this PC, choosing Remove everything. The wording strongly implies a blank slate.
It wasn’t.
After the reset, the same partitions were still there. Recovery layouts survived. The disk structure looked largely unchanged. That’s when the first misconception broke:
Resetting Windows is an OS-level repair operation, not a storage rebuild. It reinstalls system files but intentionally avoids touching partition layouts, firmware expectations, or recovery structures. It’s designed to get a broken system running again — not to erase history.
I also tried Disk Management, but could not restore it to a factory version as a recovery partition was in between two different partitions I wanted to merge.
I had tried Local Install, Cloud Install and install from a Recovery USB. I thought the recovery USB might show an option to format and erase partitions, but it’s just a recovery image of the then present system. So no luck there either.
If you want to actually start over, you need to leave the running OS behind entirely.
A “clean install” that felt unfinished
I decided to perform a clean install of Windows using the Windows Media Creation Tool and making a bootable USB. The windows license was tied to the computer’s unique hardware ID — so if someone else were to use it with a different account, it would not cause any problems.
However, booting from a Windows installation USB felt like stepping back in time.
The mouse pointer was invisible. The trackpad didn’t work. Bluetooth was useless. Wi-Fi didn’t exist. I had to use a basic wireless USB mouse and rely on the keyboard to navigate setup screens. Later, I needed an Ethernet cable just to get online.
This wasn’t a bug. It was a design choice.
A truly clean Windows installer ships with almost no drivers. Just enough to display graphics, accept keyboard input, and talk to very generic USB devices. Everything else — touchpads, Wi-Fi chipsets, Bluetooth stacks — is considered vendor territory and deliberately excluded.
At this point, Windows wasn’t broken. It was just brutally minimal.
BIOS, UEFI, and why booting isn’t “magic”
What most people still casually call “BIOS” is almost always UEFI (Unified Extensible Firmware Interface, early 2000s), the modern replacement for the original BIOS (Basic Input/Output System, late 1970s).
Both serve the same fundamental purpose: they run before the operating system and decide how the OS is loaded. But their philosophies are completely different.
BIOS was simple and linear. It jumped to a fixed location on disk and hoped something bootable lived there. UEFI is structured, modular, and far more opinionated. It expects a clearly defined boot process and refuses to improvise.
The modern boot chain looks like this:
Power On→ UEFI firmware → EFI System Partition → Boot Manager → Operating System → Drivers
Once I understood this, many of the errors I saw stopped feeling arbitrary. The system wasn’t failing randomly — it was enforcing rules.
MBR, GPT, and why Windows refused to install
Disk layout turned out to be one of those rules.
MBR (Master Boot Record, 1983) is the old partitioning scheme designed for early PCs. It has hard limits: small disk sizes, few partitions, and no redundancy. It worked because early hardware was simple.
GPT (GUID Partition Table, early 2000s) exists because everything outgrew MBR. GPT uses GUIDs (Globally Unique Identifiers, 1990s) to uniquely identify disks and partitions, stores multiple copies of critical data, and scales to modern storage sizes.
UEFI expects GPT. No exceptions.
So when Windows complained about MBR vs GPT, it wasn’t being picky — it was refusing to create a fragile system. Booting in UEFI mode from an MBR disk is a mismatch, and Windows simply will not proceed.
This was my first real glimpse of Windows’ philosophy: if something is structurally wrong, it won’t try to “make it work.”
AHCI, RAID, and the abstraction I didn’t know existed
Storage controller modes were the next rabbit hole.
AHCI (Advanced Host Controller Interface, 2004) is the straightforward way an operating system talks to a disk. The OS sees the drive directly and manages it itself. Simple, transparent, predictable.
RAID (Redundant Array of Independent Disks, 1987) was originally about combining multiple drives for speed or redundancy. On modern laptops, however, RAID often means something subtler.
My system used Intel RST (Rapid Storage Technology, late 2000s) with VMD (Volume Management Device, ~2019). This inserts an abstraction layer between Windows and the SSD:
Windows ↔ Intel RST / VMD driver ↔ NVMe SSD
Without the correct driver, the disk technically exists — but Windows is not allowed to fully control it. That single detail explained almost everything: why partitions were visible but locked, why DiskPart couldn’t see the drive, and why delete options were greyed out.
Nothing was broken. The OS was simply missing a translator.
When one driver changes everything
Once I manually loaded the correct Intel RST VMD driver during setup (after adding it to the USB and restarting the process, although, I think, it can be done using a different USB as well), the system instantly transformed.
Partitions became editable. The disk appeared correctly everywhere. GPT conversion succeeded. Installation moved forward without complaint.
That moment was oddly satisfying. It made something very clear:
Modern systems don’t degrade gracefully. They either operate within their rules — or they stop you entirely.
Deleting everything, correctly
With the storage layer finally unlocked, I deleted every partition on the internal SSD — EFI, MSR, recovery, OEM restore, old Windows — until only unallocated space remained.
Windows then rebuilt what it needed on its own. This wasn’t destructive recklessness; it was the cleanest possible starting point.
Seeing ~476 GB instead of 512 GB briefly caused panic, until I learned the difference between decimal and binary units. The space wasn’t missing. It was just being counted honestly.
The partitions Windows recreates (and why they matter)
After installation, Windows recreated a small set of partitions automatically: an EFI System Partition for booting, an MSR (Microsoft Reserved) partition for internal disk management, and a Recovery partition for repair tools.
They look mysterious, but they’re infrastructure. Delete them during installation if you want a fresh slate — never afterward.
The final irony: drivers make the computer usable
After Windows finally booted, it still didn’t feel like a laptop.
No trackpad. No Wi-Fi. Device Manager full of unknown devices.
Only after installing drivers — via Ethernet, Windows Update, and OEM tools — did the system feel “normal” again. The operating system was functional long before the computer was.
That distinction stuck with me.
What I walked away with
Before this, I thought booting was automatic, storage was simple, and resetting meant wiping.
Now I understand that modern computing is layered, cautious, and rule-driven. Firmware, disk formats, controller modes, and drivers all have to agree — or nothing proceeds.
Windows didn’t fight me because it was fragile. It fought me because it was precise.
And once I learned its language, everything finally made sense.
Leave a Reply