Your "fully updated" PC is probably running a 2011 driver

There is a particular kind of fault that wastes weeks: intermittent, hard to reproduce, and coming from a component everyone assumes is fine because the machine says it is up to date.

Drivers are the usual culprit, and the reason is structural.

Windows Update is not a driver manager

Windows Update will install a driver when a device has none. After that, it largely leaves well enough alone. If a device is functioning — even poorly — Windows has no strong incentive to replace a working driver with a newer one, because a driver swap is exactly the kind of change that turns a working machine into a broken one.

The result is that machines accumulate drivers that are technically functional and years out of date. Microsoft's generic in-box drivers are the worst offenders, because they exist to make hardware work at all, not to make it work well.

We recently traced a machine's Wi-Fi problems to an adapter running a Microsoft in-box driver dated 2011 on an 802.11ac adapter — a standard that did not exist in 2011. The vendor's current driver had been sitting in Windows Update as an optional offer the entire time.

The symptom pattern

Old drivers rarely fail outright. They produce:

• Intermittent disconnects that recover on their own, so nothing looks broken for long
• Performance well below spec that gets blamed on the ISP or the hardware
• Instability under specific conditions — a particular encryption mode, a power state, a heavy load
• Event log entries nobody reads, describing the fault precisely

That last one is the way in. On the machine above, the Wi-Fi log had recorded 110 disconnects in a fortnight, each one saying The network is disconnected by the driver — the driver announcing, in plain language, that it was the one dropping the connection.

Find out what you are actually running

Check the driver, not the device:

Get-NetAdapter | Select-Object Name, InterfaceDescription, DriverVersion, DriverDate, DriverProvider

DriverProvider: Microsoft on a third-party device is a strong hint you are on a generic in-box driver. A DriverDate more than a few years old on anything wireless, graphical or storage-related deserves a look.

Then check what is on offer:

Get-WindowsUpdate  # or Settings > Windows Update > Advanced options > Optional updates

Vendor drivers frequently sit under Optional updates, where nobody looks, for years.

Installing them without breaking things

A driver change is a real system change. Treat it like one.

• Know the revert path before you start. Device Manager → the device → Driver → Roll Back Driver restores the previous one. That option exists only if the previous driver is still staged, which it will be immediately after an update.
• Keep a second route to the machine. If you are replacing a network driver, make sure you have another way on — a cable, another adapter, physical access.
• Verify from the system afterwards, not from the installer's exit code. Read the version back:

Get-CimInstance Win32_PnPSignedDriver | Where-Object DeviceName -match 'YourDevice' |
  Select-Object DeviceName, DriverVersion, DriverDate, DriverProviderName

If the version did not change, the install did not work, whatever the installer said. We have watched an update report success while the payload was never downloaded and the driver never changed. The read-back caught it; the exit code did not.

Measure the fix, do not assume it

Record the fault rate before and after. For a network driver, count the disconnect events in the previous 24 hours, then count again a day later. A fix that reduces a fault from 24 occurrences a day to three is a real improvement — and also not a cure, which is worth knowing rather than declaring victory.

That discipline matters because driver problems are intermittent by nature. Without a before number, any quiet period looks like success.