Symptoms
- Virtual machine fails to respond to keyboard or mouse activity.
- Virtual machine is not responding to network communication.
- Virtual machine does not allow access via RDP, vCenter Server virtual machine console screen, or other connection methods.
- Virtual machine screen is black and does not refresh.
- You may see one or more of these errors similar to:
/init: /init: 151: Syntax error: 0xforce=panic
Kernel panic – not syncing: Attempted to kill init!
PAGE_FAULT_IN_NONPAGED_AREA
Error codes 6005, and 6008 in Windows Event Viewer
Purpose
Virtual machines are susceptible to going offline or not reacting the same way a physical system would. Because of this, it may be challenging to identify if the unresponsiveness is due to the ESXi or the Guest Operating System itself. This article offers some fundamental procedures to aid in locating the problem’s root cause. Additionally, it offers links to specific problems that are known to impact the guest operating system.
Resolution
Verify that each of the troubleshooting steps listed below applies to your environment before moving on. To eliminate potential causes and take appropriate corrective action, each stage includes instructions or a link to a document. To isolate the problem and find the best solution, the procedures are arranged in the most sensible order. Never omit a step.
| Verify the virtual machine is not responding. The virtual machine can not be responding through one interface yet be working well across the network. | Perform a Ping test to the VM or connect via RDP session. For more information, see Testing network connectivity with the ping command (1003486). Connecting to VMware virtual machines using the Windows Remote Desktop utility (1018809). |
| Verify no messages are received during the boot process that identifies the cause of the virtual machine’s unresponsiveness. | Observe the boot process on the Guest OS. If during boot the operating system loading information is displayed, the virtual machine can access the hard drive and is bootable. When the guest operating system can load, the issue lies within the operating system. |
| Verify sufficient disk space for proper virtual machine operation. | One of the most common causes for a virtual machine to become unresponsive is that the hard drive has run out of space. Without sufficient space for logging and IO, the virtual machine may be unable to continue to function. For more information, see Investigating operating system disk space (1004007). |
| Check that the virtual machine has enough resources to function properly. | A virtual machine may be appearing unresponsive due to an exceedingly high load on system resources. However, since the machine is virtual, the resource monitoring tools contained within the guest operating system may not accurately reflect the resource utilization of the guest. Use the tools provided with the ESXi host and VMware vCenter Server. For more information, see the Using the esxtop utility and Using the resxtop utility section of the vSphere Monitoring and Performance Guide. |
| Verify information logged to the Microsoft Event Viewer does not report an issue that can cause an unresponsive virtual machine. | A Microsoft Guest Operating System contains a utility for viewing system-related logs. The Event Viewer contains Application, Security, and System logs. These logs record information is specific to the operation of the guest operating system. For more information, see Using Windows Event Viewer to identify the cause of an unresponsive or failed virtual machine (1007866). |
| Verify the Microsoft registry’s configuration is not causing the virtual machine to appear unresponsive. | For more information, see Advanced troubleshooting for Windows-based computer freeze issues. Disclaimer: VMware is not responsible for the reliability of any data, opinions, advice, or statements made on third-party websites. The inclusion of such links does not imply that VMware endorses, recommends, or accepts any responsibility for the content of such sites. |