Microsoft has confirmed a fix for a bug that broke the built-in File History backup feature on millions of Windows 10 and Windows 11 machines, closing out a nearly two-week saga that started with the September 2026 Patch Tuesday rollout. The company’s support documentation, updated on September 22, 2026, says the problem is resolved in updates released on and after that date, including KB5124010. BleepingComputer first reported the outage on September 21 and updated its coverage two days later as the fix rolled out.
The bug is a reminder of how fragile Windows’ patch cadence can be, and it lands the same month Microsoft pushed a record-breaking 966-bug Patch Tuesday. For a feature as basic as file backup, a two-week window of silent failure is more than a cosmetic annoyance: it is the kind of gap that turns a routine security update into a data-loss risk for home users and small businesses who rely on File History as their only backup layer.
Microsoft Confirms the September 2026 File History Outage
Microsoft’s own support documentation states that after installing the September 2026 Windows security update KB5124008, some customers using File History might be unable to create or update backups. That line, buried in a routine servicing-update page, is the company’s most direct acknowledgment of the bug. File History, the documentation notes, is the tool available through Control Panel > System and Security > File History, used to back up files to an external drive or network location.
The acknowledgment came days after the updates had already shipped. Microsoft’s September security releases went out on September 8, 2026, across the full Windows 10 and Windows 11 lineup. BleepingComputer’s report, credited to reporter Sergiu Gatlan, went live on September 21 once user complaints had piled up across Microsoft’s own Q&A forums and the Microsoft Community Hub. That is roughly a two-week gap between the update shipping and Microsoft publicly documenting the failure, a lag that matters when the broken feature is the one users depend on to protect their files.
What Exactly Broke: Symptoms Users Reported
The failure did not present as an outright crash for most users, which is part of why it took time to surface. Instead, File History degraded quietly. According to Microsoft’s support notes and threads on the Microsoft Community Hub, affected systems showed a mix of the following symptoms:
- An incorrect “Reconnect your drive” prompt appearing even when a compatible external or network drive was already connected and functioning normally
- The “Last Backup” timestamp in File History settings freezing and no longer updating after new backup attempts
- Previously backed-up files showing “No previous version available” when users tried to restore an older version
- Event Viewer logs in some cases recording application crashes tied to FileHistory.exe and KERNELBASE.dll
That combination is particularly disruptive because it fails silently in the worst way: the drive looks disconnected even though it isn’t, so a user checking their backup status sees an error that suggests a hardware or cabling problem rather than a software regression. Anyone who trusted the “Last Backup” timestamp without digging further could have gone nearly two weeks assuming their files were protected when new backups were not actually completing.
The Update Trail: Which KBs Triggered the Bug
The bug did not come from a single patch. Because Microsoft services multiple Windows 10 and Windows 11 branches in parallel, the same underlying regression shipped inside several differently numbered cumulative updates on the same day, September 8, 2026. BleepingComputer’s writeup and Microsoft’s own servicing pages line up on the following originating updates:
| Windows release | Originating update | Build number |
|---|---|---|
| Windows 11, version 26H1 | KB5124012 | Not specified by Microsoft |
| Windows 11, version 25H2 | KB5124008 | 26200.9445 |
| Windows 11, version 24H2 | KB5124008 | 26200.9445 |
| Windows 11, version 23H2 | KB5122880 | 22621.7582 |
| Windows 10, version 22H2 | KB5122878 | 19045.7725 |
| Windows 10, version 21H2 | KB5122878 | 19044.7725 |
| Windows 10 Enterprise LTSC 2019 | KB5122876 | Not specified by Microsoft |
| Windows 10 Enterprise LTSC 2016 | KB5123099 | Not specified by Microsoft |
The spread across eight separate KB numbers, covering releases as old as Windows 10 21H2 and as new as Windows 11 26H1, suggests the regression sat in a shared component rather than a version-specific driver. That lines up with the crash signature pointing at KERNELBASE.dll, a core Windows API library loaded by nearly every process, including the File History service.
Timeline: From Patch Tuesday to the Fix
Laid out chronologically, the incident moved through four distinct phases over roughly two weeks:
- September 8, 2026 — Microsoft ships its monthly security updates, including KB5124008, KB5122880, KB5122878, KB5122876, and KB5123099, across the affected Windows 10 and Windows 11 branches.
- Mid-September 2026 — Users begin posting in Microsoft Q&A and the Microsoft Community Hub describing File History failures.
- September 21, 2026 — BleepingComputer publishes its report, titled “Microsoft: September updates break File History backup feature.”
- September 22, 2026 — Microsoft updates its support documentation to formally list the known issue and ships the fix, KB5124010, resolving the problem for systems that install it.
- September 23, 2026 — BleepingComputer updates its report with the resolution details.
That timeline mirrors a pattern this site has tracked with other September 2026 software updates gone wrong. Just weeks earlier, a Samsung firmware update knocked out internet-connected refrigerators right before the Chuseok holiday, and Microsoft itself was mid-cycle on a Patch Tuesday that addressed 966 separate vulnerabilities. When vendors ship updates at that scale and cadence, the odds of a shared-component regression slipping through pre-release testing climb accordingly.
How Microsoft Fixed It: KB5124010 and the Retail Channel Rollout
Microsoft’s resolution came in the form of KB5124010, described in Microsoft Q&A threads as an optional update released on the Retail channel on September 22. Users who installed it reported that File History backup functionality returned to normal and that backups could once again be performed successfully. Microsoft’s own support notes confirm the fix ships in updates released on and after September 22, 2026, without singling out one KB number as the universal remedy across every affected branch, since the LTSC and older Windows 10 branches receive their own separately numbered servicing packages on a delayed schedule.
Before the fix reached general availability, Microsoft’s official status message said it was working on a resolution for the issue in a future Windows update and would provide more information when it became available. That kind of holding statement, common in Windows release-health documentation, tends to frustrate IT administrators who need a concrete timeline rather than an open-ended promise, especially when the affected feature touches data protection.
Affected Windows Versions and Builds
The bug’s reach was broad by design of how Microsoft services Windows: nearly every actively supported consumer and enterprise branch touched the same File History code path. Based on Microsoft’s servicing documentation and BleepingComputer’s reporting, the affected population breaks down as follows:
| Category | Detail |
|---|---|
| Windows 11 branches affected | 23H2, 24H2, 25H2, 26H1 |
| Windows 10 branches affected | 21H2 and later (22H2) |
| Enterprise LTSC branches affected | LTSC 2016, LTSC 2019 |
| Implicated component | KERNELBASE.dll crash signature reported in Event Viewer logs |
| Fix availability date | September 22, 2026 (KB5124010 and later cumulative updates) |
| Confirmed affected user count | Not disclosed; Microsoft describes it only as affecting “some customers” |
Notably, Microsoft has not published a number for how many devices were affected, which is standard practice for known-issue disclosures but leaves administrators guessing about the actual blast radius inside their fleets. For organizations running mixed Windows 10 and Windows 11 environments, the practical takeaway is that version diversity offered no protection: whether a machine ran the oldest supported Windows 10 branch or the newest Windows 11 26H1 build, it was equally exposed.
Workarounds Users Tried Before the Patch
With no official fix available for roughly two weeks, affected users turned to Microsoft’s own Q&A community for stopgap measures. The most commonly cited workaround, discussed in Microsoft Q&A threads, was uninstalling the specific update that introduced the regression, namely KB5124008 on affected Windows 11 systems, and holding off on reinstalling it until the fix update became available.
That workaround carries an obvious tradeoff: rolling back a security update to restore a backup feature means temporarily giving up whatever vulnerabilities that update patched. For a feature whose entire purpose is protecting data, asking users to choose between backups working and security patches staying current is not a comfortable position for Microsoft to put customers in, even for two weeks.
Checking Installed Updates and File History Status
Users wanting to confirm which update is currently installed, and whether the September 22 fix has landed, can check from PowerShell:
Get-HotFix | Where-Object {$_.HotFixID -match "KB5124008|KB5122880|KB5122878|KB5124010"} | Format-Table HotFixID, InstalledOnIf the output shows KB5124008, KB5122880, or KB5122878 without also showing KB5124010 or a later cumulative update installed on top, the system may still be running the broken File History code path. Running Windows Update to pull the latest cumulative update for the installed branch resolves it.
Why File History Still Matters in 2026
File History has shipped as a built-in Windows feature since Windows 8, and it remains the default, no-cost backup mechanism baked into every consumer copy of Windows 10 and Windows 11. It is not the enterprise backup layer that IT departments rely on, but it is very often the only backup layer a home user, freelancer, or small office ever configures, precisely because it requires no third-party software and no subscription.
That ubiquity is exactly why a silent failure in File History carries more real-world risk than a bug in a niche enterprise tool. Enterprise backup products typically come with monitoring, alerting, and IT staff watching dashboards for failed jobs. File History has none of that: it runs in the background, and the only signal a typical user gets is the “Last Backup” timestamp, which this bug froze without throwing a visible error. Readers who want a more resilient, monitored alternative can look at cloud-native options like AWS Backup, which centralizes backup policies and alerting in a way consumer-grade File History was never designed to do.
Historical Context: Microsoft’s Pattern of Update-Breaks-Feature Bugs
This is not the first time a Windows cumulative update has broken a core feature rather than just fixing vulnerabilities. Windows’ monthly patch cycle has, across the past several years, repeatedly introduced regressions in printing, networking, and file management subsystems alongside its intended security fixes. The File History bug fits a recognizable shape: a security-focused update touches a shared library, in this case a component tied to KERNELBASE.dll, and an unrelated feature that depends on that library breaks as collateral damage.
What makes September 2026 notable is the sheer scale of patching happening in parallel. Microsoft’s Patch Tuesday that same month addressed a record 966 vulnerabilities, a volume that inevitably increases the surface area for this kind of regression. Oracle’s own September Critical Patch Update, covering more than 800 bugs, and Microsoft’s record-setting count together suggest the entire industry is pushing larger, more complex patch batches than in prior years, and quality-assurance processes are visibly struggling to keep pace. Readers can compare the scale directly against Oracle’s September 2026 patch cycle, which had its own share of high-severity fixes shipped under similar time pressure.
Market and Enterprise Impact: Backup Reliability Under Scrutiny
For enterprise IT teams, the File History bug itself is low-stakes since most organizations use dedicated backup infrastructure rather than the consumer-grade feature. The bigger signal for enterprise buyers is what it says about Microsoft’s update-testing pipeline at a moment when ransomware recovery timelines are already a board-level concern. Backup integrity has become a boardroom issue this year: recent industry data covered on this site found that ransomware recovery costs organizations an average of $5.08 million, with downtime running as much as 50 times the actual ransom demand. A silent, undetected backup failure at any point during that window compounds recovery costs directly.
The File History incident is a consumer-scale version of a problem enterprise backup vendors have spent years designing around: verification. Modern backup platforms increasingly ship with automated restore testing precisely because a completed backup job is not proof that the data is actually recoverable. Microsoft’s consumer tooling has no equivalent safety net, and this bug is a concrete illustration of why that gap matters.
Competitive Landscape: How Windows’ Built-In Backup Compares
File History competes, loosely, with a mix of other built-in and third-party options rather than facing head-to-head competition in the traditional sense. Apple’s Time Machine on macOS occupies the same free, built-in, consumer-facing niche and has generally had a more stable multi-year track record, though it has faced its own compatibility issues with network-attached storage over the years. On the cloud side, sync-based services offer redundancy that does not depend on a single local Windows component the way File History does.
The practical lesson from this incident is architectural: any backup tool tied tightly to the host operating system’s own update cycle inherits that operating system’s regression risk. A cloud-synced or agent-based backup tool running independently of Windows’ cumulative update schedule would not have broken in the same update cycle that shipped the bug, because it does not share the affected code path. That is part of why security-conscious households and small businesses increasingly layer a second, independent backup method rather than trusting File History alone.
Analysis: What This Reveals About Microsoft’s QA Process
The most telling detail in this incident is not the bug itself but the detection gap. Eight separate KB numbers shipped the same regression on the same day across every actively serviced Windows branch, yet the failure mode, a false “reconnect your drive” prompt with a frozen timestamp, did not surface as a formally documented known issue until roughly two weeks later. That gap suggests Microsoft’s automated telemetry either did not flag the File History regression with enough confidence to trigger a fast known-issue rollback, or the signal was present but deprioritized against the hundreds of other issues generated by a record 966-vulnerability patch month.
Either explanation points to the same structural issue: Windows’ update pipeline is optimized for shipping security fixes on a fixed monthly cadence, and feature regressions discovered after release depend heavily on user-forum reports bubbling up through Microsoft Q&A and the Community Hub before official acknowledgment follows. That is a reactive model, not a preventive one, and it puts the burden of detection on the people least equipped to diagnose a root cause: everyday users staring at a “reconnect your drive” error that has nothing to do with their actual drive.
Predictions: What Happens Next
Based on the pattern of this incident and Microsoft’s historical handling of similar known issues, several outcomes look likely over the coming weeks and months:
- Microsoft will likely backport the September 22 fix logic into the next scheduled cumulative updates for LTSC 2016 and LTSC 2019, since those enterprise-focused branches typically lag behind mainstream Windows 10 and Windows 11 servicing by several weeks.
- Expect Microsoft’s release-health validation process to add File History regression testing to its pre-release checklist, following the same pattern seen after previous high-profile update regressions in printing and networking subsystems.
- Enterprise IT forums and Microsoft MVP communities will likely push for faster public acknowledgment of known issues rather than waiting until user complaint volume forces the company’s hand.
- Third-party backup vendors are likely to reference this incident in marketing material aimed at consumers and small businesses, positioning independent, OS-agnostic backup tools as a hedge against exactly this kind of platform-level regression.
- Watch for similar-shaped bugs in future patch cycles as Microsoft continues to ship increasingly large monthly security batches; the September 2026 Patch Tuesday’s record 966-vulnerability count suggests testing capacity is being stretched, and File History is unlikely to be the last shared-component casualty.
How to Check If You’re Affected and What to Do Now
Anyone using File History as a backup method should take three steps immediately. First, open Control Panel > System and Security > File History and confirm the “Last Backup” timestamp reflects a recent date rather than one from before September 8, 2026. Second, run Windows Update and confirm KB5124010 or a later cumulative update for your specific branch is installed; the PowerShell command above will confirm this from the command line. Third, manually trigger a backup after updating and verify a restore point actually appears for a recently modified file, since a completed backup job is not the same as a verified, restorable one.
For anyone who went the full two weeks without realizing backups had silently stopped, it is worth treating this as a prompt to add a second, independent backup method, whether that is a cloud sync service or a scheduled export to network storage that does not depend on the same Windows component. Relying on a single backup mechanism tied to the host operating system’s own update cycle is precisely the failure mode this bug exposed.
FAQ: Windows File History Backup Bug
What caused File History to stop working in September 2026?
Microsoft’s own support documentation attributes the failure to the September 2026 security update KB5124008 and its equivalents across other Windows branches (KB5124012, KB5122880, KB5122878, KB5122876, and KB5123099), which shipped on September 8, 2026.
Which update fixes the File History bug?
Microsoft says the issue is resolved in updates released on and after September 22, 2026, including KB5124010. Users on Microsoft Q&A confirmed backups resumed successfully after installing it.
Which versions of Windows were affected?
Windows 10 21H2 and later, Windows 10 Enterprise LTSC 2016 and 2019, and Windows 11 23H2 through 26H1 were all listed as affected in Microsoft’s servicing documentation and BleepingComputer’s reporting.
How do I know if my File History backups actually stopped?
Check Control Panel > System and Security > File History for a frozen “Last Backup” timestamp, an incorrect “Reconnect your drive” message despite a working drive, or a “No previous version available” error when attempting to restore a file.
Is there a workaround if I can’t install the fix yet?
Microsoft Q&A threads describe uninstalling the specific update that introduced the regression, such as KB5124008 on Windows 11, as a temporary workaround, though this also removes whatever security fixes that update included.
Did Microsoft say how many users were affected?
No. Microsoft’s support documentation describes the impact only as affecting “some customers” and does not provide a specific figure for the number of devices or users involved.
Does this bug affect other backup software, like third-party tools?
The reported issue is specific to the built-in File History feature tied to the affected KERNELBASE.dll-related code path. There is no indication in Microsoft’s documentation or BleepingComputer’s reporting that third-party backup software running independently of File History was affected.
Should I uninstall the September 2026 security updates entirely?
Microsoft does not recommend a blanket uninstall. The safer path is to install the September 22 fix update (KB5124010 or the equivalent for your branch), which resolves the File History issue while keeping the underlying security patches in place.