I give it topology; 2*2; 100GB space & 16 GB ram.
I have tried ‘Legacy Bios’, ‘UEFI x64’, ‘UEFI SECUREBOOT x64’. The windows manual stated it’s a fix within the system… Within Windows, that you do a secure boot for in order to find what’s wrong.
I have now tried it with bootleged windows ISO’s, and the original from Microsofts own page, both Win10 & Win11. Same results. So I was thinking, maybe it’s QEMU that’s at fault here.
I installed ArcoLinuxXL without a problem, and a bunch of other Linux distro’s. It’s a Windows only problem.
… Woah, I have had 32 GB of ram in the computer for ages, and there hasn’t been any problems at all, this began with a newer kernel or later versions of Linux, I actually use at least 16 GB per session, I rather not go down that road.
Still the same result. It’s a CPU thing, and it started with newer versions of the Kernel. I get it my 1700X is getting old, but did it really have to get into this situation? It started noticing it this year. I haven’t had any problems with it before. Last year I had multiple Windows VM’s.
I have an idea what it could be. You run a first generation Ryzen processor and the early models of the first generation were affected by what was known as the segfault bug. This bug was not due to some faulty software, but to an actual undisclosed problem with the silicon. Peoples attention was drawn to it because some tasks like compiling certain application would fail an crash the kernel. I have first hand experience, by owning an affected processor for a short time, that this bug also affects virtualization. There are some tools that try to trigger an error by this hardware bug, but to be sure if you are affected you can remove the cooler, thermal paste and look at the print on the processors heatspreader, the production year and week are mentioned in the small print on there. If you want to be sure that you are unaffected you processor needs to be produced in week 26 of 2017 or later!