Azure VM stuck in 'Stopping' state after forced shutdown

Why your Azure VM gets stuck in 'Stopping'

You forced a shutdown — either from the portal, PowerShell, or the guest OS — and now the VM sits there with the status Stopping. It's been 10 minutes. Maybe an hour. The icon's still spinning.

This happens because Azure's fabric controller expects the VM agent to report back that the OS has shut down cleanly. When you force it — especially on a VM that's mid-update, has a hung process, or lost network connectivity to the host — the agent can't respond. The fabric controller waits. And waits. The VM stays in 'Stopping'.

I've seen this most often on Windows Server 2016 and 2019 VMs that were in the middle of Windows Update when someone hit 'Force stop' in the portal. Also on Linux VMs running old 4.x kernels with buggy KVM drivers.

Start here: The 30-second fix

Don't do anything drastic yet. Try the simplest thing first.

1. Go to the Azure portal and open your VM's overview blade.
2. Click Stop again — not Restart, not Delete. Just Stop.
3. Wait 30 seconds.

After you click Stop a second time, the Azure fabric controller re-sends the shutdown command. If the guest agent is hung but still reachable, this second kick often wakes it up. The status should flip to Stopped (deallocated) within a minute.

If that doesn't work, move to the next step.

5-minute fix: Force stop from Azure CLI or PowerShell

The portal can be flaky when the VM's in a weird state. Command-line tools talk directly to the Resource Manager API and bypass the portal's UI overhead.

Option A: Azure CLI

Open a terminal (Cloud Shell works fine) and run:

az vm stop --resource-group MyResourceGroup --name MyVM --no-wait

The --no-wait flag tells the CLI to fire the command and return immediately. That's useful because you don't want the command itself to hang.

After that, check the status:

az vm show --resource-group MyResourceGroup --name MyVM --query "provisioningState" -o tsv

You should see Stopped (deallocated) within 2-3 minutes.

Option B: PowerShell (Az module)

Stop-AzVM -ResourceGroupName "MyResourceGroup" -Name "MyVM" -Force

Same idea — the -Force switch bypasses any confirmation prompts and sends the shutdown directly.

If the CLI or PowerShell command itself hangs (I've seen it), just Ctrl+C out and try again with a short timeout:

az vm stop --resource-group MyResourceGroup --name MyVM --timeout 30

Still stuck? Move to the advanced fix.

15+ minute fix: Restart the VM's host node

Sometimes the problem isn't the guest OS — it's the Azure host server itself. The fabric controller can lose track of the VM's state. You need to force a redeployment onto a different host.

Redeploy the VM

This moves your VM to a new Azure host server. Your disks, IPs, and all settings stay intact. It's the nuclear option, but it works.

1. In the portal, go to your VM's blade.
2. Click Help in the left menu, then Redeploy + reattach.
3. Click Redeploy.

After you click Redeploy, expect the VM to disappear from the portal for 5-10 minutes. That's normal — it's being moved. When it reappears, the status will be Starting.

If the Redeploy button is grayed out (because the VM is stuck in 'Stopping'), use the API directly:

az vm redeploy --resource-group MyResourceGroup --name MyVM

Or PowerShell:

Restart-AzVM -ResourceGroupName "MyResourceGroup" -Name "MyVM" -Redeploy

After redeployment, stop the VM normally from the portal. It should work now.

What to do if none of these work

You've tried the double-stop, the CLI, and the redeploy. The VM is still stuck in 'Stopping'. At this point, you need to check two things:

1. Is the VM agent healthy? If the agent is corrupt, the fabric controller will never get confirmation. You might need to delete the VM (keep the disks) and create a new one from the same OS disk. Microsoft has a guide for recovering VMs with broken agents.
2. Is there a lock on the VM? Check the Locks blade in the portal. If someone applied a Delete or Read-only lock, the VM can't change state. Remove the lock, then stop the VM.

I've had exactly one case in five years where neither of these worked, and we had to open a support ticket. Azure support forced a host reboot on the backend — took them 3 hours. But 99% of the time, the redeploy or the double-stop fixes it.

Preventing this from happening again

You can avoid this whole mess by not forcing shutdowns unless you absolutely have to. When you need to stop a VM, always shut down from inside the guest OS first — then use the portal to deallocate. The fabric controller gets a clean handshake, and the VM stops in seconds.

If you're automating shutdowns (e.g., dev/test VMs turning off at night), add a 60-second grace period for the guest OS to shut down cleanly before the Azure API issues the stop command. Most automation scripts skip that, and that's exactly when you get stuck in 'Stopping'.