Fix UUID 0X0000076C - The object is the nil error

Cause #1: Corrupt Hyper-V virtual machine configuration

This is the most common place I see 0X0000076C. You're managing a Hyper-V host (2016, 2019, or 2022 usually) and either SCVMM or Failover Cluster Manager throws that error. The VM in question has a nil GUID in its .vmcx or .xml file. This usually happens after an unclean VM export, a failed storage migration, or a power loss during a VM save operation.

The fix: First, find the broken VM. Run this on the Hyper-V host:

Get-VM | Where-Object {$_.Id -eq '00000000-0000-0000-0000-000000000000'}

If that returns a VM, you've found your culprit. Next, you need to rebuild the VM configuration. Do not delete the VHDX files. Here's the process:

1. Note the VM's name and any snapshots it has.
2. Delete the VM with Remove-VM -Name "BrokenVM" -Force. This only removes the config, not the disks.
3. Recreate the VM with the same name, generation, memory, and virtual switch settings. Use the existing VHDX as the boot disk.
4. If you had snapshots, you'll lose them — no way around it. The snapshot chain is tied to the nil UUID.

I've seen admins waste hours trying to edit the XML directly. Don't bother. The VM configuration store is hashed and version-checked. Rebuild it clean.

Cause #2: Corrupt Active Directory object with a nil objectGUID

Second most common cause: an AD object — usually a user, computer, or group — has a nil objectGUID. This happens when an AD object gets created and then immediately replicated before the GUID is assigned. It can also happen from a bad authoritative restore or a migration tool that doesn't assign GUIDs correctly. You'll see 0X0000076C in event logs (look in Directory Service or Application logs) or when running PowerShell queries like Get-ADUser against that object.

Find it: Run this against your domain controller:

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

If you get a hit, you need to get rid of that object. There's no way to retroactively assign a GUID — it's set at creation and immutable. The object is dead.

The fix:

1. If it's a user or computer, disable it first. Then delete it after verifying nothing depends on it. Check group memberships, delegation, and service accounts.
2. If it's a group, remove all members first, then delete it. Recreate the group with a fresh GUID.
3. If it's a service account (gMSA or sMSA), this gets trickier. You might need to re-provision the KDS root key and recreate the account. I've had to do this twice in 14 years — it's rare but a headache.

Don't bother with ADSI Edit repair attempts. The nil GUID is a write-once attribute. Deletion and recreation is the only path.

Cause #3: Broken Windows System Image Manager (WSIM) or unattended answer file

This one's less common but I've hit it on Windows 10/11 and Server 2022 deployments. You're building an autounattend.xml or a provisioning package, and during sysprep or OOBE, you get 0X0000076C. The culprit is a blank @ProductKey or @ProcessorArchitecture attribute, or a component with a nil wcm:action attribute. Windows Setup tries to parse it, finds a nil UUID for the component, and chokes.

Find it: Open your answer file in Windows System Image Manager (WSIM). Look for any component or setting that has a blank or missing wcm:action attribute. Also check Microsoft-Windows-Setup > UserData > ProductKey — if the Key field is empty, that'll trigger it.

The fix:

1. Open the .xml or .clg file in a text editor (Notepad++ is fine).
2. Search for 00000000-0000-0000-0000-000000000000 — that's the nil UUID WSIM inserts when an attribute is blank.
3. Remove the entire offending element or fill in the required value. For ProductKey, either put a valid key or use the WillShowUI="OnError" attribute to skip it.
4. Re-validate the file in WSIM before using it for deployment.

I've seen people waste a day rebuilding deployment shares. Nine times out of ten, it's one blank attribute in the answer file. Fix that and the error evaporates.

Quick-reference summary table

That's it. Three causes, three fixes. No magic. Just methodical elimination. If you're still stuck after checking all three, post the exact context — host OS, what you were doing, and the full error message — and I'll dig deeper.