The Half-Speed Laptop

My laptop has been running its Wi-Fi at half speed. The faster driver was already sitting on the hard drive the whole time, fully installed, and Windows had simply never switched over to it.

• ASUS Zenbook A16
• Windows 11
• September 2026

This is what I found on my Zenbook A16. It is a field note, not a general Windows bug report.

I hadn't noticed anything wrong. The laptop is quick, the drive is mostly empty, and nothing was obviously broken. I asked Claude Code to run a full health check mainly as a precaution, half expecting to be told everything was fine.

Most of it was. The drive was healthy with 758 GB free out of 951, antivirus was on and current, Windows had all its patches, and no hardware was reporting faults. The battery turned out to be nearly new, with only 16 charge cycles on it.

Then two of my assumptions turned out to be wrong.

The crash that never happened

The event log showed the laptop had shut down unexpectedly at half past midnight a couple of days earlier. That's the kind of thing that makes you nervous, because it usually means a hardware fault or a serious driver bug.

Looking at the actual record, though, the crash code was zero and a separate flag said the power button had been held down. Someone had force-powered the machine off by holding the button, which Windows logs in almost the same way as a genuine crash. This laptop has never had a blue screen in its life. What it had was a moment where things froze up badly enough that holding the power button seemed like the reasonable move.

That distinction matters. A real crash means you go hunting for a faulty component. A held power button means you go looking for whatever made the machine hang, which is a much narrower search.

Programs that forgot to leave

The first genuine problem was memory. About 73% of it was in use, and a large slice belonged to five background processes left over from Android Studio, which I'd closed hours earlier. The program was gone but its helper processes were still sitting there holding nearly 3 GB between them.

This is a common pattern with development tools. They start background helpers to make builds faster, and those helpers are designed to stick around between builds. When the main program exits without cleaning up, the helpers keep running indefinitely with nothing to do.

Clearing the idle ones brought memory use from 73% down to 56%. Worth doing, though hardly dramatic.

Software from the manufacturer, falling over repeatedly

ASUS ships a lot of extra software on its laptops. One of those programs, a photo organiser called StoryCube, had crashed five times in seven days. Two others had crashed once each. None of them do anything I use.

Turning off four of these background services was straightforward. The important part was being selective, because some manufacturer software genuinely matters. The service that runs the touchpad and the one that handles fan speed, function keys and battery settings both had to stay. Switching those off to save a few megabytes would have broken real hardware features.

The part I didn't expect

Every piece of hardware in your computer needs a driver, which is a small program that lets Windows talk to it. Drivers get updated, and updating them normally happens without you noticing.

My Wi-Fi driver was from December 2025. A much newer version from May 2026 had been downloaded and installed onto the drive back in August, as part of an official ASUS update package. Windows had accepted the file, stored it in the driver store, and then continued using the December version anyway. The new driver had been sitting on my hard drive for weeks, fully staged, doing nothing.

Switching the Wi-Fi adapter over to the version already sitting there took a few seconds and no reboot. On the same access point, same band, and same spot in the room, my connection speed doubled.

• Before: 573 Mbps
• After: 1.2 Gbps

I'd been running at roughly half the speed my hardware supports since December, on a laptop I bought partly for its fast Wi-Fi. Nothing had failed. No error appeared anywhere. The update log even recorded the new driver as successfully installed, because it was: the package was on the disk. Windows had not made it the active driver.

Why this is easy to miss

Windows chooses drivers by matching hardware against a set of rules, and a newer version number doesn't always win that comparison. When the old driver keeps being selected, nothing is reported as broken, because from the system's point of view nothing is. The package really did install. It just never got switched on.

"Installed" here means the files landed in the driver store. "Running" means Windows has chosen that package for the device and loaded it. Those are two different facts. The log only records the first one.

Then it found 29 more

Once we knew what the problem looked like, it was worth checking whether anything else had the same thing wrong with it. Twenty-nine more drivers turned out to be in exactly that state, with a newer version installed and unused.

Twenty-two of them belonged to one group handling power and temperature management, including the chip's temperature sensors and the components that decide how hard the processor is allowed to work. Those were four months out of date while a newer version sat unused on the drive.

I'd been asking about the laptop running hot earlier that same afternoon, so this looked like an obvious culprit. It probably wasn't. The heat had a much simpler explanation, which was a software build using four processor cores at full speed. Two findings turning up in the same conversation doesn't mean one caused the other, and it would have been easy to draw a satisfying conclusion that happened to be wrong.

Switching those over was still the right call. Running four-month-old temperature management code when the current version is already installed has no upside. That is a reason to switch them. It is not evidence that they caused the heat.

Making it a habit

A one-off check finds whatever happens to be wrong that day. The Wi-Fi driver had been stuck since December and would have stayed stuck indefinitely, because nothing was ever going to raise a flag about it.

So the last step was turning the whole check into a script that runs every Monday morning. It saves its results each week and compares them against the previous run, which means it reports what changed rather than repeating the same list. It watches for the things worth watching:

• Drivers installed but not actually in use
• Background programs left running after their parent closed
• Battery capacity dropping over time
• New programs quietly adding themselves to startup
• Errors appearing more often than last week

It reports and suggests, without changing anything on its own.

Building it surfaced one last useful mistake. My first version of the script asked Windows which driver each device was using, and got told the old one, even for drivers that had already been switched successfully. There are two different answers to that question, because Windows distinguishes between the driver it has chosen and the driver currently loaded in memory. Until you restart, those disagree. I'd briefly reported a fix as failed when it had worked perfectly.

"The update installed successfully" and "the update is running" turn out to be two separate facts, and your computer only ever tells you about the first one.