How to Troubleshoot Azure Virtual Machines Windows

If the quick fix didn't work, the next thing I always do is pull up Boot Diagnostics. This is Azure's built-in screen capture of the VM's display output, essentially a screenshot of what you'd see if you had a physical monitor plugged in. It tells you immediately whether Windows is booting, stuck on a BSOD, or showing a login screen that just isn't reachable via RDP.

Navigate to your VM in the Azure portal → Help → Boot diagnostics → click Screenshot. Wait a few seconds for the screenshot to refresh. What you see will tell you which path to take:

• Windows login screen visible: Windows booted fine. Your problem is network/RDP-level, not OS-level. Jump to Step 2.
• Blue screen with a stop code (e.g., CRITICAL_PROCESS_DIED 0x000000EF or INACCESSIBLE_BOOT_DEVICE 0x0000007B): Windows is crashing before RDP starts. Jump to Step 3.
• Black screen or "Preparing Automatic Repair": Windows Recovery Environment (WinRE) kicked in. This usually means a bad Windows Update or corrupted boot files. Jump to Step 4.
• Azure loading screen spinning indefinitely: The VM agent or Azure Guest Agent isn't responding. Try Stop (Deallocate) and Start again before proceeding.

You can also open the Serial Log from the Boot Diagnostics blade, click Serial log. This shows the raw text output of the Windows boot sequence, including driver loading messages and Windows Error Recovery entries. Look for lines containing BOOTMGR, winload, or disk error to pinpoint where the boot is failing.

If boot diagnostics is disabled on your VM, you'll see a message asking you to enable it. Enable it, then stop (deallocate) and restart the VM so it can capture the next boot cycle.

If the Boot Diagnostics screenshot shows a Windows login screen but you still can't RDP in, Azure Serial Console is your best friend. It gives you a direct keyboard connection to the VM's serial port, no network required. You can run PowerShell commands, fix NSG-independent Windows Firewall rules, restart services, and more, all without an RDP session.

To access it: VM → Help → Serial console. You'll be prompted to log in with your VM administrator credentials. Once you're at the Special Administration Console (SAC) prompt, type cmd and press Enter, then type ch -si 1 and press Enter to get a CMD channel.

Once inside, run these diagnostic commands:

:: Check if RDP service is running
sc query TermService

:: Check Windows Firewall status
netsh advfirewall show allprofiles

:: Verify RDP is enabled in the registry
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

:: Check which IPs are allowed by Windows Firewall for RDP
netsh advfirewall firewall show rule name="Remote Desktop - User Mode (TCP-In)"

If fDenyTSConnections returns 0x1, RDP is disabled at the OS level. Fix it:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
net start TermService

If the Windows Firewall RDP rule is missing, add it back:

netsh advfirewall firewall add rule name="Remote Desktop" protocol=TCP dir=in localport=3389 action=allow

After running these, try RDP again from your local machine. If it works, you should see the Windows login screen appear normally in your RDP client.

This is the big one. If Boot Diagnostics showed a BSOD stop code, particularly 0x0000007B INACCESSIBLE_BOOT_DEVICE, 0x000000EF CRITICAL_PROCESS_DIED, or 0xC000000E, Windows itself is broken. You can't fix it from inside the VM because Windows can't even start. You need to attach the OS disk to a healthy "repair VM" as a data disk, fix the problem there, then reattach it.

Microsoft provides an Azure CLI extension that automates most of this. Install it first:

az extension add --name vm-repair

Then create the repair VM:

az vm repair create \
  --resource-group MyResourceGroup \
  --name MyBrokenVM \
  --repair-username repairadmin \
  --repair-password "YourSecureP@ssw0rd!" \
  --verbose

This creates a new Windows Server VM, stops your broken VM, detaches its OS disk, and attaches it to the repair VM as drive D: (or E:, depending on existing disks). RDP into the repair VM using the credentials you specified above.

Once inside the repair VM, open an elevated PowerShell prompt and run the following to fix the most common boot issues, a corrupted BCD store:

# Identify the attached OS disk (usually D: or E:)
Get-Disk | Where-Object {$_.OperationalStatus -eq "Online"}

# Fix BCD on the attached disk (replace D: with your actual drive letter)
bootrec /rebuildbcd /s D:
bootrec /fixmbr /s D:
bootrec /fixboot /s D:

# Run CHKDSK on the attached OS volume
chkdsk D: /f /r

For 0x0000007B specifically (often caused by a Windows Update changing storage controller drivers), you may also need to run:

dism /image:D:\ /enable-feature /featurename:Microsoft-Windows-StorPort-Driver /all

After repairs, run az vm repair restore to reattach the fixed disk and delete the repair VM.

If your Azure Windows VM is alive but completely unresponsive, RDP times out, Serial Console is sluggish, the culprit is almost always CPU or memory exhaustion. A runaway process is starving everything else, including the Azure Guest Agent that normally lets you manage the VM.

First, check Azure Monitor to confirm. In the portal: VM → Monitoring → Metrics. Add the metrics Percentage CPU and Available Memory Bytes. If CPU is pegged at 95–100% and memory is near zero, you have a resource exhaustion problem.

The fastest way to kill a process without an RDP session is Run Command: VM → Operations → Run command → select RunPowerShellScript. This executes PowerShell directly via the Azure Guest Agent, bypassing RDP entirely.

# List top 10 CPU-hungry processes
Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name, CPU, WorkingSet

# Kill a specific offending process (replace 'MsMpEng' with your process name)
Stop-Process -Name "MsMpEng" -Force

# Or by PID
Stop-Process -Id 4521 -Force

# Check if Windows Update is the cause (a common culprit)
Get-Service wuauserv | Select-Object Status
Stop-Service wuauserv -Force

If Windows Defender's MsMpEng.exe is the offender (very common on freshly deployed VMs), it's typically doing an initial full disk scan. You can schedule it for off-hours or exclude the noisy paths via Run Command:

Add-MpPreference -ExclusionPath "C:\ProgramData\SomeApp"
Set-MpPreference -ScanScheduleDay 0  # 0 = disable scheduled scans temporarily

After the immediate crisis is resolved, resize the VM to a larger SKU if the workload genuinely needs more resources. In the portal: VM → Availability + scale → Size → pick a size with more vCPUs or RAM. Azure can resize most VMs without data loss, though it requires a restart.

Two problems I see constantly on Azure Windows VMs that people overlook: Windows activation failures and a broken Azure Guest Agent. Both are silent killers, the VM appears to run fine, but activation errors eventually trigger Windows' reduced functionality mode, and a broken Guest Agent means you lose access to Run Command, VM extensions, and password resets.

Fixing Windows Activation (error 0xC004F074): Azure uses its own KMS server. Your VM needs to reach azkms.core.windows.net on TCP port 1688. If you have a custom DNS server or restrictive NSG rules, this traffic may be blocked. Run this from inside the VM (via Serial Console or Run Command) to test:

# Test KMS connectivity
Test-NetConnection -ComputerName azkms.core.windows.net -Port 1688

# Force re-activation pointing at Azure KMS
cscript C:\Windows\System32\slmgr.vbs /skms azkms.core.windows.net:1688
cscript C:\Windows\System32\slmgr.vbs /ato

# Check current activation status
cscript C:\Windows\System32\slmgr.vbs /dli

Fixing the Azure Guest Agent: If the portal shows your VM as running but Run Command fails with "VM agent not ready," the Guest Agent service (WindowsAzureGuestAgent) has crashed or corrupted its state. Fix it via Run Command if it's partially working, or via Serial Console:

# Check Guest Agent service status
Get-Service WindowsAzureGuestAgent
Get-Service RdAgent

# Restart both services
Restart-Service WindowsAzureGuestAgent -Force
Restart-Service RdAgent -Force

# If services won't start, check for corrupt agent files
Get-Item "C:\WindowsAzure\Packages\GuestAgent\*"

If the Guest Agent is thoroughly broken, the cleanest fix is to download and reinstall it. From Serial Console, download the latest installer from the Microsoft update catalog and run it silently. You can also redeploy the VM (as described in the Quick Fix section), that typically resets the Guest Agent state automatically. After a successful Guest Agent restart, the portal should show the VM status as "Running" with extensions available again.