Knowledge Base

|
Virtual Machine Panics with Bug Number 10095 or 1319
Details
My virtual machine shut down unexpectedly and reported bug number 10095 (bugNr=10095) or 1319 (bugNr=1319). What can I do?
Solution
The conditions under which this problem can occur and possible workarounds for the problem are described in the following sections:
- Running the Virtual Machine on a 64-Bit AMD Host
- Running the Virtual Machine on a Host with Different Speed Processors
- Unwanted Resynchronization of Timestamp Counters
- Running the Virtual Machine on a Windows Host That Has a Defective ACPI Timer
If this problem occurs on your host under conditions not described in these sections, please request support from VMware at www.vmware.com/requestsupport.
Running the Virtual Machine on a 64-Bit AMD Host
This problem can occur as a result of unsynchronized timestamp counters (TSCs) on 64-bit AMD multiprocessor hosts. See Virtual Machine Clock Reports Time Unpredictably on 64-Bit AMD Systems (kb.vmware.com/kb/2041).
Running the Virtual Machine on a Host with Different Speed Processors
If you are running the virtual machine on a multiprocessor host, first verify that the processors have the same CPU speeds. Intel does not support multiprocessor systems when the processors run at different speeds. Thus, VMware cannot support multiprocessor systems unless the CPUs have the same speeds. For more information about Intel multiprocessors, see support.intel.com/support/processors/dp1.htm.
Unwanted Resynchronization of Timestamp Counters
If the host processors all have the same CPU speed and if you are running a Windows host operating system, you may have encountered a problem with synchronization of timestamp counters (TSCs). Some versions of the Windows hardware abstraction layer (HAL) use the TSC register on each processor chip to implement certain timekeeping functions. Some VMware products have an internal feature that attempts to detect when the TSCs of different CPUs are out of synchronization and resynchronize them. This feature can sometimes activate when it should not, causing a virtual machine to report bug number 10095 or 1319.
To work around this problem, add the following line to your global configuration file:host.TSC.noForceSync = TRUE
The global configuration file is normally found at:
- C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\config.ini for VMware Workstation
- C:\Documents and Settings\All Users\Application Data\VMware\VMware GSX Server\config.ini for GSX Server
Running the Virtual Machine on a Windows Host That Has a Defective ACPI Timer
Some versions of the Windows HAL use the ACPI timer on your computer's motherboard to implement certain timekeeping functions. On a few machines, this timer is defective, which can cause bug 10095 or 1319 to occur in VMware products.
If your machine has the defect, you can work around it by replacing your Windows HAL with one that does not use the ACPI feature. If you have a single-processor machine with the defect, VMware recommends you change the HAL to the MPS Uniprocessor PC HAL or the Standard PC HAL. If you have a multiprocessor machine with the defect, VMware recommends you change to the MPS Multiprocessor PC HAL.
To change the HAL, you should upgrade your host operating
system. For information on how to do this for the Windows 2000
host, see Microsoft knowledge base article 237556. Go to
support.microsoft.com/default.aspx?scid=kb;EN-US;237556.
Running the Virtual Machine on an IBM x440/x445 Server or a Derivative System
On an IBM x440 or x445 server (or a derivative system from Fujitsu Siemens or NEC, for example), running a Windows host operating system with a generic HAL provided by Microsoft can cause this bug to occur, as can running with old versions of the IBM HAL. See Running the Virtual Machine on an IBM x440/x445 Server or a Derivative System with a Windows Host Operating System (kb.vmware.com/kb/2040).
Keywords
Request a Product Feature
- KB Article:
- Updated:
- Categories:
- Product Family:
- Products:
- Product Versions:

