File History stopped recording versions after KB5101684 and KB5120249 on Windows (August 31, 2026)
Chapters
TL;DR
On Windows 11 25H2 and Windows 10 22H2, File History kept copying files to the backup drive but stopped recording new versions after the July and August 2026 updates, per a report on Microsoft Community Hub opened on August 30, 2026 that drew its first replies on August 31, 2026. The Last Backup timestamp never moves and newly created files show no previous version available, so there is nothing to restore from. As of August 31, 2026 Microsoft has opened no known issue for this and no fix exists.
- The two updates named in the thread are KB5101684, the July 28, 2026 preview for Windows 11 25H2, and KB5120249, the August 11, 2026 update for Windows 10 22H2.
- Files still copy to the backup drive. What stopped is version history, which is the part you actually restore from.
- One responder traced it to the File History service failing during startup with an ESENT database error of -621, which prevents the service activating at all.
- Re-selecting the same backup drive in Control Panel restarts tracking, but it does not recover the versions that were never written.
- This is user reports only. There is no Microsoft known issue, so there is no dated resolution to wait for.
What stopped working
The original report is precise about the split. Copying physical files to the backup drive still works normally, in the poster's words, but the Last Backup timestamp in File History in Control Panel remains unchanged, and new files consistently display no previous version available under Properties.
That combination is the dangerous one, because the backup looks healthy from the outside. The drive fills and the folders appear. Version history is what people reach for when a file was overwritten an hour ago or a folder was encrypted overnight, and version history was not being written.
| Update | Released | Version reported | Reported effect |
|---|---|---|---|
| KB5101684 | July 28, 2026 (preview) | Windows 11 25H2 | File History stops recording new versions |
| KB5120249 | August 11, 2026 | Windows 10 22H2 | File History stops recording new versions, and the update is re-offered after installing |
The ESENT database error behind it
One responder on the thread reported that the File History service fails during its startup process, generating an ESENT database error of -621, which prevents the service activating at all. That is a single participant's finding rather than a Microsoft statement, and the thread does not establish which of the two updates causes it or why the failure appears on two different Windows versions.
The thread also carries a warning about repairs. Another user who tried to fix File History ended up with duplicated files and a broken restore menu. Anyone planning to rebuild the File History configuration should know that before starting, not after.
Microsoft has not acknowledged this
As of August 31, 2026 this is a pattern in a public discussion thread, not a confirmed defect. There is no known issue entry, no KB acknowledgment and no statement about a fix, and I am reporting it as exactly that.
The difference matters for how you act. With an acknowledged issue you can read Microsoft's wording, take its workaround and wait for a dated resolution. Here there is nothing to wait for, so the only sensible step is to verify your own version history by hand and stop assuming it exists.
The Windows 10 side of KB5120249
The same Windows 10 update was misbehaving in a second, separate way. A question asked at 10:51 UTC on August 31, 2026 by Lars-Erik Osterud on Microsoft Q&A reports that KB5120249 fails from Windows Update with error 0x80070643, while a manual download reports the update is already installed, and Windows Update keeps re-offering it anyway.
The machine in that thread has no separate recovery partition, with the recovery environment sitting on the C: drive. sfc and dism repairs were attempted without success. Answers on the thread suggested resetting the Windows Update cache and rebuilding the recovery partition with reagentc and diskpart, which is a good deal more invasive than the problem looks from the notification area.
What you can do today
1. Check whether your version history is actually there. Right click a file you edited this week, open Properties and look at Previous Versions. If it says no previous version available on files you know you changed, tracking has stopped on your machine too.
2. Re-select the drive. Open Control Panel, then File History, then Select drive, and pick the same backup drive again. The thread reports that this restarts tracking. The cost is that it is a restart and not a repair: it recovers nothing that was never captured, and the reports do not say how long it holds.
3. Do not start deeper repairs unless you have a second copy of the data, given that a repair attempt in the thread produced duplicated files and a broken restore menu.
4. Make one copy today that does not depend on File History, even a manual copy of your documents folder to another drive. A version history you cannot see is not a backup.
5. If Windows Update keeps offering KB5120249 after it has installed, treat that as the separate problem it is, and check where your recovery environment lives before resetting the update cache or touching partitions with reagentc or diskpart.