STATUS_OFFLOAD_READ_FLT_NOT_SUPPORTED (0XC000A2A1) fix

What actually happens with 0XC000A2A1

You're trying to do a copy offload — maybe a Hyper-V live migration, a Storage Replica sync, or just an ODX copy — and it fails with 0XC000A2A1. The message says "A file system filter on the server has not opted in for Offload Read support". That's Microsoft's way of saying a third-party filter driver is sitting in the IO path and refuses to acknowledge the offload command.

This isn't a hardware problem. It's not NTFS corruption. It's a driver compatibility gap. The filter driver sees the FSCTL_OFFLOAD_READ IRP and either drops it or returns an error because it wasn't written to handle that request type. Windows expects all filters in the stack to participate; if one doesn't, the whole operation fails.

Cause 1: Antivirus or backup filter drivers

In my experience, this is the culprit 80% of the time. Antivirus software like McAfee Endpoint Security, Trend Micro Deep Security, or Symantec Endpoint Protection registers a file system filter (minifilter) that intercepts IO. Same goes for backup agents like Veeam or Commvault that hook into the volume.

These filters were often written before Windows Server 2012 R2 introduced the Offload Data Transfer (ODX) feature, or if they were updated, the developer simply didn't add the FLTFL_REGISTRATION_SUPPORT_NFS_ODX flag in the DriverEntry routine. Without that flag, the filter silently blocks offload.

How to identify the blocking filter

Open an elevated PowerShell session and run:

fltmc instances

Look at the Altitude column — a higher altitude means the filter sits closer to the application, lower is closer to the disk. The filter that's blocking is likely one with altitude in the 300000 to 400000 range (antivirus, backup). You can also grep for known offenders:

fltmc filters | findstr /i "mcafee symantec trend veeam"

The fix: update or reconfigure the filter driver

First, check if the vendor has an updated driver that explicitly supports ODX. For example, McAfee's mfenlfk.sys gained support in version 10.7.1. If you're stuck on an older version, that's your problem.

If updating isn't an option, you can sometimes exclude the specific volumes that need offload from antivirus scanning. On McAfee, go to On-Access Scan Policies → Exclusions → Excluded Paths and add the mount point or volume GUID. On Trend Micro, it's under Real-time Scan → Exclusions.

Important: Excluding the volume removes protection on that volume. Only do this on volumes that don't hold executables or user data — like a dedicated CSV for Hyper-V VHDX files.

If exclusions don't work, you can try dynamically unloading the filter for the specific volume using fltmc detach, but that's risky — you might crash the service. I don't recommend it in production except as a temporary test.

Cause 2: Storage Spaces Direct (S2D) and CSV snapshots

On Windows Server 2016 and 2019 with Storage Spaces Direct, the csvflt.sys filter handles Cluster Shared Volumes. When you take a VSS snapshot of the CSV, the snapshot provider creates a differencing area that doesn't support offload reads. The filter then returns this error.

This typically happens during backup jobs that trigger a snapshot just before the copy offload. The sequence is: backup starts → VSS snapshot → offload copy tries to run → filter sees the snapshot view → throws 0XC000A2A1.

How to confirm it's the snapshot

Run fltmc instances and check if csvflt has an altitude of 0x280000 or so. Then check if a snapshot is active:

vssadmin list shadows /for=C:

If you see a shadow copy active at the time of the failure, that's your cause.

The fix: don't do offload copies on snapshot volumes

Option A: Schedule the backup and the offload copy at different times, so the snapshot is gone when the offload runs. This is the simplest fix.

Option B: If you're using Backup Exec or NetBackup, check if the backup agent supports ODX passthrough. Some newer versions let the backup filter forward offload requests to the underlying volume even when a snapshot is present. Update your backup software.

Option C: Disable snapshots on that volume entirely — but that breaks backup recovery points. Not recommended unless you have another snapshot mechanism.

Cause 3: Custom minifilters from in-house or third-party storage solutions

This is rare but I've seen it with Dell EMC RecoverPoint for Virtual Machines, HPE StoreOnce Catalyst, and custom deduplication filters. These filters sometimes implement their own IO stack and simply never added the offload registration flag. The error appears consistently, not just during backups.

How to diagnose

Run this command to see which filters are loaded and their altitude:

fltmc filters | findstr /i "offload"

If nothing appears, that's the problem — none of the filters advertise offload support. Next, use Process Monitor to capture the IRP_MJ_FILE_SYSTEM_CONTROL with FSCTL_OFFLOAD_READ. Filter by Path containing your volume. Look at the Result column: if it says NOT_SUPPORTED, the last filter in the stack returned that status.

The fix: disable the custom filter on the target volume

You have a few options:

• Unload the filter entirely with fltmc unload <filter_name>. This requires the vendor to have implemented an unload routine, which not all do.
• Use fltmc detach <filter_name> <volume> to remove it from just the volume that needs offload. Example: fltmc detach dedupfilter C:.
• Contact the vendor and ask for a version that includes the FLTFL_REGISTRATION_SUPPORT_NFS_ODX flag in FltRegisterFilter. That's the real fix.

I've also seen cases where uninstalling the vendor's software and rebooting resolved it. If you go that route, check the registry key HKLM\SYSTEM\CurrentControlSet\Services\ for remnants of the filter driver. Delete any leftover services manually — but back up the hive first.

Quick-reference summary table

Start with fltmc instances. Find the filter that's higher than expected. That's your blocker. Update it or remove it from the IO path. Nine times out of ten, this error goes away after that.