Windows 11 File History Not Backing Up: Reconnect Your Drive

Microsoft currently lists a File History known issue for the September 2026 Windows security update KB5124008. On affected systems, File History can stop creating or updating backups even though the configured external drive or network target is still available. Microsoft added the issue to the KB5124008 documentation on September 19, 2026 and, as of September 21, says it is working on a resolution for a future Windows update.

The documented symptoms are unusually useful for diagnosis: Windows can incorrectly show “Reconnect your drive,” the Last Backup timestamp can stop advancing, previously backed-up files can show “No previous version available,” and Event Viewer can contain application crashes referencing FileHistory.exe and KERNELBASE.dll. If those symptoms began after the September update while the backup target itself remains reachable, the known issue is a stronger explanation than a genuinely disconnected drive.

Open Settings > Windows Update > Update history and check whether the problem began after the September 2026 security update. For Windows 11 24H2 and 25H2, Microsoft’s KB5124008 page identifies OS builds 26100.9445 and 26200.9445. Later cumulative updates can contain earlier fixes, but Microsoft’s current KB5124008 documentation still lists this File History issue as unresolved, so simply being on an update newer than September 8 does not currently prove that File History has been fixed.

That distinction matters because Microsoft separately resolved other September-update problems in updates released on and after September 14, including KB5129195 for 24H2/25H2. The File History entry has a different resolution status: Microsoft still says a fix is in development. Do not assume an emergency update that fixed Remote Desktop or other September regressions also fixed File History.

Before attributing the failure to KB5124008, verify the storage path independently of File History. For an external USB drive, confirm that Windows can open the drive and read ordinary files from it. Microsoft’s general File History guidance says a genuine Reconnect your drive warning can occur when the backup drive has been disconnected for too long, so a physically missing or unreadable drive remains a separate and valid cause.

For a network destination, verify that the share is reachable with the account and network state you normally use. Microsoft’s supported reconnect guidance says to open Control Panel > System and Security > File History and reselect the network location when a network backup target needs reconnecting. If the share itself is inaccessible outside File History, solve that storage or network problem first rather than diagnosing the September File History bug from the warning alone.

In Control Panel > System and Security > File History, note the displayed Last Backup time before testing. If the target is reachable, Microsoft’s normal reconnect procedure allows you to select Run now to start a backup manually. Recheck the timestamp and, where practical, verify that a recently changed test file becomes recoverable rather than relying only on a reassuring status message.

If Run now does not produce a new backup and the timestamp remains stale despite a working destination, that combination is consistent with Microsoft’s September issue. A successful new backup, by contrast, means the specific “unable to create or update backups” symptom is not currently reproduced, even if an earlier warning appeared.

Microsoft says some affected devices record application crash events referencing FileHistory.exe and KERNELBASE.dll. If File History stopped after the September update, checking the Windows application log for those names can add useful evidence. Record the event time and details if you may need to compare behavior after a future update.

The absence of that crash signature does not clear KB5124008: Microsoft says it occurs only in some cases. Likewise, seeing a FileHistory.exe error does not establish that the backup disk is healthy. Combine the event evidence with update timing, destination reachability, the Last Backup timestamp, and whether a manual backup completes.

Do not delete the existing FileHistory folder, format the backup drive, or discard an existing backup set merely to clear the warning. Microsoft’s known-issue description explicitly says previously backed-up files can incorrectly appear as though no previous version is available. That symptom is not evidence that the underlying backup files should be destroyed.

If the existing backup contains important versions, leave it intact while diagnosing the failure and avoid destructive “start over” steps unless you have separately verified the data you need and have a reason to rebuild the set. The current Microsoft known-issue entry does not publish a destructive reset procedure or a special registry workaround for this File History regression.

Microsoft’s current File History known-issue entry says a resolution is being developed; it does not instruct users to uninstall KB5124008 as the supported File History fix. Removing a security update also removes the security and reliability changes bundled with it, so that is not a neutral troubleshooting step.

Keep Windows Update current and re-check Microsoft’s KB5124008 known-issue status when a newer cumulative update arrives. Once Microsoft names a resolving update, install the supported update and then verify that File History can create a fresh backup, the Last Backup timestamp advances, and previous versions are visible again before considering the incident closed.

A Reconnect your drive message predates this September bug and can still mean exactly what it says. If the external disk repeatedly disconnects, is unreadable in File Explorer, or the network share cannot be reached normally, troubleshoot that path first. The same applies when the problem clearly began before the September update or follows a drive, enclosure, router, NAS, account, or network change instead.

A useful isolation result is whether the destination works outside File History. If ordinary access is broken, File History cannot compensate for it. If ordinary access is healthy but File History stopped updating immediately after the affected Windows update and shows Microsoft’s documented symptoms, avoid unnecessary storage surgery and track the Windows known issue instead.

For an unresolved case, record the Windows edition and version, OS build, installed September and later cumulative updates, whether the target is USB or network storage, whether that target opens normally outside File History, the Last Backup timestamp, the result of Run now, and any FileHistory.exe or KERNELBASE.dll application event. Those facts cleanly separate the update-regression branch from the storage-path branch.

As of September 21, 2026, there is no Microsoft-published resolution for this File History known issue. Treat any third-party registry edit, service reset, backup-set deletion, or claimed permanent workaround as separate advice unless Microsoft later documents it. The safest endpoint for a system that matches the known issue is preserved backup data, a confirmed reachable destination, current Windows updates, and a repeatable verification test ready for the resolving update.