File History Does not Turn On -Problem and Hard Fought Solution

I spent two months trying to solve this problem and succeeded. I see older post of folks who have similar issues, but they are locked and so I have no way to reach them. My hope is that the fulling will save those with the same problem lots of misery.

• Title: File History Turn on fails when 41960B29A3BC1475 is missing under Notifications\Data

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
  However, I did not prove the exact component boundary that publishes or persists 41960B29A3BC1475.

  Timeline

  I do not have proof of one exact causative KB or date. What I do have is the closest supported window so far:
  • 24H2 transition / install date:
    • 2025-07-02 21:40:38 -07:00
  • KB5054156 installed:
    • 2025-10-08
  • stale uninstall/rollback state already present in an offline backup image by:
    • 2025-11-14
  So the best current statement is:
• the machine appears to have been left in a stale persisted DEP/setup state sometime after the July 2025 24H2 transition and no later than the November 14, 2025 backup image
  • later normal update activity did not naturally reconstruct the missing value

  Short version

  If File History will not turn on, and this value is missing: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Notifications\Data\41960B29A3BC1475 restore it as: REG_BINARY 0100000001000000 reboot, and test again. That fixed the original machine, and the same value deletion/restoration was enough to break and recover File History on a separate healthy VM

Tested on Windows 11 Pro, Build 26200.8457 (25H2). The machine was upgraded to 24H2 on 2025-07-02 — the missing registry value was already absent by the November 2025 backup image and was not restored by subsequent servicing through Build 26200.8457.

Feedback Report Link:
https://aka.ms/AA1105nm