@dinhngtu No, I haven't tried those. The host reboot appeared to fix the original issue and I had forgotten about them when I was troubleshooting the restart yesterday.
I'll do a bit more playing around with this in a few days and report back.
@dinhngtu No, I haven't tried those. The host reboot appeared to fix the original issue and I had forgotten about them when I was troubleshooting the restart yesterday.
I'll do a bit more playing around with this in a few days and report back.
@dinhngtu yes, same issue, same BSOD error message at the same point (very early) in the boot process. System seems to be perfectly stable once booted.
I struggle to see how it’s a hardware issue when older versions of Windows have worked just fine, as has every single Linux VM I’ve installed. Also, if it was a hardware issue I’d expect the VM to be unstable, which it does not appear to be. Seems more likely that there is something happening during the very early stages of boot that Xen is not handling gracefully/reliably.
Well sadly that's not the end of the story. After running just fine for a week or two, including multiple reboots in the early stages of installing apps etc, the most recent reboot (to install some sort of 'touchscreen driver' update) has caused a reoccurrence of this issue.
After a few tries, and leaving the VM off for a few minutes, I managed to get it to boot up again, but there is clearly some sort of issue here.
@dinhngtu well, would you believe it, but a reboot of the host seems to have solved the problem. I haven't done anything else and one of the Windows 10 test VMs that I was playing with quite merrily completed its setup process and loaded into Windows with no drama.
@dinhngtu I can confirm that it was setup as a single CPU with dual cores. I have adjusted to be one CPU with 6 cores, and that doesn't help matters.
It's worth noting that I occasionally get it to boot off the install ISO and complete the installation, but booting into the installed OS subsequently fails. It appears there is something intermittent here that's causing it to fail most of the time, but occasionally make it through.
@dinhngtu I think it’s just a simple single processor with dual cores configuration, but I’ll check when I can.
Worth noting too that that crash dump was from a VM with Viridian disabled (not an intentional choice, was just disabled from some other playing around). I’ve tried to get a crash dump with it enabled, but the system just keeps hanging at about the point I expect it to crash, so I never get a crash dump.
@dinhngtu ok, after some more mucking about, I worked out what I was doing wrong. You need to have the "break on connect" flag set in Windbg for it to show when the system has stopped, and then be able to hit the go button to continue. Once I did that, my experience matched up with your instructions.
My next failing was continuing on until I saw the BSOD on the VM, at which point the debugger was unable to analyse the crash and create the dump file. Second time around I didn't make that mistake, so I now have a successful crash dump and analysis.
Here's the output of the command window during the debugging session:
************* Preparing the environment for Debugger Extensions Gallery repositories **************
ExtensionRepository : Implicit
UseExperimentalFeatureForNugetShare : true
AllowNugetExeUpdate : true
NonInteractiveNuget : true
AllowNugetMSCredentialProviderInstall : true
AllowParallelInitializationOfLocalRepositories : true
EnableRedirectToChakraJsProvider : false
-- Configuring repositories
----> Repository : LocalInstalled, Enabled: true
----> Repository : UserExtensions, Enabled: true
>>>>>>>>>>>>> Preparing the environment for Debugger Extensions Gallery repositories completed, duration 0.000 seconds
************* Waiting for Debugger Extensions Gallery to Initialize **************
>>>>>>>>>>>>> Waiting for Debugger Extensions Gallery to Initialize completed, duration 0.016 seconds
----> Repository : UserExtensions, Enabled: true, Packages count: 0
----> Repository : LocalInstalled, Enabled: true, Packages count: 45
Microsoft (R) Windows Debugger Version 10.0.27920.1001 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Opened 192.168.205.10
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 26100 x64 target at (Sun Oct 12 16:36:29.370 2025 (UTC + 13:00)), ptr64 TRUE
Kernel Debugger connection established.
Symbol search path is: srv*
Executable search path is:
ReadVirtual() failed in GetXStateConfiguration() first read attempt (error == 0.)
Windows Boot Debugger Kernel Version 26100 UP Free x64
Primary image base = 0x00000000`016d0000 Loaded module list = 0x00000000`019499e8
System Uptime: not available
bootmgr!DebugService2+0x5:
00000000`01923755 cc int 3
kd> g
Shutdown occurred at (Sun Oct 12 16:36:49.449 2025 (UTC + 13:00))...unloading all symbol tables.
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 19041 x64 target at (Sun Oct 12 16:36:50.780 2025 (UTC + 13:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
ReadVirtual() failed in GetXStateConfiguration() first read attempt (error == 0.)
Windows Boot Debugger Kernel Version 19041 UP Free x64
Primary image base = 0x00000000`01300000 Loaded module list = 0x00000000`014afa98
System Uptime: not available
winload!DebugService2+0x5:
00000000`0146ece5 cc int 3
kd> g
Shutdown occurred at (Sun Oct 12 16:37:18.377 2025 (UTC + 13:00))...unloading all symbol tables.
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 19041 x64 target at (Sun Oct 12 16:37:19.340 2025 (UTC + 13:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows Boot Debugger Kernel Version 19041 UP Free x64
Primary image base = 0x00000000`01300000 Loaded module list = 0x00000000`014afa98
System Uptime: not available
winload!DebugService2+0x5:
00000000`0146ece5 cc int 3
kd> g
Shutdown occurred at (Sun Oct 12 16:37:43.699 2025 (UTC + 13:00))...unloading all symbol tables.
Waiting to reconnect...
Connected to Windows 10 19041 x64 target at (Sun Oct 12 16:37:44.812 2025 (UTC + 13:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (1 procs) Free x64
Edition build lab: 19041.3636.amd64fre.vb_release_svc_prod3.231019-1741
Kernel base = 0xfffff801`5a200000 PsLoadedModuleList = 0xfffff801`5ae2a930
System Uptime: 0 days 0:00:00.001
nt!DebugService2+0x5:
fffff801`5a606f85 cc int 3
kd> g
KDTARGET: Refreshing KD connection
*** Fatal System Error: 0x0000007e
(0xFFFFFFFFC0000094,0xFFFFF8015A69706C,0xFFFF9E03AF6897C8,0xFFFF9E03AF689000)
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
For analysis of this file, run !analyze -v
nt!DbgBreakPointWithStatus:
fffff801`5a606f30 cc int 3
0: kd> !analyze -v
Connected to Windows 10 19041 x64 target at (Sun Oct 12 16:50:59.853 2025 (UTC + 13:00)), ptr64 TRUE
Loading Kernel Symbols
....
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
...........................................................
................................................................
..........
Loading User Symbols
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common BugCheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000094, The exception code that was not handled
Arg2: fffff8015a69706c, The address that the exception occurred at
Arg3: ffff9e03af6897c8, Exception Record Address
Arg4: ffff9e03af689000, Context Record Address
Debugging Details:
------------------
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
KEY_VALUES_STRING: 1
Key : Analysis.CPU.mSec
Value: 4625
Key : Analysis.Elapsed.mSec
Value: 273277
Key : Analysis.IO.Other.Mb
Value: 25
Key : Analysis.IO.Read.Mb
Value: 1
Key : Analysis.IO.Write.Mb
Value: 19
Key : Analysis.Init.CPU.mSec
Value: 8406
Key : Analysis.Init.Elapsed.mSec
Value: 1067795
Key : Analysis.Memory.CommitPeak.Mb
Value: 93
Key : Analysis.Version.DbgEng
Value: 10.0.27920.1001
Key : Analysis.Version.Description
Value: 10.2506.23.01 amd64fre
Key : Analysis.Version.Ext
Value: 1.2506.23.1
Key : Bugcheck.Code.KiBugCheckData
Value: 0x7e
Key : Bugcheck.Code.LegacyAPI
Value: 0x7e
Key : Bugcheck.Code.TargetModel
Value: 0x7e
Key : Failure.Bucket
Value: 0x7E_C0000094_nt!MiComputeRunTimeZeroComparisons
Key : Failure.Exception.Code
Value: 0xc0000094
Key : Failure.Exception.IP.Address
Value: 0xfffff8015a69706c
Key : Failure.Exception.IP.Module
Value: nt
Key : Failure.Exception.IP.Offset
Value: 0x49706c
Key : Failure.Exception.Record
Value: 0xffff9e03af6897c8
Key : Failure.Hash
Value: {08aa3e5b-968e-659a-d0a6-6a71f6ff3635}
Key : Hypervisor.Enlightenments.Value
Value: 0
Key : Hypervisor.Enlightenments.ValueHex
Value: 0x0
Key : Hypervisor.Flags.AnyHypervisorPresent
Value: 1
Key : Hypervisor.Flags.ApicEnlightened
Value: 0
Key : Hypervisor.Flags.ApicVirtualizationAvailable
Value: 0
Key : Hypervisor.Flags.AsyncMemoryHint
Value: 0
Key : Hypervisor.Flags.CoreSchedulerRequested
Value: 0
Key : Hypervisor.Flags.CpuManager
Value: 0
Key : Hypervisor.Flags.DeprecateAutoEoi
Value: 0
Key : Hypervisor.Flags.DynamicCpuDisabled
Value: 0
Key : Hypervisor.Flags.Epf
Value: 0
Key : Hypervisor.Flags.ExtendedProcessorMasks
Value: 0
Key : Hypervisor.Flags.HardwareMbecAvailable
Value: 0
Key : Hypervisor.Flags.MaxBankNumber
Value: 0
Key : Hypervisor.Flags.MemoryZeroingControl
Value: 0
Key : Hypervisor.Flags.NoExtendedRangeFlush
Value: 0
Key : Hypervisor.Flags.NoNonArchCoreSharing
Value: 0
Key : Hypervisor.Flags.Phase0InitDone
Value: 0
Key : Hypervisor.Flags.PowerSchedulerQos
Value: 0
Key : Hypervisor.Flags.RootScheduler
Value: 0
Key : Hypervisor.Flags.SynicAvailable
Value: 0
Key : Hypervisor.Flags.UseQpcBias
Value: 0
Key : Hypervisor.Flags.Value
Value: 4096
Key : Hypervisor.Flags.ValueHex
Value: 0x1000
Key : Hypervisor.Flags.VpAssistPage
Value: 0
Key : Hypervisor.Flags.VsmAvailable
Value: 0
Key : Hypervisor.RootFlags.AccessStats
Value: 0
Key : Hypervisor.RootFlags.CrashdumpEnlightened
Value: 0
Key : Hypervisor.RootFlags.CreateVirtualProcessor
Value: 0
Key : Hypervisor.RootFlags.DisableHyperthreading
Value: 0
Key : Hypervisor.RootFlags.HostTimelineSync
Value: 0
Key : Hypervisor.RootFlags.HypervisorDebuggingEnabled
Value: 0
Key : Hypervisor.RootFlags.IsHyperV
Value: 0
Key : Hypervisor.RootFlags.LivedumpEnlightened
Value: 0
Key : Hypervisor.RootFlags.MapDeviceInterrupt
Value: 0
Key : Hypervisor.RootFlags.MceEnlightened
Value: 0
Key : Hypervisor.RootFlags.Nested
Value: 0
Key : Hypervisor.RootFlags.StartLogicalProcessor
Value: 0
Key : Hypervisor.RootFlags.Value
Value: 0
Key : Hypervisor.RootFlags.ValueHex
Value: 0x0
Key : SecureKernel.HalpHvciEnabled
Value: 0
Key : WER.OS.Branch
Value: vb_release_svc_prod3
Key : WER.OS.Version
Value: 10.0.19041.3636
BUGCHECK_CODE: 7e
BUGCHECK_P1: ffffffffc0000094
BUGCHECK_P2: fffff8015a69706c
BUGCHECK_P3: ffff9e03af6897c8
BUGCHECK_P4: ffff9e03af689000
FAULTING_THREAD: ffff8a03761f1300
EXCEPTION_RECORD: ffff9e03af6897c8 -- (.exr 0xffff9e03af6897c8)
ExceptionAddress: fffff8015a69706c (nt!MiComputeRunTimeZeroComparisons+0x00000000000ec1f4)
ExceptionCode: c0000094 (Integer divide-by-zero)
ExceptionFlags: 00000000
NumberParameters: 0
CONTEXT: ffff9e03af689000 -- (.cxr 0xffff9e03af689000)
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000002
rdx=0000000000000000 rsi=0000000000000000 rdi=fffff60000008108
rip=fffff8015a69706c rsp=ffff9e03af689a00 rbp=0000000000000000
r8=ffff8a03760e1078 r9=0000000000000000 r10=ffff8a03760e1070
r11=0000000000000000 r12=0000000000000000 r13=fffff8015ae50d80
r14=ffff8a03760e1070 r15=ffff8a0376051060
iopl=0 nv up ei pl nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010206
nt!MiComputeRunTimeZeroComparisons+0xec1f4:
fffff801`5a69706c 49f7f1 div rax,r9
Resetting default scope
PROCESS_NAME: System
ERROR_CODE: (NTSTATUS) 0xc0000094 - {EXCEPTION} Integer division by zero.
EXCEPTION_CODE_STR: c0000094
EXCEPTION_STR: 0xc0000094
STACK_TEXT:
ffff9e03`af689a00 fffff801`5a5aae03 : 00000000`00000000 ffff8a03`76096980 fffff600`00007000 fffff801`5ae50d80 : nt!MiComputeRunTimeZeroComparisons+0xec1f4
ffff9e03`af689a40 fffff801`5a5ab2ad : 00000000`00000000 00000000`00000002 00000000`00000000 00000000`00000000 : nt!MiZeroPageCalibrate+0x1bf
ffff9e03`af689b00 fffff801`5a55d6e5 : ffff8a03`00000001 fffff801`00000001 ffffffff`80000050 ffff8a03`760b7410 : nt!MiZeroNodePages+0x26d
ffff9e03`af689c10 fffff801`5a606578 : fffff801`5802b180 ffff8a03`761f1300 fffff801`5a55d690 00000000`00000000 : nt!PspSystemThreadStartup+0x55
ffff9e03`af689c60 00000000`00000000 : ffff9e03`af68a000 ffff9e03`af684000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x28
SYMBOL_NAME: nt!MiComputeRunTimeZeroComparisons+ec1f4
MODULE_NAME: nt
IMAGE_VERSION: 10.0.19041.6328
STACK_COMMAND: .cxr 0xffff9e03af689000 ; kb
IMAGE_NAME: ntkrnlmp.exe
BUCKET_ID_FUNC_OFFSET: ec1f4
FAILURE_BUCKET_ID: 0x7E_C0000094_nt!MiComputeRunTimeZeroComparisons
OS_VERSION: 10.0.19041.3636
BUILDLAB_STR: vb_release_svc_prod3
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
FAILURE_ID_HASH: {08aa3e5b-968e-659a-d0a6-6a71f6ff3635}
Followup: MachineOwner
---------
0: kd> .dump /o C:\Win10BootCrask.dmp
******************************************************************************
INFORMATIONAL: Dump file will not contain user mode memory or user mode module list
Press Ctrl-C or Ctrl-Break if you want to terminate the command.
******************************************************************************
Unable to create file 'C:\Win10BootCrask.dmp' - Win32 error 0n5
"Access is denied."
0: kd> .dump /o C:\Users\Michael Williams\Desktop\Win10B00tCrash.dmp
******************************************************************************
INFORMATIONAL: Dump file will not contain user mode memory or user mode module list
Press Ctrl-C or Ctrl-Break if you want to terminate the command.
******************************************************************************
Creating C:\Users\Michael Williams\Desktop\Win10B00tCrash.dmp - mini kernel dump
Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.
KdDebuggerData.MmMaximumNonPagedPoolInBytes is NULL
KdDebuggerData.MmAllocatedNonPagedPool is NULL
KdDebuggerData.MmTotalCommittedPages is NULL
KdDebuggerData.MmPeakCommitment is NULL
KdDebuggerData.MmTotalCommitLimitMaximum is NULL
Dump successfully written
Here's a link to download the crash dump: https://drive.google.com/file/d/1MHnhivvGKYilsG2_FI5S-_VXHWZe_8AY/view?usp=sharing
Hopefully I've managed to collect everything you need.
@dinhngtu thanks for that info and for the PM.
I managed to successfully update the bcd, however after rebuilding the ISO, I cannot get the VM to boot from it, I just end up in the EFI shell. I was following these instructions: https://www.wintips.org/how-to-edit-iso-file-modify-windows-iso-bootable-image/ The only deviation I had to make was to manually set the file system to UDF, since the prompt shown in the instructions did not come up.
I used the WinPE ISO that you provided, which did boot, however I didn't have a lot of joy getting any much information out of it. I managed to get WinDbg to connect and show the status, however the VM ultimately just hung on the following screen:

Note that either WinDbg was either showing that the Debugee was busy/running or disconnected. It wasn't waiting for me to click go at any point.
This is what was shown in the WinDbg command window:
************* Preparing the environment for Debugger Extensions Gallery repositories **************
ExtensionRepository : Implicit
UseExperimentalFeatureForNugetShare : true
AllowNugetExeUpdate : true
NonInteractiveNuget : true
AllowNugetMSCredentialProviderInstall : true
AllowParallelInitializationOfLocalRepositories : true
EnableRedirectToChakraJsProvider : false
-- Configuring repositories
----> Repository : LocalInstalled, Enabled: true
----> Repository : UserExtensions, Enabled: true
>>>>>>>>>>>>> Preparing the environment for Debugger Extensions Gallery repositories completed, duration 0.000 seconds
************* Waiting for Debugger Extensions Gallery to Initialize **************
>>>>>>>>>>>>> Waiting for Debugger Extensions Gallery to Initialize completed, duration 0.062 seconds
----> Repository : UserExtensions, Enabled: true, Packages count: 0
----> Repository : LocalInstalled, Enabled: true, Packages count: 45
Microsoft (R) Windows Debugger Version 10.0.27920.1001 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Opened 192.168.205.10
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 26100 x64 target at (Sun Oct 12 12:39:23.766 2025 (UTC + 13:00)), ptr64 TRUE
Kernel Debugger connection established.
Symbol search path is: srv*
Executable search path is:
ReadVirtual() failed in GetXStateConfiguration() first read attempt (error == 0.)
Windows Boot Debugger Kernel Version 26100 UP Free x64
Primary image base = 0x00000000`016d0000 Loaded module list = 0x00000000`019499e8
System Uptime: not available
Shutdown occurred at (Sun Oct 12 12:41:48.383 2025 (UTC + 13:00))...unloading all symbol tables.
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 19041 x64 target at (Sun Oct 12 12:41:49.330 2025 (UTC + 13:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
ReadVirtual() failed in GetXStateConfiguration() first read attempt (error == 0.)
Windows Boot Debugger Kernel Version 19041 UP Free x64
Primary image base = 0x00000000`01300000 Loaded module list = 0x00000000`014afa98
System Uptime: not available
Shutdown occurred at (Sun Oct 12 12:42:15.478 2025 (UTC + 13:00))...unloading all symbol tables.
Waiting to reconnect...
BD: Boot Debugger Initialized
Connected to Windows Boot Debugger 19041 x64 target at (Sun Oct 12 12:42:16.760 2025 (UTC + 13:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows Boot Debugger Kernel Version 19041 UP Free x64
Primary image base = 0x00000000`01300000 Loaded module list = 0x00000000`014afa98
System Uptime: not available
Shutdown occurred at (Sun Oct 12 12:42:22.714 2025 (UTC + 13:00))...unloading all symbol tables.
Waiting to reconnect...
Connected to Windows 10 19041 x64 target at (Sun Oct 12 12:42:24.039 2025 (UTC + 13:00)), ptr64 TRUE
Kernel Debugger connection established.
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
Symbol search path is: srv*
Executable search path is:
Windows 10 Kernel Version 19041 MP (1 procs) Free x64
Edition build lab: 19041.3636.amd64fre.vb_release_svc_prod3.231019-1741
Kernel base = 0xfffff803`51e00000 PsLoadedModuleList = 0xfffff803`52a2a930
System Uptime: not available
... Retry sending the same data packet for 64 times.
The transport connection between host kernel debugger and target Windows seems lost.
please try resync with target, recycle the host debugger, or reboot the target Windows.
... Retry sending the same data packet for 128 times.
... Retry sending the same data packet for 192 times.
@dinhngtu I've just been trying to make those edits to the bcd file, however, I'm not having any luck. Below is a section of things I have tried with no success (using the latest Windows 10 22H2):
Microsoft Windows [Version 10.0.19045.6332]
(c) Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>bcdedit /store "C:\Windows 10 22H2\boot\BCD" /set debug on
An error occurred while attempting to reference the specified entry.
The system cannot find the file specified.
C:\WINDOWS\system32>bcdedit /store "C:\Windows 10 22H2\boot\BCD" /debug on
An error occurred while attempting to access the specified entry.
The system cannot find the file specified.
@TeddyAstie apologies for the tardy reply.
This is the tail end of note from xl dmesg:
(XEN) [1029242.324130] d17v1 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff80272497e14 0xffff9f8d4689e7c8 0xffff9f8d4689e000
(XEN) [1029490.963515] d18v1 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff80251497e14 0xffffac025109e7c8 0xffffac025109e000
(XEN) [1029557.664243] d19v1 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff8073c497e14 0xfffff4895049e7c8 0xfffff4895049e000
(XEN) [1029654.360658] d20v1 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff80030497e14 0xffff848fdee9e7c8 0xffff848fdee9e000
(XEN) [1029786.928461] d21v0 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff80639697e14 0xfffff50ea42897c8 0xfffff50ea4289000
(XEN) [1030181.784003] d23v0 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff80749297e14 0xfffffb0fe66897c8 0xfffffb0fe6689000
(XEN) [1030346.926513] d24v0 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff80337c97e14 0xffff8304baa897c8 0xffff8304baa89000
(XEN) [1030399.047734] d25v0 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff80542c97e14 0xfffff204226897c8 0xfffff20422689000
(XEN) [1529444.878620] d13v1 VIRIDIAN GUEST_CRASH: 0x7a 0x117a30 0xc00000c0 0x2c9f6be0 0x22f46000
(XEN) [1529695.616425] d30v1 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff80355497e14 0xffff8387fbcb37c8 0xffff8387fbcb3000
(XEN) [1546475.266724] d49v0 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff80649896f0a 0xffffba8689a897c8 0xffffba8689a89000
(XEN) [2060275.879001] d54v0 VIRIDIAN GUEST_CRASH: 0x7e 0xffffffffc0000094 0xfffff8027a497e14 0xfffff302fea897c8 0xfffff302fea89000
The last line appears to be from my most recent test with a fresh VM (just to check those messages were related).
@dinhngtu Thanks. I'll try and give that a go in the next few days and will report back.
Note that I have Windows 10 1803 installed without any issues. Trying to update to 22H2 fails with the same blue screen error as you'd expect. Sadly, no crash dump as it seems to fail very early in the boot process.
@dinhngtu sorry, I don't know how to do that offhand. If you point me in the direction of some instructions, I'm happy to give it a go.
@dinhngtu given it’s trying to boot from the installer, where would it save the crash dump to?
@olivierlambert it is a “ Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz”
@acebmxer it is UEFI, and I’ve tried with and without secure boot enabled.
@dinhngtu the host is a Dell Precision T3610 workstation with Intel Xeon processor and 120GB RAM. I used the default Windows 10 (64bit) template. The ISO was built with the Microsoft Windows 10 media creator about a month ago and it successfully installed a VirtualBox VM. The ISO is located on a NFS SR.
@dinhngtu can you please explain what you mean and exactly what information you’re asking for?
Hi,
I've just created a new VM to install the latest version of Windows 10 in. I selected the Windows 10 template and pointed it at the ISO, but whenever I tried to boot it, I get a BSOD with the error "SYSTEM THREAD EXCEPTION NOT HANDLED".
Other VMs on this server are working fine.

@XCP-ng-JustGreat thanks for the info. I have tried following your instructions for a test Windows 10 VM I have and unfortunately it has not helped the issue at all. I will note however that I haven't had a chance to update XCP-ng for a few months now, so I won't be running the latest version.
One 'issue' I have with your theory is that, in my case at least, it's the USB controller that's bombing, which is causing the mouse to stop working. I expect if USB pass-through was being used, this would also stop working for the same reason.
@DevilDan this isn't related to the mouse problem, so you are far better to create a new forum post for help with your issue.