UUID 0XC002004D – The object is the nil fix

I got a call from a client last month – their 2019 file server kept throwing 0XC002004D in the System log every time backup ran. Event Viewer showed FsRtlGetFileId failing on a null GUID. Their backup software (Veeam) was choking on a ghost volume that didn't exist anymore. The error message is literal: the object is the nil – Windows tried to look up a UUID that's all zeros. It's not a normal file. It's a phantom.

1. Active Directory replication tick – stale object with null GUID

This is the number-one cause I've seen in the field. Some domain controller replicates an object (usually a computer or user account) that got created with an empty objectGUID. It's rare, but when Windows tries to reference that object by its UUID – say during a Get-ADObject or a group policy update – you get the nil error.

How to find it

Fire up PowerShell on a Domain Controller (run as admin). Search for any object whose objectGUID is exactly 00000000-0000-0000-0000-000000000000:

Get-ADObject -Filter {ObjectGUID -eq '00000000-0000-0000-0000-000000000000'} -Properties *

If it returns a result – usually a user or computer account that got created during a failed migration – you've found the zombie. Check the DistinguishedName to see where it lives. Then delete it:

Get-ADObject -Identity "CN=ZOMBIE,OU=Users,DC=contoso,DC=com" | Remove-ADObject -Confirm:$false

If the object won't delete (AD can be stubborn), use ADSI Edit instead. Connect to the partition, browse to the object, right-click and delete. I had one case where the null GUID was on a system volume that had no SID – had to use ntdsutil metadata cleanup to kill it. But start with ADSI Edit.

What to watch for

This usually pops up after a failed domain controller promotion or an inter-forest migration. If you're seeing the error in multiple DC event logs, it's a replication problem. Let it replicate the deletion naturally – or force replication with repadmin /syncall.

2. Disk volume ghost – stale volume GUID in registry or VSS

Second most common cause: you unplugged an external drive, deleted a volume, or migrated a disk, but the Volume Shadow Copy service (VSS) still holds a reference to the old volume GUID. Windows tries to access it, finds nil, and throws 0XC002004D. This is what bit my backup client.

Find the volume ghost

Open an admin Command Prompt or PowerShell and list all volume GUIDs on the system:

mountvol

Look for any line like \\?\Volume{00000000-0000-0000-0000-000000000000}\. If you see a nil GUID, that's your phantom. Remove it with:

mountvol \\?\Volume{00000000-0000-0000-0000-000000000000}\ /d

If mountvol doesn't show the nil GUID (it sometimes hides it), check the registry directly. Navigate to:

HKLM\SYSTEM\MountedDevices

Look for a value whose name contains {00000000-0000-0000-0000-000000000000}. If you find it, delete that registry value. Back up the key first – I've seen people delete the wrong thing and lose boot drive mappings.

VSS writers might be holding it too

Run vssadmin list shadows and check the Shadow Copy Volume column for a nil GUID. If you see one, delete all shadows with vssadmin delete shadows /all. This nukes all restore points, but so does a corrupted VSS. Worth it.

3. Corrupted volume from a botched disk clone or backup restore

Third scenario: someone cloned a disk (often with a third-party tool like Acronis or Macrium) and the clone didn't regenerate the volume GUID properly. The system has two volumes with the same GUID, or one with a nil GUID. This shows up as 0XC002004D during chkdsk, defrag, or backup reads.

Check for duplicate or nil GUIDs on disks

Use fsutil to dump the volume information:

fsutil volume queryguid C:

If it returns all zeros, the volume itself is damaged. Run chkdsk C: /f first – fixes a surprising number of these cases. But if chkdsk reports corruption in the volume header, you might need to reformat and restore from backup. That's the hard but honest fix.

For a quick check across all volumes, loop through them in PowerShell:

Get-Volume | ForEach-Object { $guid = (Get-ItemProperty -Path "HKLM:\SYSTEM\MountedDevices" -Name "\\??\Volume{$($_.UniqueId)}" -ErrorAction SilentlyContinue)."(default)"; if ($guid -eq $null) { Write-Host "$($_.DriveLetter) – no GUID or nil" } }

If you find a drive with a missing GUID, dismount it, assign a new GUID with mountvol, then remount. I've done this on a client's D drive after a failed clone – worked like a charm.

Quick-reference summary

That's it. Three causes, three fixes. Start with the AD check if it's a domain member, then move to mountvol. Most of the time, you're killing a ghost that shouldn't have been there in the first place. Now go delete that zombie.