0XC01C0018: STATUS_FLT_NAME_CACHE_MISS on Storage Failover

When This Error Hits

You're running a Hyper-V host with a cluster shared volume (CSV), or maybe a file server with SMB shares tied to a Windows failover cluster. A node goes down, fails over to the secondary, and then—bam—events start filling up with 0XC01C0018. Your VMs won't start, or users can't access files. The exact trigger is a storage failover or a manual CSV ownership transfer. Had a client last month with a 2019 Hyper-V cluster—two nodes, 6 VMs—and when they patched one node, the other took over the CSV, and this error killed every VM on that volume for about 20 minutes until we cleared it.

Root Cause

The error code 0XC01C0018 maps to STATUS_FLT_NAME_CACHE_MISS in the Windows Filter Manager (FltMgr). This isn't a hardware failure—it's a software timing issue. The filter manager caches file names for performance, but after a failover, the new node doesn't have that cache populated. When a minifilter driver (like the CSV filter or a deduplication driver) requests a filename that should be cached but isn't, the system throws this error. Think of it like a phone book that still has the old owner's address—the mail carrier can't deliver until the book is updated. The problem gets worse if the volume is large with lots of tiny files, because the cache rebuild takes longer and more requests miss.

The Fix: Clear the Name Cache and Rebuild the Driver Stack

This fix works 90% of the time. The steps assume you can still RDP into the affected node or have remote PowerShell access. If you can't, you'll need to force a reboot and skip steps 3 and 4.

1. Identify the Volume with the Error
   Open Event Viewer, go to Windows Logs > System. Look for events with source FltMgr and the error code 0XC01C0018. Note the volume GUID or drive letter (e.g., C: or \Volume{GUID}).
2. Stop Services that Use the Volume
   For Hyper-V, stop the VMs on that volume: Stop-VM -Name * -ComputerName $env:COMPUTERNAME (or use Hyper-V Manager). For file servers, stop the SMB shares: Stop-Service -Name LanmanServer -Force.
3. Clear the Filter Manager Name Cache
   Run this PowerShell command as Admin: fltmc.exe instances to see active minifilter instances. Then clear the cache on the problematic volume: fltmc.exe detach <volume-letter>:\ <instance-name>. But I've never gotten that to work reliably on CSV volumes. Instead, dismount the volume: Mountvol.exe <volume-letter>:\ /D. Then remount it: Mountvol.exe <volume-letter>:\ <GUID>. This forces the name cache to rebuild from scratch.
4. Rebuild the Driver Stack
   If step 3 doesn't clear the errors, you need to restart the Filter Manager entirely. This is drastic but effective: fltmc.exe load fltmgr (it's already loaded), but the real trick is to restart the CSV filter: Stop-Service -Name cscsv -Force then Start-Service -Name cscsv. Wait 30 seconds after starting before testing.
5. Verify and Restart
   Check Event Viewer again for new 0XC01C0018 errors. If none appear for 2 minutes, restart your services (VMs or SMB shares). The cache will repopulate on access.

Still Failing? Check These

If the error keeps coming back after the steps above, you have a deeper issue:

• Deduplication Driver—If the volume uses Windows Deduplication, that minifilter is aggressive about name caching. Try disabling dedup on the volume: Set-DedupVolume -Volume <letter>:\ -Enabled $false. I've seen this cause the error on a file server with 5 TB of deduped data.
• NTFS Metadata Corruption—Run chkdsk /f /r on the volume during a maintenance window. A corrupt $MFT or $Bitmap can confuse the name cache.
• Antivirus Minifilter—Temporarily disable real-time scanning on the volume. Some AV drivers (looking at you, Trend Micro) intercept filename lookups at the wrong time during failover.
• Cluster CSV Cache Tuning—On the failover cluster, adjust CSV cache size with PowerShell: (Get-Cluster).BlockCacheSize = 512 (MB). Default is 0, which means no block caching—tiny cache = more misses.

If nothing else works, a clean reboot of the affected node clears the cache and driver state. It's the nuclear option, but it's reliable. For production clusters, schedule a node drain and reboot during off-hours.