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
Get-VMReplication -VMName "MEGATRON-SVR-KAP-DSTN-04"
→ Showed replication normal, so the issue wasn’t with Replica.
Try removing replication
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
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
Get-VM
→ VM showed as SavedCritical with “Cannot connect to virtual machine configuration storage.”
⚔️ The Cleansing Ritual
Remove ghost from WMI
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
or
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-VMno 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.






