Blog

I’ve been installing Windows software the same way since the late nineties: download the ZIP or the EXE, run it, click Next four times, untick the bundled toolbar, done. For most of that time a package manager felt like overkill for a single desktop. Two years of running both Winget and Chocolatey side by side on Windows 11 changed my mind, but not in the way the package-manager evangelists promised.

Here is what actually happened when I stopped hand-installing everything and let two competing tools manage my machines.

The pitch, and why it matters for people who fix Windows

The core problem package managers solve is not convenience for its own sake. It is reproducibility. When I rebuild a machine, I do not want to hunt down fourteen installers from fourteen different sites, each with its own setup wizard and its own idea about where to put a desktop shortcut. I want a list I can feed to a command and walk away from.

Both Winget and Chocolatey do that. What separates them is where the packages come from, who approves them, and how much the tool quietly assumes about your system. Those differences become obvious only after you have broken something and had to fix it.

Winget: the one Microsoft ships

Winget (App Installer) is baked into modern Windows 11 and tied to the Microsoft Store’s package manifests. That is its biggest strength and its biggest limitation.

The strength: it is already there, it is signed by Microsoft, and its repository pulls from the vendors’ own installers rather than repackaged copies. When I tell it to install 7-Zip or Notepad++, I am getting the same binary the project ships, minus the wrapper nonsense. The manifest just points at the official URL and verifies the hash. That is a clean model, and it means fewer surprises about what is actually landing on disk.

The limitation: it only knows what Microsoft’s community has catalogued. Popular free utilities are almost always there. Niche tools, older drivers-adjacent utilities, and anything that looks like a system tweaker? Often missing, or present only as a manifest somebody abandoned two years ago. I have typed winget search more times than I can count and come up with a version that has not been touched since 2022.

Winget’s update story is decent but not automatic. You run winget upgrade --all and it does its thing. In my experience it handles the simple case well and chokes on anything with a custom uninstaller or a per-machine vs per-user install split. When an installer fights back, Winget tends to fail the same way a manual run would: silently or with a cryptic exit code.

Chocolatey: the older, more opinionated workhorse

Chocolatey predates Winget by years and it shows, in both directions. The good direction: it has a huge catalogue, including the messy system tools that Winget refuses to touch. The bad direction: it is a third-party service with its own conventions, its own PowerShell helpers, and a strong opinion that the community should package everything.

That mean repackaging. Chocolatey often wraps the vendor installer in its own script, and that wrapper can do things you did not ask for: creating directories, registering environment variables, or pulling dependencies you were not expecting. Most of the time this is fine. Occasionally it is exactly the kind of change I spend a weekend untangling.

What I like about Chocolatey is the chaining. Its install scripts handle the real-world case where a program needs a runtime library underneath it. If something wants a particular C++ redistributable, the package can declare that dependency and the tool resolves it. Winget mostly expects the vendor installer to sort that out itself, and sometimes the vendor does not.

Where the two tools actually differ in practice

After two years, the split in my own usage is clear:

• Winget for the everyday stuff: 7-Zip, Notepad++, IrfanView, Rufus, HWiNFO, Audacity, and the other free utilities that make up most of a working Windows box. These are the tools that keep showing up on “must-have” lists, and Winget has near-perfect coverage of them.
• Chocolatey for the awkward middle layer: runtime libraries, command-line tooling, and the handful of programs that need a scripted install to behave. Anything where a plain setup wizard leaves you clicking through dialogs you have seen a thousand times.

That is not a marketing split. It is what survived contact with real machines.

The driver and Device Manager problem

Neither tool touches drivers. Winget can list some driver-related packages but it will not update the PCIe chipset driver on your motherboard, and Chocolatey does not pretend otherwise. If driver trouble is your reason for wanting a package manager, neither answer. You still need Device Manager and the vendor’s own updater, or a dedicated driver updater. Do not let either tool’s package list trick you into thinking otherwise.

The uninstaller question

Both can uninstall what they installed, cleanly, as long as you installed it through them. The moment you install a program by hand and later ask a package manager to remove it, you are relying on the tool finding the vendor’s uninstaller and guessing the right silent flags. That sometimes works. When it does not, you fall back to the Windows uninstaller or a dedicated uninstaller, and you are right back where you started.

My rule: if a program goes on through a package manager, it comes off through the same one. Mixing the two is how you end up with orphaned registry entries and a folder in Program Files nobody can explain.

What I would tell someone starting now

If you are on a fresh Windows 11 install, start with Winget. It is already there, it is Microsoft-signed, and it covers the free-utility tier almost completely. Learn winget search, winget install, and winget upgrade --all before you reach for anything else.

Add Chocolatey when you hit a wall. That wall will probably be a runtime library, a command-line tool, or a program whose vendor installer refuses to run unattended. Do not install both on day one just to compare. Run Winget for a few weeks. Notice what it cannot do. That list is your reason to add the second tool.

And keep your expectations modest. A package manager is not a driver updater, it is not a system cleaner, and it will not fix a broken install that went sideways before it ever got involved. In two years and a few hundred installs, the real value was the scriptable rebuild: a list of packages I can replay on a new machine. Everything else is convenience, and convenience is worth less than a clean uninstall when a program misbehaves.

Winget won my default slot. Chocolatey earned its place as the backup that handles the jobs Winget quietly refuses. That is the honest verdict after two years: not a rivalry, a division of labor.

Patch Tuesday goes wrong more often than Microsoft‘s release notes admit, and when it does, the failure mode is usually the same: the machine restarts, the spinning dots appear, and then nothing. No login screen. No error code worth typing into a search box. Just a boot loop or a black frame staring back at you.

I have kept a running log of these incidents on my own hardware and on machines friends dragged over to my desk. Six of them stand out, and each one taught a slightly different recovery lesson. Here they are, roughly in the order I hit them, with the fix that actually worked.

1. A monthly rollup that left the system on “Getting Windows ready”

This one is the most common shape of the problem. A cumulative update installs, the machine reboots, and then hangs on the “Getting Windows ready” screen indefinitely. The update essentially failed to finish committing, and the boot process is stuck waiting for it.

The fix that reliably works is a hard power-off, then booting into the recovery environment (hold Shift while clicking Restart, or interrupt the boot three times on a machine that will not cooperate). From there, Troubleshoot > Advanced options > Uninstall Updates lets you remove the most recent quality update. The system reboots cleanly after that. You can then reinstall the update later if you want, though I usually wait a cycle to see whether the next cumulative build covers it.

Keep a note of the KB number before you uninstall. Microsoft’s own guidance points to the Update history page under Settings > Windows Update, and having the number makes it far easier to check whether the issue is a known one or something local to your machine.

2. Broken Always On VPN after a security update

Microsoft has confirmed that Always On VPN connections may break after installing the September 2026 security patches for Windows 11. This is the sneaky class of breakage: the machine boots fine, the desktop loads, but remote workers discover the VPN tunnel will not come up, and from their perspective the laptop is “broken.”

Recovery here is not about booting, it is about isolating the update. If you can boot into Safe Mode with Networking, test the VPN there. If it works, the update is the culprit. The practical fix is to uninstall the offending security update, block it temporarily, and pin the machine to a working state until Microsoft ships a repair. That is annoying in a security context, but a laptop that cannot reach the corporate network is worse than one missing a single month’s patches. Note which update you removed so you can reinstall it once a fix cycle lands.

3. A driver update bundled into Windows Update that killed display output

Not every bad boot comes from a security patch. Windows Update occasionally pushes GPU drivers through the optional updates channel, and on older cards this has produced a boot that gets as far as the login screen and then flickers to black. The machine is alive, you just cannot see it.

Boot into Safe Mode (which loads the basic display driver) and open Device Manager. Expand Display adapters, right-click the GPU, and choose Roll Back Driver. If the button is greyed out, uninstall the device and let Windows re-detect it on the next boot. This is also the moment to visit the vendor’s own site and grab the correct driver package rather than trusting the one Windows chose. A clean install from the manufacturer usually sticks. I have seen this fix hold for months on an old ThinkPad.

4. A failed feature update that corrupted the boot configuration

Feature updates (the big version bumps) can fail midway and leave the boot configuration data damaged. The symptom is a “Boot device not found” or a recovery screen listing error codes you have never seen. The Windows partition is intact, the bootloader just cannot find its way to it.

From the recovery environment, open a command prompt and run bootrec /fixmbr, then bootrec /fixboot, then bootrec /rebuildbcd. In most cases the rebuild step finds the Windows installation and restores the entry. If it does not, you may need to run bcdboot against the system partition manually. This is the point where having a USB recovery drive you made in advance saves you a very long evening. Make one. It takes ten minutes and it is the single best insurance policy against this class of failure.

5. Antivirus and update interacting to produce a boot-time hang

Third-party security software sometimes intercepts file operations during the update’s commit phase and the two deadlock. The result is a machine that hangs at the vendor splash screen with no progress. The tell is that the update installed but the machine never reaches the desktop.

Boot into Safe Mode, uninstall the third-party antivirus, and let the machine start normally with Windows Security in place. Once it boots, reinstall a fresh copy of the antivirus from the vendor’s site. Clean reinstall beats repair here every time. Going forward, I pause Windows Update long enough to disable real-time protection before a major feature update, then re-enable it after. It is a small manual step that has saved me two support calls.

6. Storage full during the update’s staging phase

The most avoidable of the six. Updates need free disk space to stage files before the reboot. If the drive is nearly full, the update can fail partway and leave the machine unable to finish the commit, producing a boot loop.

Boot to recovery, open a command prompt, and delete temp files with cleanmgr or by clearing the %temp% and SoftwareDistribution folders. Then reboot. Windows will usually complete the pending update once there is room. The lesson is to keep at least 20 GB free on the system drive at all times. Storage Sense (under Settings > System > Storage) can handle the routine cleanup automatically, and it is worth turning on.

The habits that actually prevent these

Three things have consistently saved me from disaster. First, a bootable recovery USB made from the same Windows build, kept current. Second, a folder of notes with the KB number, the date, and what you changed, because without that you are guessing. Third, a pause before installing updates on any machine you depend on for work. Delaying by a week or so lets other people find these bugs first, and Microsoft’s release notes rarely tell you everything that broke.

None of this is glamorous. But if you keep a working recovery drive, know where the Uninstall Updates menu lives, and remember that bootrec exists, you can turn a dead laptop into a twenty-minute fix. That beats waiting on hold to confirm the machine is plugged in.

Every Windows feature release lands the same way in an office: someone in IT clicks “check for updates,” and by Friday half the building is running a different build than the other half. Windows 11 25H2 is rolling out now, and before you push it to a room full of workstations, there are a few things worth checking on a test box first. I’ve been burned by enough “minor” updates to stop trusting the label.

This isn’t a review of 25H2. It’s the checklist I actually run before rolling a Windows feature update across machines that people depend on to do their jobs. Driver state, installer paths, privacy defaults, startup load. All of it matters more on a fleet than it does on your personal laptop.

Confirm the driver baseline before you touch the build number

Feature updates have a nasty habit of refreshing device drivers. Sometimes that’s fine. Sometimes your print server driver, your USB dock firmware, or that one weird NIC in the conference room stops cooperating. The safe move is to snapshot your driver state before the update and compare after.

Open Device Manager and look for any yellow bangs. If you’ve been ignoring a problem device for six months, fix it now. An update on top of a broken driver stack is how you end up with machines that won’t wake from sleep.

• Export your current driver list using pnputil /enum-drivers from an admin prompt, or a tool like DriverView. Keep the output somewhere you can compare it to.
• Check manufacturer pages for your specific model. Dell, Lenovo, and HP usually publish a “Windows 11 25H2 supported” note within weeks. Update regularly, per every reasonable guide on the topic.
• Do not use a driver updater on production machines right before a feature update. If a driver updater pushes something broken, you’ve now got two variables to debug at once.

I’ll say it plainly: the week of a feature update is the wrong week to “refresh all drivers.” Hold that maintenance window.

Audit what launches at startup, because 25H2 will re-enable some of it

Feature updates have a well-documented tendency to bring back things you deliberately disabled. Edge startup boost. OneDrive auto-launch. Teams (still). A feature update on a machine with a dozen startup entries turns a five-second login into forty seconds, and the user blames you, not Microsoft.

Before you push, walk each machine’s startup list in Task Manager (Ctrl+Shift+Esc, Startup tab) and note what’s enabled. After the update, walk it again. Then trim. Startup program management is the single highest-return cleanup you can do on a fleet, and it’s low-risk. Disabling a startup entry doesn’t uninstall anything. If something breaks, you re-enable it.

Pair that with Storage Sense on your image. It’s built into Windows 11 under Settings > System > Storage and clears temp files and Recycle Bin automatically. On a fleet, that alone keeps the C: drive from silently filling between updates.

Lock down diagnostics defaults before deployment, not after

Here’s the thing that actually annoys me about feature updates: privacy defaults sometimes reset to “send optional diagnostic data.” That’s the drop-down you turned off in Settings > Privacy & security > Diagnostic & feedback six months ago. Optional data includes app activity and can include browsing history. Microsoft’s minimum required data is not optional, but the extra stuff is.

On a single PC, you’d just open Settings and turn off the optional toggle plus “Improve inking and typing.” On a fleet, do it with Group Policy or a registry policy, so the update can’t quietly undo your work. If you’re not running domain policy, a tool like Windows Privacy Dashboard or O&O ShutUp10 still handles this in a couple of minutes on a per-machine basis, and each setting is described in plain language. I keep one around for one-off boxes.

Worth saying directly: turning these off won’t break functionality. That’s the source I trust most on this point. It’s just less data about your users leaving the building.

Sanity-check your installers and install paths

Before you upgrade fifty machines, run your full app install script on one test machine running 25H2. I’ve watched feature updates break silent installer flags, mangle paths under Program Files, and cause setup wizards to trip over a changed environment. None of that shows up in a “supports Windows 11” claim on a vendor’s site.

On my own test box I install the usual stack: 7-Zip for archive handling, the standard Visual C++ Redistributable bundle and DirectX runtime for the older games and CAD tools that still expect them, and whatever management agent the org uses. Runtime libraries are the classic silent failure. A machine that “runs fine” until someone opens a legacy app and gets a missing DLL is a machine that wasn’t tested properly.

Also verify your uninstall paths. Windows 11’s Settings > Apps has been the default uninstaller for a while, but feature updates sometimes orphan registry entries. Run an installer, confirm it launches, uninstall it cleanly. If the uninstaller leaves junk behind, fix your script now, before it’s on fifty machines.

What I’d actually do on rollout week

• Pick one sacrificial machine. A user who tolerates a reboot, ideally someone using the same apps and hardware model as your trouble cases.
• Update it, reboot twice, then log in and open every app that matters. Twice. The second reboot catches things the first one misses more often than you’d think.
• Compare Device Manager, startup list, and privacy toggles against your pre-update snapshot.
• Then stage the rollout in small batches. Ten machines, live with them a week, expand.

The Windows 11 25H2 push is not scary. It’s just a feature update, and feature updates are exactly where small configuration drift turns into a helpdesk ticket queue. Do the audit before the roll-out, not after, and the rollout is quiet. That’s the only outcome you want to hear about from the office.