iamnor

My C:\ drive had been screaming at me for three days.

Not the polite sort of Windows whining where the storage bar turns red and you tell yourself you’ll deal with it later. The angry kind. The kind where OneDrive stops syncing, the browser chokes trying to write a temp file, and you start looking at installed games like a Depression-era accountant deciding which child gets soup.

So I did what we all do. I went hunting.

Temp files. Browser caches. Downloads. Stray ISO images. A VM snapshot I absolutely meant to move to the NAS months ago. This is not new territory for me. I’ve been doing this dance since back when defrag animations were practically screen savers and every machine eventually developed that one mysterious directory you were afraid to look inside.

I clawed back a few gigs here, a few there. Enough to buy time, not enough to solve the problem. The numbers still didn’t make sense. This box is barely a year old. A 1TB system drive should not already feel like an asthmatic hamster.

Then I found the body.

C:\Windows\Installer.

Sixty-five gigabytes.

On a one-year-old build.

If you’ve never had the pleasure, C:\Windows\Installer is where Windows Installer keeps copies of MSI and MSP packages for installed products and patches. And when I say “keeps,” I mean “hoards like a paranoid dragon.” It does not clean up after itself. It does not revisit past decisions. It does not wake up one morning and decide that maybe those installers from three product versions ago no longer need to occupy a meaningful percentage of your boot drive.

It just accumulates. Layer after layer. Geological strata made out of bad lifecycle hygiene.

Naturally, I did the thing you’re supposed to do. I searched to see whether cleaning it up manually was safe.

The internet, to its credit, responded the way the internet always responds when somebody asks if it’s okay to start deleting things inside Windows system directories: with a lot of terrified screaming.

Fair enough.

Delete the wrong files from C:\Windows\Installer and you can absolutely ruin your day. Break Windows Update. Break repair operations. Break uninstall paths. Break some future patch process in a way that won’t show up until six months from now, on a Tuesday, five minutes before an important meeting.

So no, I was not about to go full caveman and del /s /q my way into a rebuild.

The recommended options were the usual cast of underwhelming characters.

Disk Cleanup. I ran it. It found about enough space to store a medium-resolution JPEG and a handful of bad decisions.

DISM /Online /Cleanup-Image. Also ran it. Also largely useless.

Then there was the only actually sensible answer: PatchCleaner.

PatchCleaner, for those unfamiliar, does the thing Windows should probably do itself. It cross-references the contents of C:\Windows\Installer against Windows Installer registrations and identifies the files that are still referenced versus the ones that are just dead weight.

That is the right approach.

So I went looking for PatchCleaner.

And that’s where the real story starts.

Finding a free Windows utility in 2026 is less a software search than a trust obstacle course. Every path looks wrong. The first promising hit led to a GitHub repository that might have been legitimate, or might have been the digital equivalent of a guy in an alley whispering, “psst, hey kid, want a privileged executable?”

The next few results all had the same smell: polished pages, suspiciously enthusiastic download buttons, and that familiar aggregator-site vibe where the real product is buried underneath a mile of SEO sludge and at least three attempts to sell you malware wearing a necktie.

Eventually I found what looked like the real site. Real developer. Real product page. Real-looking download.

So I pulled the installer.

Then, because I’m me, I threw it at VirusTotal before I ran anything.

Two engines lit up.

Just two.

And yes, rationally, I know what that usually means. Two detections out of seventy-something is very often noise. Heuristic engines get weird around administrative utilities, installers, low-volume tools, and anything that touches system directories in a way marketing departments would describe as “advanced optimization.” PatchCleaner lives squarely in that neighborhood.

But that’s the problem, isn’t it?

The tool I needed would require Administrator privileges on the exact machine I cared about, with access to a system directory that could ruin my week if mishandled. And to justify running it, I would have had to spend real time validating provenance, inspecting signing, reviewing source if the source was even available, interpreting the detections, evaluating the site, and deciding whether I trusted the entire chain enough to hand it the keys.

At that point the trust exercise had become more expensive than the original storage problem.

So I crossed the river.

I opened Claude Code and told it to build me a Python utility that would scan C:\Windows\Installer, enumerate registered MSI products and patches via Windows Installer COM and the registry, normalize paths, resolve 8.3 names, and classify files as known, orphaned, or unknown.

A few minutes later I had a working tool.

Not a toy. Not a proof of concept held together with duct tape and optimism. A real tool.

It enumerated products through WindowsInstaller.Installer COM, walked HKLM\...\Installer\UserData across the SIDs, handled SQUID-to-GUID conversion, resolved short paths, normalized everything for comparison, and produced a clean table showing what was referenced, what was orphaned, and what kind of space recovery I was looking at.

I ran it.

It found ~40GB of orphaned installer garbage.

I spot-checked the classifications against the registry, reviewed the logic, then moved the orphaned files into an archive directory instead of deleting them outright, because I may be reckless but I’m not stupid.

Nothing broke.

My C:\ drive is breathing again. I got back roughly 40GB. The screaming stopped.

That part is satisfying. It is not, however, the interesting part.

The interesting part is this: I am a security guy. Vetting software is part of the job. Thinking adversarially about provenance, trust, privilege, and blast radius is not some exotic side hobby for me. It is the work.

And even with that background, the effort required to get comfortable with a random third-party utility was higher than the effort required to build a narrowly scoped replacement myself.

Read that again, because two years ago it would have sounded ridiculous.

A utility that correctly interacts with MSI COM, crawls the registry, handles compressed GUID weirdness, cleans up path edge cases, and presents sane results used to be the kind of thing you squeezed in over a weekend if you were feeling optimistic and self-destructive.

Now? It’s a prompt, a review pass, some hardening, a little testing, and a second pass where you remove the dumb AI mistakes before they become your dumb mistakes.

That’s a very different world.

And the river here is not “AI helped me write code.” That’s old news. Plenty of us crossed that one a while back.

The river this time was different.

I used AI to replace a trust decision.

I didn’t need to bet on some random binary from the internet.

I didn’t need to play archaeological detective through download sites, code-signing details, forum posts, and VirusTotal chatter just to solve a stupid disk-space problem.

I could describe the utility I wanted, generate it, read every line, test the behavior, harden the rough edges, and know exactly what the thing was doing because the entire codebase fit inside my head.

That changes the economics.

This is not an argument against open source. It is not an argument against shared tooling. That would be nonsense. Modern computing runs on layers of other people’s code, and anybody pretending otherwise is either lying or writing everything in assembly while living in a cave (send me your address, I would love to come visit)!

What this is is an observation about a very specific class of problem: small, self-contained tools with ambiguous trust surfaces, often requiring elevated privileges, where the validation cost has become stupidly high relative to the underlying task.

In that space, AI shifts the equation.

Not because the model is magic.

Not because generated code is automatically safer.

And definitely not because you should blindly run whatever slop tumbles out of a prompt window.

It shifts the equation because for bounded problems, building has become cheap enough that building can be part of verification.

That is new.

Before, your options were roughly these: trust the binary, spend too much time validating the binary, or give up.

Now there is a fourth option.

Build the thing. Audit the thing. Own the thing.

That’s the Rubicon.

And I have a feeling I’m going to cross it again.

My Patch Cleaner can be found here.