Troubleshoot Hyper-V VMMS service issues that prevent virtual machines from starting, stopping, or being managed.
Confirm VMMS itself is running before assuming the problem is with a specific VM — a stopped or crash-looping VMMS blocks every VM management operation on the host.
A repeatedly crashing VMMS almost always has a specific event ID behind it — find that before restarting the service repeatedly.
Use Get-Service vmms and review the Service Control Manager event log when the service is stopped or repeatedly restarting.
Check VMMS status
Confirm the Hyper-V Virtual Machine Management service is actually running — if it's stopped, no VM on the host can be started, stopped, or even queried through Hyper-V Manager or PowerShell, regardless of whether individual VMs are otherwise healthy:
Get-Service vmmsIf it shows as running but Hyper-V Manager itself is unresponsive or times out, check whether the service is actually crash-looping rather than genuinely stable — a service that restarts every few minutes can briefly show "Running" between crashes:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; Id=7031,7034} -MaxEvents 20 |
Where-Object {$_.Message -match 'vmms'}Check host resources
VMMS depends on the system volume having free space and on the host having enough available memory to service management requests — it can become unresponsive (not crashed, just very slow to respond) when the boot/system volume is nearly full or memory is critically constrained:
Get-Volume | Select-Object DriveLetter, SizeRemaining, Size
Get-Counter '\Memory\Available MBytes'This is worth checking before diving into event logs, since resource exhaustion produces vague or misleading VMMS error messages that look configuration-related but aren't.
Identify which VM is actually involved
If VMMS crashes only when a specific operation touches a specific VM (rather than being globally unresponsive), that VM's configuration is the likely trigger — most commonly a corrupted checkpoint chain, a virtual disk on storage that's since become unavailable, or a malformed configuration file after an unclean shutdown. Check its checkpoints and virtual disk paths:
Get-VMSnapshot -VMName "VMName"
Get-VMHardDiskDrive -VMName "VMName" | Select-Object PathConfirm every listed disk path actually exists and is reachable — a VM referencing a disk on a disconnected iSCSI target or a removed CSV is a common VMMS destabilizer.
Review Hyper-V event logs for the specific error
The generic System log rarely has enough detail — go to the Hyper-V-specific operational logs, which log the actual failure reason:
Get-WinEvent -LogName 'Microsoft-Windows-Hyper-V-VMMS-Admin' -MaxEvents 50 |
Where-Object LevelDisplayName -in 'Error','Critical'Also check Microsoft-Windows-Hyper-V-Worker-Admin if the crash correlates with a specific VM's worker process rather than VMMS itself — the two logs cover different layers and a worker process crash can look like a VMMS problem from the console.
Check dependencies: storage, permissions, and cluster state
If the affected VMs are on shared storage, confirm the CSV or SMB share is actually online and reachable from this host — a CSV that dropped offline produces VM management failures that look like a VMMS problem rather than a storage one. On clustered hosts, also check the Cluster service and whether this specific node is seeing the same failures as others in the cluster, which tells you whether the issue is host-specific or shared storage/cluster-wide.
Validate after remediation
After restarting VMMS or resolving the underlying dependency, don't just confirm the service shows "Running" — actually perform the VM operation that originally failed (start, stop, checkpoint) and confirm it completes. Then watch the Hyper-V-VMMS-Admin log for a period afterward if the original symptom was a crash loop, since a genuinely fixed root cause should mean no recurrence over the following hours, not just an immediately successful restart.