Azure Virtual Machines Not Responding, Boot, RDP/SSH, and Disk Fixes

When your Azure Virtual Machine won't boot and you can't connect, you're essentially debugging blind, unless you use Boot Diagnostics. This feature captures a screenshot of whatever the VM is displaying on its virtual monitor at startup, and it also stores the serial console log. These two things together tell you almost everything you need to know about why the VM isn't responding.

To access it: open your VM in the Azure portal, scroll the left menu to Support + Troubleshooting, and click Boot diagnostics. If you see a screenshot showing a GRUB rescue prompt, a kernel panic trace, or a Windows blue screen with a stop code, you've already identified your problem category.

Common things you'll see and what they mean:

• GRUB rescue> prompt, The bootloader can't find the kernel or its configuration files. Usually caused by a bad kernel update or a disk geometry change.
• Kernel panic, not syncing, A kernel module failed to load, often after applying a kernel update that introduced a dependency issue.
• Windows blue screen with INACCESSIBLE_BOOT_DEVICE, Windows can't find or read its system drive. Often triggered when Hyper-V drivers are disabled inside the guest.
• BitLocker recovery screen, The VM's system drive is BitLocker-encrypted and the recovery key is being requested. This commonly appears after a hardware change or host migration.
• Waiting for /dev/sda1 (or similar), A Linux fstab entry is pointing to a device that doesn't exist at that path, and the system is hung waiting for it to appear.

You can also open the Serial console from this same menu section. The serial console gives you an interactive terminal to the VM even when SSH and RDP are completely down, it's one of the most powerful tools in Azure's troubleshooting toolkit and it's under-used by most people who manage Azure VMs.

Once you know what category of failure you're dealing with, continue to the relevant step below.

RDP not connecting is one of the most common Azure Virtual Machines problems I see reported. The error messages Windows gives you, "Remote Desktop can't connect to the remote computer" or "An authentication error has occurred (Code 0x80004005)", are almost deliberately unhelpful. Here's how to actually fix them.

Step one: check the NSG rules. In the Azure portal, navigate to your VM → Networking. Look at the inbound port rules for your Network Security Group. You need a rule allowing TCP traffic on port 3389 from your source IP. If that rule is missing, click Add inbound port rule and create it. This alone fixes probably 30% of RDP failures.

Step two: check if the VM guest NIC is disabled. Sometimes after an update or policy application, the network adapter inside the VM guest OS gets disabled. You can't fix this via RDP since you can't connect, but you can use the Run Command feature in the Azure portal (under Operations) to run a PowerShell command that re-enables it:

Get-NetAdapter | Where-Object {$_.Status -eq "Disabled"} | Enable-NetAdapter

Step three: diagnose with Event ID. If you can get partial access via the Azure Serial Console, check the Windows Event Viewer for specific RDP-related Event IDs. Event ID 1149 in the TerminalServices-RemoteConnectionManager log means authentication succeeded but the session failed to start. Event ID 4625 in the Security log means authentication failed, and the SubStatus code tells you exactly why (0xC000006D = bad credentials, 0xC0000064 = account doesn't exist, 0xC000006A = wrong password for existing account).

Step four: use the portal's Reset Password tool. Go to your VM → Help → Reset Password. For authentication errors, sometimes selecting Reset configuration only (not changing the password) is enough, this resets the RDP configuration itself, re-enables the Remote Desktop service, and sets the firewall rules. It's the equivalent of the old "fix RDP" script, built right into the portal.

If none of these work, redeploy the VM to a new node as described in the Quick Fix section. RDP connectivity issues tied to the underlying host resolve immediately after redeploy.

SSH failing on a Linux Azure Virtual Machine has its own distinct set of causes compared to Windows RDP issues. I want to walk you through the most impactful ones, especially SELinux, which bites people constantly and barely appears in generic troubleshooting guides.

SELinux misconfiguration is the silent killer of SSH sessions. Your SSH client will time out or get a "Connection refused" even though sshd is running and listening on port 22. SELinux is blocking sshd from accessing its required keys or socket files, and it does it silently by default. To diagnose this from the Azure Serial Console:

sudo getenforce
sudo ausearch -m avc -ts recent | grep sshd

If getenforce returns Enforcing and you see AVC denials for sshd, the fix is to restore the correct SELinux context on the SSH host key files:

sudo restorecon -R /etc/ssh/

Then restart sshd: sudo systemctl restart sshd. This resolves most SELinux-related SSH failures immediately.

Check your NSG just like you would for RDP. Go to your VM → Networking in the portal and verify that TCP port 22 is allowed inbound. Also check that the VM's internal firewalld or iptables rules aren't blocking it:

sudo firewall-cmd --list-all
sudo iptables -L INPUT -n -v | grep 22

Debian-specific SSH issues. If you're running a Debian Linux VM on Azure and SSH is failing after an OS update, check whether the update replaced /etc/ssh/sshd_config with a default version that doesn't match your configuration. The Azure Linux VM Agent for Debian has specific provisioning behavior you need to be aware of, after a fresh provisioning cycle, the host keys may be written to a different location than expected. Use Boot Diagnostics and the Serial Console to inspect /var/log/auth.log for the actual connection rejection reason.

VM Agent not responding. If Run Command in the portal also fails, the Azure Linux VM Agent (walinuxagent) may have stopped. From the Serial Console: sudo systemctl status walinuxagent. If it's not running, start it with sudo systemctl start walinuxagent and enable it to persist across reboots with sudo systemctl enable walinuxagent.

This is where things get genuinely technical, but don't let that scare you. Boot failures on Azure Virtual Machines are very recoverable. The key is that you need to repair the OS disk while it's attached to a different VM (called a repair VM), since you obviously can't boot into a broken OS to fix it.

The Azure VM repair process:

1. In the Azure portal, go to your broken VM and click Stop to deallocate it.
2. Take a snapshot of the OS disk: VM → Disks → click the OS disk → Create snapshot. Name it something like broken-vm-os-snapshot and save it. This is your safety net.
3. Create a new disk from that snapshot: go to Disks → Create → select Source: Snapshot and pick your snapshot.
4. Spin up a small repair VM (same OS family, a working Debian or Ubuntu VM for Linux, a Windows Server VM for Windows) and attach the new disk to it as a data disk.

For GRUB rescue on Linux: Mount the attached OS disk inside your repair VM, then reinstall GRUB. Assuming the disk appears as /dev/sdc:

sudo mkdir /mnt/broken
sudo mount /dev/sdc1 /mnt/broken
sudo mount --bind /dev /mnt/broken/dev
sudo mount --bind /proc /mnt/broken/proc
sudo mount --bind /sys /mnt/broken/sys
sudo chroot /mnt/broken
grub-install /dev/sdc
update-grub
exit

For UEFI boot failures: Azure Generation 2 VMs use UEFI instead of BIOS. Boot failures here are often caused by a corrupted EFI System Partition (ESP). Azure's official documentation on Linux VM UEFI boot failures notes that the ESP must be intact and the bootloader entry must be correctly registered. Inside your chroot, check efibootmgr -v and recreate the boot entry if it's missing.

For Windows INACCESSIBLE_BOOT_DEVICE / disabled Hyper-V drivers: This happens when someone installs Windows updates inside the VM and a change disables the synthetic Hyper-V storage drivers that Azure depends on. Attach the OS disk to a repair VM and use the Offline Registry Editor to re-enable the storvsc and vmbus drivers in HKLM\SYSTEM\CurrentControlSet\Services, set their Start value to 0.

fstab errors are a rite of passage for anyone managing Linux Azure Virtual Machines. One wrong entry in /etc/fstab, a UUID that no longer matches, a mount point that doesn't exist, or a network share that times out, and your VM hangs at boot waiting for a device that never shows up. It will sit there for 90 seconds, then drop to emergency mode. You won't be able to SSH in at all.

Diagnosing the fstab error: Boot Diagnostics will show you a screen that says something like Dependency failed for /data. Job dev-disk-by\x2duuid-XXXXXXXX.device timed out. That UUID is the device that Linux can't find.

Fixing fstab from the Serial Console: If your VM has the Azure Serial Console enabled (and it should, enable it now if not), you can often get an emergency root shell directly. At the emergency mode prompt, type the root password or just press Enter if none is set. Then edit fstab:

sudo nano /etc/fstab

Find the offending line, it's usually a data disk entry with a stale UUID or a network mount. Either comment it out by adding # at the start, or correct the UUID. To find the correct UUID for your attached disks:

sudo blkid

Save the file (Ctrl+O, Enter, Ctrl+X in nano), then reboot: sudo reboot. The VM should come up clean.

Azure Managed Disk issues: If a data disk detaches unexpectedly or shows as unavailable in the guest OS, check the Azure portal first. Go to your VM → Disks. If the disk shows as "Unattached," reattach it from the portal by clicking Attach existing disk. If the disk shows attached but the guest can't see it, run sudo rescan-scsi-bus.sh (Linux) or use Device Manager to scan for hardware changes (Windows) to force the OS to detect the newly attached disk without rebooting.

Disk encryption (BitLocker) problems: On Windows VMs with Azure Disk Encryption enabled, if the VM can't unlock the OS drive at boot, you'll see a BitLocker recovery screen. The recovery key is stored in your Azure Key Vault. Go to your Key Vault in the portal, find the secret named after your VM, copy the 48-digit recovery key, and enter it at the BitLocker prompt via the Serial Console. After recovery, verify your Key Vault access policies are correctly configured so this doesn't recur.