[EN] Windows 10 (1809) VDI Virtual Machines Appear Unresponsive but Respond to Ping

VDI virtual machines running Windows 10 build 1809 can stop serving user sessions while still appearing “alive” at the network layer. The VM answers ping and ARP, and RDP even accepts credentials but the session never opens. In Horizon environments, the same machines often drop into an “Agent Unreachable” state.

The root cause is not a network, storage, or resource bottleneck. It is the hpet0.present = FALSE parameter in the virtual machine’s .vmx configuration file. This value deviates from the supported default (TRUE) and is incompatible with the timer behaviour introduced in Windows 10 1809.

An affected virtual machine typically shows the following pattern:

Observation	Status
ICMP (ping) response	✅ Succeeds
ARP resolution	✅ Succeeds
RDP authentication	✅ Credentials accepted
RDP session establishment	❌ Connection never completes
VM console access	❌ Frozen / unresponsive screen
Horizon Agent status	❌ “Agent Unreachable”
Application and service response	❌ None, or severely delayed

This combination is highly diagnostic. The lower layers of the network stack ICMP and ARP, which are handled in kernel context keep working, while session management and the application layer have effectively stalled.

Scope of the issue

Reported only on Windows 10 build 1809.
Not observed on Windows 10 1803 or earlier builds.
Affected machines are typically configured with 2 vCPUs.

Root Cause : What is HPET?

The High Precision Event Timer (HPET) is a hardware timer on x86 platforms that provides high-resolution timekeeping. The operating system selects one of the available timer sources for timer interrupts, thread scheduling, synchronization primitives, and time measurement. HPET sits alongside alternatives such as the TSC (Time Stamp Counter) and the ACPI PM Timer.

In virtualized environments, HPET is exposed to or hidden from the guest through the hpet0.present parameter in the .vmx file. The supported default on the VMware side is TRUE.

Why the problem appears

On Horizon VDI virtual machines, HPET has historically been disabled for performance reasons (hpet0.present = FALSE). That configuration worked without incident on Windows 10 1803 and earlier.

Windows 10 1809, however, changed how the kernel selects and synchronizes against timer sources. When the 1809 kernel runs on a virtual hardware profile without HPET and cannot find the timer resource it expects, timing-based synchronization operations can stall. As a result:

Timer-dependent kernel objects (timers, DPC queues) stop making progress.
User-mode services and the logon chain (LSASS / Winlogon / TermService) block.
ICMP and ARP replies, handled at the network driver level, remain unaffected.

That is the technical explanation for the apparent contradiction: ping replies arrive, but no session ever opens.

Verification: Is This VM Affected?

Before applying the fix, confirm that the parameter is actually set to FALSE.

Using the vSphere Client

Right-click the virtual machine → Edit Settings
Go to the VM Options tab
Expand Advanced → Configuration Parameters → Edit Configuration
Locate the hpet0.present row and check its value

Bulk scan with PowerCLI

To audit every virtual machine in the environment at once:

Get-VM | ForEach-Object {
    $hpet = ($_ | Get-AdvancedSetting -Name "hpet0.present").Value
    [PSCustomObject]@{
        VM         = $_.Name
        PowerState = $_.PowerState
        OS         = $_.Guest.OSFullName
        HPET       = if ($null -eq $hpet) { "Undefined (default)" } else { $hpet }
    }
} | Where-Object { $_.HPET -eq $false } | Format-Table -AutoSize

This lists every VM whose hpet0.present value is FALSE.

From the ESXi shell

grep -i "hpet0.present" /vmfs/volumes/<datastore>/<vm-name>/<vm-name>.vmx

Resolution

Setting hpet0.present to TRUE resolves the issue.

Important: This change can only be made while the virtual machine is powered off. Editing the parameter on a running VM has no effect.

Method 1 : VMware vSphere Client (GUI)

Ensure the virtual machine has been shut down cleanly and is Powered Off.
Right-click the virtual machine.
Click Edit Settings… to open the Virtual Machine Properties window.
Go to the VM Options tab. (In older vSphere Client versions: the Options tab.)
From the list on the left, select Advanced > General.
In the Configuration Parameters frame on the right, click Configuration Parameters… / Edit Configuration….
Locate hpet0.present and change the value from FALSE to TRUE.
Click OK.
Power on the virtual machine for the setting to take effect.

Method 2 : VMware PowerCLI (single VM)

$vm = Get-VM -Name "VDI-Win10-01"

# Make sure the VM is powered off
if ($vm.PowerState -ne "PoweredOff") {
    Stop-VM -VM $vm -Confirm:$false
    Start-Sleep -Seconds 30
}

# Update the parameter
Get-AdvancedSetting -Entity $vm -Name "hpet0.present" |
    Set-AdvancedSetting -Value $true -Confirm:$false

# Power the VM back on
Start-VM -VM $vm

Method 3 : VMware PowerCLI (bulk remediation)

For environments where many VDI machines are affected:

$targetVMs = Get-VM | Where-Object {
    ($_ | Get-AdvancedSetting -Name "hpet0.present").Value -eq $false
}

foreach ($vm in $targetVMs) {
    Write-Host "Processing: $($vm.Name)" -ForegroundColor Cyan

    if ($vm.PowerState -eq "PoweredOn") {
        Shutdown-VMGuest -VM $vm -Confirm:$false -ErrorAction SilentlyContinue
        # A hard power-off may be required if the guest OS is unresponsive
        $counter = 0
        while ((Get-VM $vm.Name).PowerState -eq "PoweredOn" -and $counter -lt 12) {
            Start-Sleep -Seconds 10
            $counter++
        }
        if ((Get-VM $vm.Name).PowerState -eq "PoweredOn") {
            Stop-VM -VM $vm -Confirm:$false
        }
    }

    Get-AdvancedSetting -Entity $vm -Name "hpet0.present" |
        Set-AdvancedSetting -Value $true -Confirm:$false

    Start-VM -VM $vm
    Write-Host "Completed: $($vm.Name)" -ForegroundColor Green
}

Note: Run bulk remediation inside a maintenance window and in waves (for example, batches of 20–30 machines).

Restarting large numbers of VMs simultaneously can create a boot storm on the storage subsystem.

Permanent Fix in Horizon Environments

In Horizon environments using Instant Clones or Linked Clones, fixing the existing machines is not enough the same parameter is redeployed whenever the pool is recreated.

For a permanent fix:

Set hpet0.present = TRUE on the golden image / parent VM.
Take a new snapshot.
Run a Push Image / Recompose operation on the desktop pool using the new snapshot.
Verify that all machines in the pool have been recreated from the new image.
Confirm that no hpet0.present = FALSE line remains in your automation templates or deployment scripts.

Post-Remediation Checklist

[ ] hpet0.present now reads TRUE
[ ] The VM has been restarted (mandatory after the parameter change)
[ ] Console login works
[ ] RDP progresses past authentication and opens a session
[ ] Horizon Administrator reports the agent as Available
[ ] Golden images and deployment templates have been updated
[ ] Newly provisioned machines inherit the correct value

Frequently Asked Questions

Can I change the parameter while the VM is running? No. hpet0.present belongs to the virtual hardware layer and is read only during VM power-on. The machine must be fully powered off and started again. A guest-initiated restart alone is not sufficient.

Does enabling HPET hurt performance? HPET is theoretically a more expensive timer source than the TSC, which is why it was disabled on VDI machines in the past. On modern ESXi releases and current Windows kernels, however, the guest generally continues to prefer the TSC; HPET is simply made available as a resource. No measurable performance loss should be expected, while the stability gain is significant. TRUE is the supported configuration on the VMware side.

What if the parameter is not present in the .vmx file at all? An undefined parameter means the default behaviour (TRUE) applies, so no action is required. If you prefer to set it explicitly, use New-AdvancedSetting -Name "hpet0.present" -Value $true in PowerCLI.

Will updating Windows 10 1809 fix the problem? Upgrading to build 1903 or later may reduce how often the issue appears, but the actual fix is returning to the supported configuration. This is less a Windows defect than an incompatibility triggered by an unsupported virtual hardware configuration.

Could something else produce the same symptoms? Yes. A VM that answers ping but never opens a session can also be suffering from storage latency, resource starvation (high CPU ready, memory ballooning), a full disk, or a failed guest service. Checking hpet0.present is simply the fastest way to confirm or rule out this particular cause.

Prevention

Audit VM templates and deployment automation regularly to make sure no unsupported .vmx parameters are present.
Schedule the PowerCLI scan above as a recurring health check.
Validate that the virtual hardware configuration is supported for the target OS build before performing in-place upgrades.
Define a baseline configuration so that configuration drift can be detected.