File History silently fails to turn on after Windows 11 24H2 update (Stops during Catalog creation)

I fixed it. For anyone else who encounters this issue here is the solution and full investigation detail.

TL;DR

If File History will not turn on (you press turn on from Control Panel/File History UI, it darkens as if it is about to start but then resets), check this value:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications\Data\41960B29A3BC1475

Command to check:

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications\Data" /v 41960B29A3BC1475

If it is missing, restore it as:

REG_BINARY 0100000001000000

Command to restore:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications\Data" /v 41960B29A3BC1475 /t REG_BINARY /d

0100000001000000 /f

Then reboot.

On a separate healthy VM I deleted only this value and File History failed. Restoring only this value and rebooting made File History work again. The same fix worked on the original broken machine.

Full Investigation Detail:

I investigated a Windows File History failure where clicking Turn on did not complete. The root cause turned out to be a missing persisted registry value under:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications\Data

The specific missing value on the broken machine was:

41960B29A3BC1475

On healthy systems, it existed as:

REG_BINARY 0100000001000000

What the failure looked like

On the broken machine:

• File History would not enable successfully.
• fhsvc ended up stopped again.
• The healthy file set was not completed.
• The broken fingerprint was:
  • local Catalog1.edb
  • local Catalog1.jfm
  • no Catalog2.edb
  • no completed Config XML set on the backup drive

Advanced tracing showed the immediate failure path was:

• fhcfg!CDpConfigMgr::CreateCatalogs
• fhcat!DataProtectionCatalog::CreateStringTable
• ESENT!JetCreateTableColumnIndexW
• ESENT error:
  • -621
  • JET_errEngineFormatVersionParamTooLowForRequestedFeature
• translated back to:
  • 0x800405ff

That HRESULT propagated back through fhcfg to the File History Control Panel enable path, which simply failed the Turn on operation without exposing a useful user-visible error code.

The fix

Restore this value:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications\Data\41960B29A3BC1475

REG_BINARY 0100000001000000

Command:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications\Data" /v 41960B29A3BC1475 /t REG_BINARY /d

0100000001000000 /f

Then reboot and test File History again.

Why I am confident this is causal

This is not just correlation on one machine.

Broken machine before fix

• 41960B29A3BC1475 was missing
  • File History failed

  Broken machine after fix

• restoring only 41960B29A3BC1475 = 0100000001000000
  • File History worked again
  • fix survived reboot and clean reset/re-enable testing

  Healthy comparison systems

  Both a healthy Elitebook and a healthy VM had: 41960B29A3BC1475 = 0100000001000000 41960B29A3BC0C75 = 0100000001000000 and File History worked on both.

  Cross-machine repro on the healthy VM

  I then tested the healthy VM directly:
  • deleted only:
    • 41960B29A3BC1475
  • left:
    • 41960B29A3BC0C75 unchanged
  • rebooted
  • File History failed
  • local result matched the broken pattern:
    • only Catalog1.edb
    • only Catalog1.jfm
    • fhsvc stopped
  • restored only:
    • 41960B29A3BC1475 = 0100000001000000
  • rebooted
  • File History worked again
  That is strong cross-machine proof that this specific value is sufficient to break and restore the File History path.

  Safe scope

  This is not a generic Windows tweak. I would only apply this fix if your machine matches the same pattern:
• File History fails to turn on
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications\Data\41960B29A3BC1475 is missing
  • you see the same partial local catalog behavior
  Useful checks: reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications\Data" /v 41960B29A3BC1475 reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications\Data" /v 41960B29A3BC0C75 Get-Service fhsvc | Select-Object Name,Status,StartType Get-ChildItem "$env:LOCALAPPDATA\Microsoft\Windows\FileHistory\Configuration" -Force -ErrorAction SilentlyContinue | Select-Object Name,Length,LastWriteTime

  Likely origin

  I do not have proof of the exact Microsoft-internal component that should have recreated this value, but current evidence points toward stale setup/rollback maintenance state rather than an ordinary File History UI problem. Static analysis made SetupCleanupTask.dll the strongest upstream policy-owner candidate. It contains explicit uninstall- window decision logic sourcing from:
• CSP
  • Registry
  • OneSettings
  and gating on:
• OOBE completion
  • uninstall validity
  • deployment in progress

Salut CDub,

Thank you so much for your investigation and for sharing the solution. Creating the binary key absolutely saved me.

Before finding your post, I had spent at least 10 hours trying to get File History working again after upgrading to Windows 11 24H2. I tried countless different methods, including some pretty crazy ones, but nothing worked.

Your solution fixed the problem immediately. I really appreciate the time and effort you put into tracking this down and sharing it with the community. You saved me a lot of frustration!

Thank you again!

Hi CDub,

Thank you for the detailed breakdown, especially confirming that you’ve already tested standard fixes and identified the failure point during catalog creation.

Based on your description, the behavior suggests File History is able to start initialization but stops when building its internal catalog, which points more toward a system-level state or component restriction rather than a typical configuration issue.

Please try the following targeted checks:

1, Verify File History is not restricted by policy

• Press Win + R > type gpedit.msc
• Go to: Computer Configuration > Administrative Templates > Windows Components > File History
• Ensure all settings are Not configured

2, Reset Windows Search database (used by catalog/indexing)

net stop wsearch
rd /s /q C:\ProgramData\Microsoft\Search\Data\Applications\Windows
net start wsearch

• Restart the PC after running the commands

3, Test with a new local admin account

• Create a new local admin user and try enabling File History there
• This helps determine if the issue is tied to the user profile or system state

If File History continues to stop during setup, you may temporarily use Windows Backup / OneDrive backup or another backup solution. You’ve already ruled out the common causes, and your findings point to a deeper system condition after the upgrade.

Let me know if you need further assistance, feel free to ask me by clicking "Add Comment" or "Add Answer" if you cannot add comment so your response will be visible. Thanks for your effort.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Deleting the 41960B29A3BC1475 value was my original workaround for FH failing to clean up old versions on both Win10 and Win11. Restoring it does fix the basic FH functionality that the March 2026 cumulative update broke, but it also brings back the old "Could not clean up File History data -- Element not found" error message. That means your FH backup data will probably accumulate indefinitely, which makes the whole thing unusable for me.

You can restore the old behavior (that requires 41960B29A3BC1475 to be gone) by rolling back the fhcat.dll file to version 10.0.26100.7309. (Thanks for pointing out the failing call stack that pointed me in the direction of that DLL, by the way.)

Please find a proper fix for cleaning up old FH data and we should be golden.