STATUS_NO_EAS_ON_FILE (0XC0000052) Fix – File Has No Extended Attributes

You’re debugging an app or driver and you hit STATUS_NO_EAS_ON_FILE (0XC0000052). It’s cryptic and stops you cold. Let’s fix it now.

The Immediate Fix

If your application or driver triggers this error, the problem is you’re calling ZwQueryEaFile or NtQueryEaFile on a file that has zero Extended Attributes (EAs). The system returns this status code because there’s nothing to enumerate.

The fix depends on what you want to do:

1. If you’re reading EAs and expect them to exist – check if the file actually has EAs first using NtQueryInformationFile with FileBasicInformation and looking at the EaSize field. If EaSize is 0, don’t call NtQueryEaFile.
2. If you’re writing a tool that must handle both cases – catch STATUS_NO_EAS_ON_FILE as a valid return. It’s not a crash, it’s just information. Treat it like “null” for EA data.
3. If you want to add EAs to the file – use NtSetEaFile with a valid FILE_FULL_EA_INFORMATION structure. One common EA name is User.Lorem with some value.

Real-world trigger: This happens often with backup software (like old versions of Veritas or Symantec Backup Exec) that tries to read NTFS EAs from every file. If the file is a plain text file on a non-NTFS volume (FAT32, exFAT, or a network share that strips EAs), you’ll get this error.

Why the Fix Works

Extended Attributes are optional metadata on NTFS files. They’re not present on every file – most files have zero EAs. The Windows kernel’s NtQueryEaFile function correctly returns STATUS_NO_EAS_ON_FILE when the EA list is empty. The mistake is treating this as an error instead of an expected result. Once you check EaSize before querying, you avoid calling the function when it has nothing to return. Adding EAs works because you’re giving the file the metadata the query expects.

Less Common Variations

Here are scenarios where this error shows up in unexpected places:

• WSL (Windows Subsystem for Linux) file access: WSL’s drvfs layer strips or ignores EAs on files in the Windows drive. If a Linux app tries to read EAs on a file in /mnt/c/, you’ll get STATUS_NO_EAS_ON_FILE. Fix: don’t use EAs on cross-filesystem files, or copy the file to the WSL ext4 volume first.
• Anti-virus or file monitoring drivers: Some file system filter drivers (like older versions of McAfee or Sophos) enumerate EAs for every file during scans. They crash if they don’t catch this status code. The driver vendor needs to handle it gracefully – you can’t fix that yourself except by updating the AV software.
• Custom applications using FindFirstFile / FindNextFile with GetFileInformationByHandleEx: If you’re using these to read EAs, you might miss the status code and think the file is corrupted. The real issue: you’re querying a file on a non-NTFS filesystem. Check the volume’s filesystem type first with GetVolumeInformation.
• Network drives (SMB shares): Some SMB servers don’t support EAs. If the server is a Linux Samba share without EA support, or an old Windows server with the feature disabled, NtQueryEaFile will return this error. The client app must check the share’s capabilities via FSCTL_GET_NTFS_VOLUME_DATA.

Prevention

To avoid this error in your own code:

1. Always call NtQueryInformationFile with FileBasicInformation first. Check the EaSize field. If it’s zero, don’t query EAs.
2. Wrap NtQueryEaFile calls in a loop that accepts STATUS_NO_EAS_ON_FILE as a non-terminal return. Treat it as “no data” and move on.
3. If you’re writing EAs, verify the filesystem supports them. FAT32 and exFAT do not. Use GetVolumeInformation and check the filesystem name string – if it’s not NTFS or ReFS, skip EA operations.
4. For driver developers: never assume every file has EAs. Your filter driver should pass through STATUS_NO_EAS_ON_FILE without modifying it. Handle it in your post-operation callback by setting the IRP’s IoStatus.Status to that value and completing the request.

Bottom line: This isn’t a corruption or a crash – it’s a normal kernel response that means “there’s nothing here.” Design your code to accept that, and you’ll never see this error as a problem again.