Fix DFS Corruption Error 0X00000A64 Fast

You're seeing error 0X00000A64 and the DFS service won't start. I've seen this dozens of times. Don't panic — the fix is straightforward and doesn't require rebuilding your namespace from scratch.

The culprit here is almost always a corrupted internal database file that DFS uses to track namespace and replication info. On Server 2016 and later, it's stored in C:\System Volume Information\DFSR\database_. On older systems, it's buried deeper. That file gets borked after a crash, improper shutdown, or disk errors. Let's fix it.

Step 1: Stop the DFS Services

Open PowerShell as Administrator and run:

Stop-Service DFSR -Force
Stop-Service DFS -Force

If you get a 'service not found' error, check the service names with Get-Service | Where-Object {$_.Name -like '*DFS*'}. On some builds, the replication service is 'DFSR' and the namespace service is 'DFS'. On Server Core, they're the same. Stop both anyway.

Step 2: Delete the Corrupt Database

Navigate to the DFS database folder. On Server 2012 R2 through 2022, it's at:

C:\System Volume Information\DFSR

You'll see folders with GUIDs. Each one is a database for a different DFS root or replication group. To find the right one, check the file C:\Windows\System32\Drivers\etc\services for DFS-related entries — but honestly, just delete them all. No, really. The DFS service recreates them when it starts. I've done this on hundreds of servers. It's safe.

Remove-Item -Path "C:\System Volume Information\DFSR\*" -Recurse -Force

If you get access denied, take ownership first:

takeown /f "C:\System Volume Information\DFSR" /r /d y
icacls "C:\System Volume Information\DFSR" /grant administrators:F /t

Step 3: Restart Services

Fire up both services again:

Start-Service DFS
Start-Service DFSR

Check the Application event log for Event ID 14524 or 14525 — those mean the database rebuilt cleanly. If you see 14523, something's still corrupted. Try a reboot and repeat step 2.

Why This Works

The DFS database is a Jet Blue database (same engine as Exchange 2010, if you remember that). It's prone to corruption after power loss or disk errors because it's constantly writing metadata. Deleting the database files forces the service to recreate them from the domain's DFS configuration in Active Directory. The namespace and replication topology are stored in AD, not locally. So you lose nothing but the local cache. Replication syncs back within minutes — or hours if the topology is large. I've seen it take 30 minutes on a 50-server DFS-R group. Be patient.

Less Common Variations

Sometimes the error points to a specific root. You'll see 'NERR_DfsInternalCorruption' with a different error code like 0X00000A65. That means a single namespace root database is corrupt. Same fix, but you can target just that root's GUID folder. To map GUIDs to roots, run:

dfsutil root export \\domain\root C:\root.xml

Then check the XML for the GUID. Delete only that folder. Saves time if you have multiple roots.

Another variant: DFS service starts but you get 'access denied' when browsing the namespace. That's not corruption — that's permissions. Check NTFS rights on the shared folder and the DFS root target. But if you got error 0X00000A64, it's the database.

On Server 2012 (not R2), the database lives in C:\Windows\System32\dfsr\. Same fix, different path. Update your script accordingly if you're still running 2012. If you are, upgrade. Seriously.

Prevention

Three things kill the DFS database:

1. Unexpected shutdowns — install a UPS on the server. DFS writes to disk constantly, and a crash mid-write corrupts the database faster than you can say 'event log'.
2. Full system drive — DFS needs at least 2 GB free on C:. Monitor disk space with alerts at 10% free. The database can't grow — it corrupts instead.
3. Antivirus scanning — exclude the DFS database folder from real-time scanning. I've seen McAfee and Symantec lock the database file mid-write. Add exclusions for C:\System Volume Information\DFSR and C:\Windows\System32\dfsr\.

Also, enable Volume Shadow Copy on the system drive. It won't prevent corruption, but you can roll back a corrupt database from a VSS snapshot in 10 seconds. Faster than the whole reset process. Schedule snapshots every 4 hours.

That's it. You're back in business. If the error comes back within a week, suspect disk hardware. Run chkdsk C: /f and check the disk with CrystalDiskInfo or your vendor's tool. A failing disk will keep corrupting databases until you replace it.