HomeNewsletterCommunityMVP FeedToolsArchiveBlogToday's NewsAboutServicesQuick Links Subscribe free
← Back to Blog
Windows KB5124008FileHistoryWindows11PatchTuesdayDataBackup24H225H2WindowsUpdate

KB5124008 Breaks File History: 'Reconnect Your Drive' Error Now Officially Confirmed

IA
Imran Awan
20 September 2026
The short version

The September 9, 2026 Patch Tuesday security update KB5124008 causes File History to stop creating backups on Windows 11 24H2 and 25H2 devices. Users see a false “Reconnect your drive” warning even when the backup drive is fully connected, and FileHistory.exe crashes silently in the background (faulting module: KERNELBASE.dll). Microsoft officially confirmed the issue on 19 September 2026. The September 14 out-of-band update KB5129195 does not fix it — that update addressed the RDS regression only. There is no production fix as of 20 September 2026. This post shows how to confirm whether your devices are affected, pinpoint the crash in Event Viewer, and identify every File History machine in your fleet before backup data goes stale.

Watch this post — YouTube walkthrough
KB5124008 Breaks File History — Find Affected Devices Before Data Loss
KB5124008 Breaks File History — Find Affected Devices Before Data Loss
Endpoint Weekly
Watch on YouTube Subscribe at @EndpointWeekly

The problem: false “Reconnect your drive” and silent crash

Since the September 9, 2026 Patch Tuesday update, Windows 11 devices running build 26100.x (24H2) and 26200.x (25H2) are exhibiting a specific failure: File History silently stops creating backups and the user sees a “Reconnect your drive” warning in the File History control panel even when the backup drive is physically present and readable by every other application on the machine.

The visible symptoms are consistent across affected devices:

Microsoft added acknowledgement of this issue to the official KB5124008 support article on 19 September 2026. The regression itself has been present since September 9, with users reporting it on community forums since Patch Tuesday. Official confirmation appeared 10 days after the issue began, which is important context for any support tickets your users have already raised.

Control Panel › System and Security › File History
💾
File History is off
Reconnect your drive
⚠ File History can’t find your File History drive
Reconnect your drive and try again, or use a different drive.
Your last backup was on 9/8/2026 22:47
Last backup
9/8/2026 22:47
Not updated since KB5124008
Backup drive
BackupDrive (D:)
Drive IS present — false error
⚠ Data protection risk: File History is the only automatic versioned backup mechanism built into Windows 11 for personal files on a local or network drive. If backups have silently stopped since September 9, affected users have no automatic recovery point for files created or modified in the 11+ days since the patch. Identify every device in your fleet that uses File History and has KB5124008 installed before assuming backup data is current.
Windows versionBuild after KB5124008Affected?
Windows 11 24H226100.x (September 2026 CU)Yes
Windows 11 25H226200.x (September 2026 CU)Yes
Windows 11 23H2 and earlierNot in scope for this KBNo
Windows 10 (all versions)Different KB seriesNo (different KB)

Why it happens: FileHistory.exe crashes in KERNELBASE.dll

File History runs as a Windows service called fhsvc (Windows File History Service). When a backup is due, fhsvc launches FileHistory.exe as the backup engine. FileHistory.exe handles all the actual work: scanning the protected libraries and folders, comparing changed files against the previous backup snapshot, and copying new or modified files to the backup drive.

After KB5124008, FileHistory.exe crashes during this startup phase before any backup work begins. The crash is not in FileHistory.exe’s own code — it occurs inside KERNELBASE.dll, which is the core Windows kernel API abstraction layer. KERNELBASE.dll provides fundamental process, thread, file, memory, and security APIs that almost every Windows application depends on. A crash at offset inside KERNELBASE.dll during FileHistory.exe’s startup means that KB5124008 changed the behaviour of a Windows API that FileHistory.exe calls early in its execution, and the new implementation is incompatible with FileHistory.exe’s existing calling pattern.

Because the crash happens before the backup engine can reach the drive, File History produces no backup content. The fhsvc service detects that FileHistory.exe terminated unexpectedly and surfaces the generic “Reconnect your drive” error in the Control Panel. That UI string is File History’s catch-all for any startup failure — it does not mean the drive is physically disconnected.

Event Viewer — Windows Logs › Application
2026-09-10 06:47:23 — Event ID 1000 — Source: Application Error
Application crash — FileHistory.exe
Faulting application name: FileHistory.exe, version: 10.0.26100.2605
Faulting module name: KERNELBASE.dll, version: 10.0.26100.4061
Exception code: 0xc0000374 (STATUS_HEAP_CORRUPTION)
Fault offset: 0x000000000014bda5
Faulting process id: 0x1a34
2026-09-10 06:47:24 — Event ID 1001 — Source: Windows Error Reporting
WER follow-up to Event 1000
Fault bucket: FileHistory.exe-KERNELBASE.dll-0xc0000374
2026-09-10 12:47:19 — Event ID 1000 — next scheduled backup attempt
Same crash, repeating at every backup interval
Faulting application: FileHistory.exe — Faulting module: KERNELBASE.dll

Notice the crash repeats at each scheduled backup interval. File History will keep trying — and keep crashing — on its configured schedule until a fix ships. Each attempt produces a new Event ID 1000 entry. A device with hourly backups running for 11 days since September 9 will show approximately 264 crash events by now.

Gotcha — KB5129195 does NOT fix this: The September 14 out-of-band update KB5129195 was released specifically to repair an RDS (Remote Desktop Services) regression from KB5124008, where Remote Desktop connections were dropping unexpectedly. KB5129195 patches Remote Desktop Session Host and related components — it has no overlap with the File History code path. Installing KB5129195 is the right call for the RDS fix, but it leaves the FileHistory.exe crash entirely unaffected. Do not tell users or peers that KB5129195 resolves File History.

The strongest evidence that Microsoft is actively working on a fix comes from the Windows Insider channel. On 18 September 2026 — one day before the official KB5124008 acknowledgement — Insider Beta and Experimental builds included a fix described as resolving a File History failure where “No usable drives found” was shown. That wording is the Insider-channel equivalent of the production “Reconnect your drive” error. Both are File History’s UI response to the same underlying condition: FileHistory.exe crashing at startup before it can reach the backup drive. A fix landing in Insider builds on September 18 means the code change exists, is being validated in testing, and will arrive in a production Cumulative Update — but has not yet shipped as of 20 September 2026.

Scope note — Windows Backup vs File History: File History (the feature affected here) backs up files to a local or network drive and is configured via Control Panel › File History or by running filehistory.exe. It is separate from the Windows Backup app (introduced in Windows 11 22H2) which syncs Desktop, Documents, Pictures, Videos, Music, and Favourites to OneDrive. Windows Backup is not affected by this issue. If your users are backing up via OneDrive, they are unaffected. The regression only affects users who have configured File History with a drive target.

How to verify: KB state, crash events, last backup timestamp

Before doing anything, confirm a device is actually affected by the regression rather than experiencing a genuine drive disconnection. There are four checks to run, in order: confirm the build and KB state, check the File History registry configuration, query the Application event log for crashes, and check the last backup timestamp.

Step 1 — Confirm Windows build and KB installation

Open PowerShell as administrator. The first command returns the build number and display version to confirm the device is on 24H2 or 25H2. The second confirms KB5124008 is installed. The third checks whether KB5129195 is also present, which you should note but not treat as a fix.

PowerShell — Run as Administrator
# Windows build number and display version (24H2 = 26100.x, 25H2 = 26200.x) Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object CurrentBuild, DisplayVersion, UBR # Confirm KB5124008 (September Patch Tuesday — the causing update) is installed Get-HotFix -Id KB5124008 # Confirm KB5129195 (September 14 OOB — fixes RDS only, NOT File History) Get-HotFix -Id KB5129195

If Get-HotFix -Id KB5124008 returns nothing, the device has not yet received September Patch Tuesday and is not in scope for this issue. If it returns a result and the build is 26100.x or 26200.x, continue to the next check.

Step 2 — Check File History registry configuration

File History stores its enabled state and target drive path in the current user’s registry hive. Checking this tells you whether File History was actively configured on the device before the patch broke it. Run the following in PowerShell, or navigate to the key manually in Registry Editor (Win+R then regedit).

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\FileHistory
Registry Editor — File History configuration keys
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\FileHistory
Enabled REG_DWORD 0x00000001  ✓ File History is on
TargetUrl REG_SZ \\.\D:  Backup drive target
DisabledByGroup REG_DWORD 0x00000000  Not disabled by policy
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\fhsvc
Start REG_DWORD 0x00000002  Automatic start
ImagePath REG_EXPAND_SZ %SystemRoot%\system32\svchost.exe -k LocalService
Registry valueExpected (healthy)What it tells you
Enabled (REG_DWORD)0x1File History is turned on. If absent or 0, File History was never configured and this is not a KB5124008 issue.
TargetUrl (REG_SZ)Drive letter or UNC pathThe configured backup destination. If this is empty, File History has no target drive set.
DisabledByGroup (REG_DWORD)0x0Set to 1 if a Group Policy or Intune configuration has disabled File History. Check this before blaming KB5124008.

Step 3 — Find the crash in the Application event log

The definitive confirmation is Event ID 1000 in Windows Logs › Application, with FileHistory.exe as the faulting application and KERNELBASE.dll as the faulting module. Run the following to query it from PowerShell without opening Event Viewer manually.

PowerShell — Query FileHistory.exe crash events
# Count FileHistory.exe crashes in the last 14 days Get-WinEvent -LogName Application -ErrorAction SilentlyContinue | Where-Object { $_.Id -eq 1000 -and $_.Message -like '*FileHistory.exe*' -and $_.TimeCreated -gt (Get-Date).AddDays(-14) } | Measure-Object | Select-Object -ExpandProperty Count # Get the 5 most recent crash events with timestamps Get-WinEvent -LogName Application -ErrorAction SilentlyContinue | Where-Object { $_.Id -eq 1000 -and $_.Message -like '*FileHistory.exe*' } | Sort-Object TimeCreated -Descending | Select-Object -First 5 TimeCreated, Id, @{N='Fault';E={ if ($_.Message -match 'Faulting module name: (\S+)') {$matches[1]} else {'(see full message)'} }} | Format-Table -AutoSize

If the first command returns a count greater than zero with timestamps on or after September 9, 2026, the device is confirming the KB5124008 crash pattern. Each crash represents one failed backup attempt. File History keeps retrying at its configured interval and keeps failing — so the crash count accumulates quickly on devices with frequent backup schedules.

Step 4 — Event ID reference table

File History events appear in two locations. The primary location for this investigation is the standard Application log for the crash event. File History also writes to its own dedicated event channels, which are useful for confirming when the last successful backup actually completed.

Event Viewer — Windows Logs › Application — Source: Application Error
1000
Application crash
FileHistory.exe faulted in KERNELBASE.dll. Fires once per failed backup attempt. The key field is “Faulting module name: KERNELBASE.dll” — confirms this is the KB5124008 regression, not a drive issue.
1001
Windows Error Reporting follow-up
Auto-generated after Event 1000. Contains the fault bucket ID used for Microsoft crash telemetry. Not actionable on its own — use Event 1000 for diagnosis.
Event Viewer — Applications and Services Logs › Microsoft › Windows › FileHistory-Engine › BackupEnd
200
Backup completed successfully
Fires when FileHistory.exe finishes a backup cycle without error. If there are no Event 200 entries dated on or after September 9 on a device that had them regularly before, backups have been failing consistently since the patch.
201
Backup failed
Fires when a backup attempt ends in failure. May appear alongside the Application log crash, depending on whether the engine crash occurs before or after it logs to this channel. Check both channels when investigating.

Step 5 — Run the fleet detection script

The companion script Get-FileHistoryKB5124008Status.ps1 wraps all four checks into a single read-only run. It reports the KB state, File History configuration, last backup timestamp (from the File History XML config at %LOCALAPPDATA%\Microsoft\Windows\FileHistory\Configuration\Config), crash event count, and a plain-English verdict. Deploy it via Intune shell script or run it locally on a representative sample of devices before deploying the Proactive Remediation.

Get-FileHistoryKB5124008Status.ps1 — example output (affected device)
# Output from an affected Windows 11 24H2 device ComputerName : DESKTOP-XXXXXXX OSBuild : 26100 DisplayVersion : 24H2 KB5124008Present : True KB5129195Present : True # OOB installed but does not fix File History FileHistoryEnabled : True FileHistoryTargetUrl : \\.\D: LastBackupDate : 09/08/2026 22:47:03 # Frozen since day before Patch Tuesday BackupStaleDays : 11.6 CrashesFound : 268 # ~hourly crashes over 11 days LastCrashTime : 09/19/2026 18:47:09 Verdict : AFFECTED - File History backup failing since KB5124008

The fix: workarounds while awaiting Microsoft’s patch

There is no production fix as of 20 September 2026. The right approach is to put interim protections in place for users who depend on File History for their only backup, monitor Microsoft’s KB article for a fix update, and avoid the one tempting-but-wrong remediation: removing the security update.

⚠ Do not uninstall KB5124008 to restore File History. KB5124008 is the September 2026 Patch Tuesday security update and contains patches for multiple CVEs, including critical-severity vulnerabilities. Removing it to restore File History functionality leaves managed devices unpatched for those vulnerabilities. The correct action is to apply interim protections (below) while waiting for Microsoft to ship the fix in a future Cumulative Update.

Immediate actions

  1. Rule out a genuine drive disconnection first. Open File Explorer on the device and verify the backup drive’s letter or UNC path is accessible and files can be opened. If the drive genuinely is not connected, the “Reconnect your drive” message is correct and not the KB5124008 issue. Only after confirming the drive is reachable should you proceed.
  2. Check whether DisabledByGroup is set. If the registry value HKCU:\Software\Microsoft\Windows\CurrentVersion\FileHistory\DisabledByGroup equals 1, a Group Policy or Intune configuration has explicitly disabled File History on this device. That is not the KB5124008 crash — it is a policy-driven state.
  3. Attempt a service restart as a temporary measure. Restarting the fhsvc service occasionally allows one backup cycle to complete before the next crash. This is not a fix — the crash recurs at the next scheduled interval — but it creates a single checkpoint backup to reduce data loss exposure.
    PowerShell — Run as Administrator
    # Restart the File History service Restart-Service -Name fhsvc -Force Get-Service -Name fhsvc | Select-Object Name, Status # Trigger a manual backup attempt immediately Start-Process -FilePath 'C:\Windows\System32\FileHistory.exe' -ArgumentList '-backup' # Wait 90 seconds then check for new crash events Start-Sleep -Seconds 90 Get-WinEvent -LogName Application -ErrorAction SilentlyContinue | Where-Object { $_.Id -eq 1000 -and $_.Message -like '*FileHistory.exe*' -and $_.TimeCreated -gt (Get-Date).AddMinutes(-3) } | Select-Object TimeCreated, Id
    If the last command returns no results, the service restart succeeded and a backup cycle ran. If Event ID 1000 appears within 3 minutes, the crash is persisting on this device.
  4. Direct users to Windows Backup as an interim alternative. If the user’s files are in the standard libraries (Desktop, Documents, Pictures, Videos, Music), Windows Backup syncs those folders to OneDrive and is not affected by this issue. It is a different mechanism from File History and cannot replace File History’s versioned restore capability, but it provides a current copy of all files.
    Settings Accounts Windows Backup
  5. Monitor Microsoft’s KB article for the production fix. Microsoft will update the KB5124008 support article when the fix ships, either as a new entry in the Resolved issues section or as a link to the Cumulative Update that contains the fix. Monitor the KB5124008 support article and the Windows 11 release health dashboard daily until the fix is confirmed.

Deploy as an Intune Proactive Remediation

Use the companion Detect and Remediate scripts to surface affected devices in Intune before IT receives individual user tickets. The detection script exits 1 on devices where KB5124008 is installed, File History is enabled, and FileHistory.exe crash events are found in the last 7 days. The remediation script restarts fhsvc — a temporary measure only.

  1. In the Intune admin center, go to Devices › Scripts and remediations › Proactive remediations and select Create.
  2. Name the package KB5124008 — File History crash detection.
  3. On the Settings page, upload Detect-FileHistoryKB5124008.ps1 as the Detection script file.
  4. Upload Remediate-FileHistoryKB5124008.ps1 as the Remediation script file.
  5. Set Run script in 64-bit PowerShell to Yes and Run this script using the logged-on credentials to No (SYSTEM context).
  6. Assign to your target group. Set schedule to Daily until the production fix ships, then retire the package.
Devices Scripts and remediations Proactive remediations Create
Tip — filter affected devices from Intune: After the Proactive Remediation is running, go to the package’s Device status tab and filter by Detection status: Issues found. This gives you a list of every managed device with KB5124008 installed, File History enabled, and recent crash events. Export the list and cross-reference with your helpdesk queue to proactively reach out to affected users before they notice missing Previous Versions.

Proof it worked: what healthy File History looks like

Since the production fix has not yet shipped, this section documents what you should verify on a pilot device immediately after Microsoft releases the fix update. Run these checks before rolling the update fleet-wide.

PowerShell — Verify File History after the fix
# Confirm the fix KB is installed (KB number TBC — monitor the support article) Get-HotFix | Where-Object { $_.InstalledOn -gt '2026-09-09' } | Select-Object HotFixID, InstalledOn | Sort-Object InstalledOn -Descending # Trigger a manual backup and wait 2 minutes for it to run Start-Process -FilePath 'C:\Windows\System32\FileHistory.exe' -ArgumentList '-backup' Start-Sleep -Seconds 120 # Zero results = healthy. Any Event 1000 = still crashing $newCrashes = Get-WinEvent -LogName Application -ErrorAction SilentlyContinue | Where-Object { $_.Id -eq 1000 -and $_.Message -like '*FileHistory.exe*' -and $_.TimeCreated -gt (Get-Date).AddMinutes(-5) } if ($newCrashes.Count -eq 0) { Write-Host 'HEALTHY: No FileHistory.exe crashes in the last 5 minutes' -ForegroundColor Green } else { Write-Host "STILL CRASHING: $($newCrashes.Count) event(s) — fix not effective on this device" -ForegroundColor Red }

Expected state once the fix is confirmed working on a pilot device:

Companion PowerShell scripts — KB5124008 File History

Three scripts are included with this post. Download them from the GitHub link below and deploy as described in the verification and fix sections above. View on GitHub →

Get-FileHistoryKB5124008Status.ps1 Read-only diagnostic. Reports KB state, File History configuration, last backup timestamp from the XML config, crash event count, and a plain-English verdict. Safe to run on production devices. Does not modify any system state.
Detect-FileHistoryKB5124008.ps1 Intune Proactive Remediation detection script. Exits 1 (issue found) when KB5124008 is installed, File History is enabled, and FileHistory.exe crash events exist in the last 7 days. Run as SYSTEM in 64-bit PowerShell.
Remediate-FileHistoryKB5124008.ps1 Temporary remediation: restarts fhsvc to allow one backup cycle to complete. Not a production fix. Replace with the real fix script once Microsoft ships the Cumulative Update. Run as SYSTEM in 64-bit PowerShell.

Repo: Imran76Awan/Windows-Patching-Scripts — folder: kb5124008-file-history-reconnect-drive-error-windows-11

References

Last updated: 20 September 2026. This post will be updated with the fix KB number and verified remediation steps as soon as Microsoft ships the production Cumulative Update. Monitor the Windows 11 release health dashboard for live status.

Was this post helpful?
React below — no account needed
Share this post
LinkedIn X / Twitter Reddit Bluesky

More from EndpointWeekly

Windows
KB5094126 Sign-in Failure Fix — Windows 11 24H2
KB5094126 is causing sign-in failures on some Windows 11 24H2 devices after installation.…
Windows
Morocco Is Abolishing DST on 20 September 2026 — What Windows…
Morocco permanently moves to UTC+0 (GMT) on 20 September 2026. Windows devices set to…
Windows 11
WMIC Has Been Removed from Windows 11: Replace Your Legacy…
The August 2026 preview update (KB5067470) removes wmic.exe from Windows 11 for good - no…