Kapothi Scroll: Banishing the Ghost VM in Hyper‑V

Kapothi — Sinhala slang for “getting into a big problem.” This scroll documents how we untangled one such haunting: a phantom VM that refused to die, flooding Event Viewer with endless errors.

🌀 The Symptom


Failed to load Hyper-V state for virtual machine 'MEGATRON-SVR-KAP-DSTN-04'

from the configuration: Unspecified error (0x80004005).

(Virtual machine ID 287FCA31-68ED-43C1-8B35-0452C2EDF743).

Hyper-V may not work properly. An attempt to reload the configuration will be made in a few minutes.

🔎 The Investigation Ritual

Check replication status

# PowerShell
Get-VMReplication -VMName "MEGATRON-SVR-KAP-DSTN-04"

→ Showed replication normal, so the issue wasn’t with Replica.

Try removing replication

# PowerShell
Remove-VMReplication -VMName "MEGATRON-SVR-KAP-DSTN-04" -Force

→ Command worked only with -VMName, not -VMId.

Search filesystem and registry

Looked under C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines
Checked registry keys under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization

→ No folder or key for the GUID found.

Inspect WMI repository

# PowerShell


Get-WmiObject -Namespace root\virtualization\v2 -Class Msvm_ComputerSystem |

Where-Object { $_.Name -eq "287FCA31-68ED-43C1-8B35-0452C2EDF743" }

→ Found the ghost entry still alive in WMI, status Degraded.

Check VM list

# PowerShell
Get-VM

→ VM showed as SavedCritical with “Cannot connect to virtual machine configuration storage.”

⚔️ The Cleansing Ritual

Remove ghost from WMI

# PowerShell


Get-WmiObject -Namespace root\virtualization\v2 -Class Msvm_ComputerSystem |

Where-Object { $_.Name -eq "287FCA31-68ED-43C1-8B35-0452C2EDF743" } |

Remove-WmiObject

Force remove VM object

Remove-VM -Name "MEGATRON-SVR-KAP-DSTN-04" -Force

Remove-VM -Id "287FCA31-68ED-43C1-8B35-0452C2EDF743" -Force

Purge leftover config files

Search for GUID‑named files (287FCA31-68ED-43C1-8B35-0452C2EDF743) under:

C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines
Replica storage paths (e.g., E:\Hyper-V\Replica\...)

Restart services

Restart-Service vmms

🌑 Final Cleansing (WMI Repository Reset)

If the ghost still lingers after all steps, reset the WMI repository:


net stop winmgmt

winmgmt /resetrepository

net start winmgmt

⚠️ Note: This is the last resort — it rebuilds the entire WMI repository, clearing any corrupted or stale entries.

✅ The Outcome

Event Viewer spam stopped.
Get-VM no longer listed the ghost VM.
Replication remained healthy for other VMs.

📜 Ritual Reflection

The ghost scroll wasn’t just in the shelves (registry) or archives (ProgramData) — it hid in the secret catalog (WMI). Hyper‑V kept trying to read it, failing each time. By purging the catalog entry, removing the VM object, and finally resetting the repository, the shrine keeper’s chant of errors was silenced.

✨ Kapothi Lesson: When Hyper‑V haunts you with “Failed to load state” errors, cleanse all three layers — filesystem, registry, and WMI. If the ghost still lingers, reset the repository to rebuild the shrine’s catalog from scratch.

Kapothi Tech Blog

Kapothi Scroll: Banishing the Ghost VM in Hyper‑V