Forum Discussion
Is anyone else's Windows 10 File History failing to update after the August/September updates?
Hi everyone,Since installing the KB5120249 update on August 11th, my Windows 10 (version 22H2) has been experiencing an issue where File History can find and run backups to my target drive (Drive D), but the last copy date and time of files remain unchanged, preventing any new or modified files from being backed up properly.
The specific issues are as follows:
- Version and Timestamp Not Updating: The read and write functions of Drive D are working normally. Even after confirming that a file has been successfully saved, clicking the Run now button in Control Panel does not update the last backup timestamp or version time to the actual latest save time.
- Missing Previous Versions: In a file's Properties -> Previous Versions, modified or newly added files show past versions, but fail to display the latest update date. New versions are omitted as well, continuing to show No previous version available, which fails to reflect the latest changes.
- Strangely enough, the system sometimes backs up files even when they haven't been modified at all. I haven't changed anything on my end, and I haven't been able to successfully back up since the KB5122878 update on September 8th.
I didn't mess with the settings; the problem occurred after the update.
After the recent KB5124010 update in Windows 11, the file history can find and run backup drives, but the last copy date of the files remains unchanged, and any new files can be backed up.
I suspect the problem persists after KB5101684 on July 29th.
Is anyone else still experiencing this issue? On September 23rd, I contacted Microsoft Support to report this File History glitch caused by recent updates (including subsequent impacts from the KB5124010 update). Several other users had also reported the same problem. Two days later, Microsoft Support sent an email confirming that they were aware of the issue and were investigating.
1 Reply
Your report describes two different symptoms: a stale “last backup” display and modified files missing from recoverable versions. The second is the more important risk, because an unchanged timestamp alone does not prove that backups stopped. Make an independent copy of current files before testing, and preserve the existing File History drive and catalog. Create one new test document and modify another inside a backed-up library, then run File History manually. Open the restore interface and inspect whether both versions can actually be recovered; restore them to an alternative location so the originals are not overwritten. Record the file modification times, backup run time, Windows build, and installed update details. Since you already have a support investigation, add these reproducible results to that case. I cannot substantiate those updates as an officially confirmed regression or provide a release date for a fix; keep another backup until recovery tests succeed.
