Fix STATUS_OFFLOAD_WRITE_FLT_NOT_SUPPORTED (0xC000A2A2)

What's happening when you see 0xC000A2A2

You're trying to copy a large file on a Windows Server (2019 or 2022) — maybe using Storage Spaces Direct or just a regular CSV volume. The copy fails with STATUS_OFFLOAD_WRITE_FLT_NOT_SUPPORTED (0xC000A2A2). Or you see it in Event Viewer under Storage-Class Memory or Offload events. The system is trying to use ODX (Offloaded Data Transfer) to move data between storage endpoints without touching host memory, but a file system filter driver sitting on top of the volume said "nope, I don't support that".

ODX is great for moving terabytes of VHDX files in seconds. But the moment you have a filter driver that doesn't register for FSCTL_OFFLOAD_WRITE, Windows bails and falls back to a boring old buffered copy — or just fails outright.

The real fix is identifying which filter driver is blocking offload writes and either updating it or disabling it for that volume. Let's walk through it.

Cause #1: Antivirus or security software filter

This is the most common reason. Antivirus products like Symantec Endpoint Protection, McAfee, Trend Micro, or even Windows Defender (when configured with real-time scanning on CSV volumes) attach filter drivers that intercept all I/O. Many of them — especially older versions — never bothered to register for offload write support.

How to confirm: Run this command as Administrator:

fltmc instances

Look for entries like Symantec, McAfee, TmFilter, WdFilter, or similar. Under the "Altitude" column you'll see numbers — the lower the altitude, the closer to the filesystem. An antivirus filter typically hangs around 328000-328100.

Fix it: The specific fix depends on your antivirus vendor. But here's a general approach:

1. Open your antivirus management console.
2. Find the policy or settings for real-time scanning.
3. Look for an option like "Enable offload data transfer (ODX) support" or "Enable copy offload."
4. Enable it. If you can't find that setting, you'll need to update to the latest version of the antivirus software.
5. If updating isn't possible, create an exclusion for the CSV volume or the specific folder where you're copying files.
6. Reboot the server to make sure the filter driver reloads with the new settings.

After the reboot, rerun fltmc instances and check if the problem persists. You can also test offload with this PowerShell snippet:

Get-CimInstance -ClassName Win32_Volume | Where-Object {$_.DriveType -eq 3} | Select-Object DriveLetter, SupportsFileLevelCompression, SupportsDiskQuotas

That won't show offload specifically, but if you get a successful copy now without the error, you're good.

Cause #2: Backup software filters (VSS writers, snapshot providers)

Backup agents from Veeam, CommVault, NetBackup, or even Windows Server Backup often install their own file system filters. These are usually volume snapshot providers or change journal tracking drivers. They attach to volumes to track block-level changes. Some of these — especially older versions — don't register for offload write.

How to spot them: Run fltmc filters and look for names like VeeamFSR, VeeamBackupFilter, cvSnap, NBSnapshot, wbx_*. Backup filters usually sit at a higher altitude (300000-350000) but can be anywhere.

Fix it:

1. Open the backup software management console and check for updates. Most major vendors have released patches that add offload support.
2. If an update exists, install it and restart the VSS service: net stop vss then net start vss.
3. If no update is available, you can try to temporarily disable the backup filter for the volumes where offload is needed. This varies by product.
4. For Veeam specifically, go to Registry Editor:

HKLM\SYSTEM\CurrentControlSet\Services\VeeamFSR\Parameters

Create a DWORD value called OffloadWriteSupported and set it to 1. Then reboot.

Cause #3: Storage driver or SAN multipathing filter

Less common, but real. Multipath I/O (MPIO) drivers or storage vendor-specific filters (like Dell EMC PowerPath, HP MPIO, or NetApp DSM) can block offload writes if they're not coded to support ODX. This usually shows up in SAN environments where you're doing direct copy between LUNs.

How to confirm: Check Event Viewer under Applications and Services Logs > Microsoft > Windows > Storage-Class Memory for event ID 306 or similar. The event details will name the filter driver causing the issue.

Also run fltmc instances -v and look for storage-related filters like mpio, fcinfo, PowerPath, or NetApp.

Fix it: Update your multipathing driver to the latest version from your SAN vendor. If that doesn't work, you may need to disable offload write for specific volumes. That's a last resort — don't do it casually because it kills copy performance. You can disable ODX entirely on a volume using:

fsutil behavior set disableoffload 1

But that's a global setting for all volumes on that server. A better approach is to exclude the volume from the offending filter. Contact your storage vendor for the exact method because it's different for each.

Quick-reference summary table

Don't waste time guessing. Run fltmc instances first. That command shows you exactly which filters are loaded on the volume where the error happens. The name of the filter is your clue to which software is responsible. Update that software, and you'll likely never see 0xC000A2A2 again.