@john-c There's no memory.dmp file there, as far as I can see with ls or ls -a. There's no way for me to look at it in Windows, or change the hidden file options.

I suppose it's probable that the system crashes before a dump can happen. But I'm not sure what I can do about that.

@john-c No. It's a basic no-frills standalone machine.

@john-c It's not something I set explicitly. The Windows 10 Pro install was a clean install from ISO, I did not change settings beyond enabling RDP and patching.

Not GP or such. The machine on boot looped between a restart after the BSOD (restarted itself) and a self-triggered automatic repair and reboot (which BSOD'd after).

Definitely not interrupting the boot cycle.
-Alan

@dinhngtu That's not in the file system either...

@dinhngtu No, I can't catch the boot to get into Safe Mode. I have the disk mounted on a Linux instance and can see the Windows systemroot, but I can't find a crash dump in there, looking for a Windows\Minidump or anything *dump or *dmp.
-Alan

@dinhngtu Is there a way to do this when you can't get to a point where you can log in and install/run that?
Thanks for the reply!

Been testing XCP-ng 8.3 in my home lab by running a server inside a KVM VM. I've set the VM to about 32GB RAM and 250GB disk. It works fine for various Linux machines with various distributions.

I haven't had much luck with Windows 10 however. Almost all the time the machine crashes during boot with a SYSTEM THREAD EXCEPTION NOT HANDLED BSOD.

I've used the template for Windows 10 x64 and tried various settings for vCPU count and RAM, and UEFI vs BIOS. I've swapped DIMMs in the hardware a couple of times to try to rule that out.

Is there anything obvious I could try to stabilize this for testing? Or is the scenario just not possible?

Screenshot attached. Thanks in advance for any thoughts.
-Alan