Background / VM history:
The affected VM has a complex migration history:
Environment:
Problem:
Following a crash, we attempted to restore the VM from both PBS and Veeam backups. All restore attempts (multiple PBS snapshots from different dates, plus Veeam backup) result in the same behavior:
Diagnostic steps performed:
We analyzed the memory dump with WinDbg. The crash analysis shows:
CRITICAL_PROCESS_DIED
CriticalProcessDied.Process: wininit.exe
FAILURE_BUCKET_ID: 0xEF_wininit.exe_BUGCHECK_CRITICAL_PROCESS_489dd740_ntdll!NtTerminateProcess
wininit.exe is calling NtTerminateProcess on itself — it's not a driver crash, it's an intentional exit. The boot log (ntbtlog.txt) only shows 5 entries before the crash:
ntoskrnl.exe
hal.dll
mcupdate_GenuineIntel.dll
werkernel.sys
The crash occurs before any third-party drivers are loaded.
Attempted fixes (all unsuccessful):
Key observation:
The dump shows Hyper-V enlightenments are active (SynicAvailable=1, ApicEnlightened=1), which is inherited from the VMware/Hyper-V migration history. However disabling these did not resolve the issue.
The fact that the crash occurs after only 5 kernel files load, even in Safe Mode, suggests corruption at the HAL or kernel level rather than a driver issue.
Question:
Has anyone experienced this specific scenario with a VM that went through a physical → VMware → Proxmox migration chain? Is there a known fix for wininit.exe terminating this early in the boot process, or is a clean reinstall with AD restore (from ntds.dit) the only viable path?
Any help appreciated.
The affected VM has a complex migration history:
- Originally a physical Windows Server 2016 server (HP ML350 Gen10, Xeon Silver) virtualized using VMware Converter onto a Dell PowerEdge with E5-2660 V4 CPUs
- Subsequently migrated to Proxmox VE using the built-in Proxmox migration tool (import from ESXi)
- Running on a 3-node Proxmox cluster with shared iSCSI storage (LVM over iSCSI on a NAS)
Environment:
- Proxmox VE: 8.4.17
- PBS: 4.1.6
- Veeam Backup & Replication: v13
- VM role: Windows Server 2016 Domain Controller + File Server
- VM disk: ~559 GB LVM volume on iSCSI NAS
- Backup targets: PBS (local ZFS datastore) + Veeam (SMB NAS target)
Problem:
Following a crash, we attempted to restore the VM from both PBS and Veeam backups. All restore attempts (multiple PBS snapshots from different dates, plus Veeam backup) result in the same behavior:
- VM boots, CHKDSK runs automatically and fixes some filesystem errors
- On reboot after CHKDSK, Windows crashes with CRITICAL_PROCESS_DIED BSOD
- System uptime at crash: approximately 4 seconds
Diagnostic steps performed:
We analyzed the memory dump with WinDbg. The crash analysis shows:
CRITICAL_PROCESS_DIED
CriticalProcessDied.Process: wininit.exe
FAILURE_BUCKET_ID: 0xEF_wininit.exe_BUGCHECK_CRITICAL_PROCESS_489dd740_ntdll!NtTerminateProcess
wininit.exe is calling NtTerminateProcess on itself — it's not a driver crash, it's an intentional exit. The boot log (ntbtlog.txt) only shows 5 entries before the crash:
ntoskrnl.exe
hal.dll
mcupdate_GenuineIntel.dll
werkernel.sys
The crash occurs before any third-party drivers are loaded.
Attempted fixes (all unsuccessful):
- Disabled all VMware/ESXi residual services and drivers via offline registry editing (vmxnet3ndis6, vmbus, vmci, vm3dmp, vmmouse, VMMemCtl, VMSP, VMSVSP, etc.)
- Changed disk controller from VirtIO SCSI to SATA — resulted in INACCESSIBLE_BOOT_DEVICE instead
- Enabled Safe Mode boot via bcdedit — same CRITICAL_PROCESS_DIED in Safe Mode
- Changed CPU type from host to kvm64 — no change
- Attempted to disable Hyper-V enlightenments via -cpu args — no change
- Disabled mcupdate_GenuineIntel service via offline registry — no change
- Attempted DISM /RestoreHealth from Windows Server 2016 ISO — failed (version mismatch, error 0x800f081f)
- Attempted SFC /scannow offline — found corrupted files but could not repair them
Key observation:
The dump shows Hyper-V enlightenments are active (SynicAvailable=1, ApicEnlightened=1), which is inherited from the VMware/Hyper-V migration history. However disabling these did not resolve the issue.
The fact that the crash occurs after only 5 kernel files load, even in Safe Mode, suggests corruption at the HAL or kernel level rather than a driver issue.
Question:
Has anyone experienced this specific scenario with a VM that went through a physical → VMware → Proxmox migration chain? Is there a known fix for wininit.exe terminating this early in the boot process, or is a clean reinstall with AD restore (from ntds.dit) the only viable path?
Any help appreciated.
Last edited: