When running 3d accelerated games in win11 using either vmware-workstation or virtualbox, that are also using compatibility mode for windows xp sp3, they crash almost immediately at/after launching. Programs that don’t use 3d acceleration appear to be unaffected, just programs that are accelerated. Repeatable on 2 different systems.
This bug(?) is pretty specific. Full system specs will be at the end. I was running the default kernel until 2/2, when I started experiencing issues. Did a full EOS reinstall, including wiping home, and still had issues. lts kernel fixes them. Looking at https://github.com/archlinux/linux/releases , v6.13.1-arch1 was when problems started. I compared it to previous kernel but nothing stood out to me https://github.com/archlinux/linux/compare/v6.13-arch1...v6.13.1-arch1 – latest zen kernel has same bug.
Specific game: Dungeon Siege 2 with Killa fix for Broken World + Legendary Mod
VM instead of Wine?: Playing with a friend, so requires gameranger
Steps to recreate: Install EOS with KDE, update, install vmware-workstation, start vmware-workstation services, install windows 11 in vmware, install Dungeon Siege 2 with Killa fix for Broken World + Legendary Mod, set EXE to use windows 98 sp3 compatibility mode, game crashes at/soon after launch. The longest I got a game to run was loading from the main menu into the actual game world.
Game will launch/run without compatibility mode active, but will have several visual artifacts such as non-transparent textures that have transparencies. This behavior is expected and why compatibility mode is used.
Lts works. My concern is that whatever is in the base kernel will eventually be merged to lts.
I’d tried restoring a system snapshot (timeshift) from Jan 5th, but had to update with arch-chroot on a live USB to have a bootable system again.
I’ve unfortunately reformatted since then, so spending part of today figuring out how to install the first 6.13 kernel from 2 weeks ago to confirm it didn’t have issues.
Not intending to highjack this thread, so if I am, I apologise in advance.
OK…I have a similar weird experience with 6.13.x and KVM/Libvirtd on my Win10 gaming install. On Kernel 6.13.1 and 6.13.2 every time I attempt to do anything with Steam - it just silently crashes - nothing in the error logs there at all.
I re-installed Steam multiple times on that instance and it just kept crashing. I think tried a fresh install of Windows 10 on a different VM (with all of the same virtual hardware including a GPU passthrough) and that install started having issues with a different program. I finally decided to reboot back to LTS 6.12.x and when I started the original Win 10 VM - Steam was working just fine. All of the behaviour that caused crashing under 6.13.x worked fine in 6.12.x.
I updated when the kernel went from 6.13.1x to 6.13.2x and it didn’t help.
I want to dig into this more but I don’t know which log might show some errors. I trolled through journalctl looking for any sort of indicator and nothing showed up; I tried various forums and bug trackers for libvirtd, QEMU, Kernel.org and KVM - Nothing sounded even close to my type of issue.
So while this is different a different VM setup the kernel version issues sound similar.
I appear to be able to re-create the issue at will right now, so if someone has an idea on possible information gathering or troubleshooting I could do, I’m happy to do so.
New Kernels, same behavior. Attempting to use compatibility mode on a win11 guest with a 3d accelerated game causes various crashes. Specific test game is Dungeon Siege 2
6.13.3.arch1-1 crashes nearly immediately. Always crashes by the time it loads in to the game world.
lts 6.12.15-1 still works fine.
I don’t know when lts bumps to the 6.13 branch, but hopefully it doesn’t include whatever broke things.
Correct - Steam just closes - Doesn’t generate any errors in it’s logs or any Window’s logs. On the underlying Endeavour layer - Nothing in Journalctl that looks like it would be the problem and I didn’t see anything in the systemclt status logs for Libvirtd right after. Happy to look at other logs if you have an idea where.