Knowledge Base

The VMware Knowledge Base provides support solutions, error messages and troubleshooting guides

Search the VMware Knowledge Base (KB)

View by Article ID

ESX/ESXi hosts fail with a purple diagnostic screen and report the error: #PF Exception(14) (2012404)

Symptoms

The ESX/ESXi host fails with a purple diagnostic screen
You see a backtrace similar to:

@BlueScreen: #PF Exception(14) in world 1056477182:sh ip 0x41803645e7fc addr 0x417ff5d1e50c
LBR: from 0x41803645e825 to 0x41803645e7e1
Code starts at 0x418036400000
0x4100c7ff7d08:[0x41803645e7fc]WorldNewInt+0xa3 stack: 0x4100a30e4bf0
0x4100c7ff7d38:[0x41803645ec6f]World_New+0xbe stack: 0xbad0014
0x4100c7ff7d98:[0x41803645ee0e]WorldNewDefaultWorld+0x179 stack: 0x4100c7ff7e08
0x4100c7ff7de8:[0x41803657ae50]UserCartel_NewChildWorld+0x9b stack: 0x4100c7ff7e48
0x4100c7ff7e38:[0x41803657af5d]UserCartel_Fork+0xc8 stack: 0x4100c7ff7e78
0x4100c7ff7ef8:[0x41803656369d]LinuxThread_Clone+0x134 stack: 0xec7ff7f28
0x4100c7ff7f28:[0x41803653d90c]User_LinuxSyscallHandler+0xa3 stack: 0x0

Cause

When new worlds are created, an integer is incremented. When this integer overflows, the kernel panics and fails with a purple diagnostic screen. In ESXi, new worlds are created for all processes because there is no service console operating system. Therefore, this number increments much faster in ESXi than ESX. In ESXi, this issue occurs when the system has been running for a very long time (over a year) without a reboot and has been actively creating processes. In ESX classic, it is almost impossible to hit this threshold.

Resolution

This issue is resolved in the following ESX/ESXi releases:

VMware ESX 4.0, Patch Release ESX400-201203001. For more detail, see VMware ESX 4.0, Patch Release ESX400-201203001 (2011767)
VMware ESX/ESX 4.1 Update 3. You can download this update from the VMware Download Center.
VMware ESXi 5.0 Update 1. You can download this update from the VMware Download Center.

Note: This issue does not affect ESXi 5.1

If you are unable to upgrade to the appropriate release, to workaround this issue on earlier release of ESX/ESXi, reboot the host. Rebooting the host restarts the counter and eliminates the risk of any failure.

To avoid a reboot, you can check to determine if your system is at risk.

To determine if your system is at risk, run this script in the ESXi command line:

highWID=$(vsish -e ls world | sed 's!/$!!' | sort -n | tail -n 1)
let microFull=highWID/7400
echo ${microFull}

If this script returns a value close to 100,000 it is recommended to schedule a reboot.

Additional Information

To be alerted when this article is updated, click Subscribe to Document in the Actions box.

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

Feedback

1 2 3 4 5
4 Ratings

1 2 3 4 5
4 Ratings

Actions

Bookmark Document

KB:

Did this article help you?
This article resolved my issue. This article did not resolve my issue. This article helped but additional information was required to resolve my issue.
What can we do to improve this information? (4000 or fewer characters)