Windows10 boot: SYSTEM THREAD EXCEPTION
-
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
-
Nested virtualization has some compatibility issues. Could you analyze the crash dump with Windbg and see what it says?
-
@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! -
Does it boot into recovery or Safe Mode at all? If nothing works, you can pull the crash dump with a Linux live CD, then analyze it on your own Windows machine.
-
@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 -
Try
\Windows\MEMORY.DMP? -
@dinhngtu That's not in the file system either...
-
@webminster You may have jumped in with the reboot and boot disk before Windows had the opportunity to generate the file, or may have the memory dump functionality disabled via Group Policy or in the System Properties. You could have had the file erased with "Disk Clean-up" or as part of "Storage Sense".
Thus you will likely not be able to find that file your looking for.
-
@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 -
@webminster said in Windows10 boot: SYSTEM THREAD EXCEPTION:
@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.
-AlanIs the VM part of a Domain Login (via Windows Server or Samba) if it is did you define it in the GPO when setting up the Domain's Group policy?
Cause this is propagated to all domain member computers.
-
@john-c No. It's a basic no-frills standalone machine.
-
@webminster said in Windows10 boot: SYSTEM THREAD EXCEPTION:
@john-c No. It's a basic no-frills standalone machine.
Have you made sure it's not a hidden file as Windows hides files by default! So if the "%SystemRoot%\Memory.dmp" has the Hidden and/or System bit set it will be not visible on default settings.
One sure fire way to tell is to enable Windows to show the hidden files, then have a look or using the command line terminal to run a listing and/or search in the %SystemRoot% directory for the file.
Linux is case sensitive don't forget, but Windows isn't so if the case for the file name doesn't match then it won't be found.
Also if the system crashes too early and/or quickly when doing BSOD it may not have the filesystem components and drivers, loaded yet for the "%SystemRoot%\Memory.dmp" file creation.
-
@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.
-
You can redirect its serial port to a TCP port on the host (
xe vm-param-add uuid=<uuid> param-name=platform hvm_serial=tcp::7001,server,nodelay,nowait) then connect a Windbg remote kernel debugger using a connection string (com:ipport=7001,port=192.168.1.xx)