The connection to the mksSandbox was lost. So it would be better to look at the mksSandbox.log file instead of the vmware.log. I think with 17.5 Windows 10/11 VMs can support DX11.1 but up to feature level 11_0 only (you can see in dxdiag of the VM); so if the game is using DirectX looking for feature level 11_1 or newer, there is no fix to this.
From the vmware.log you attached,
2023-12-30T18:21:21.764Z In(05) vmx Monitor Mode: ULM
2023-12-30T18:21:31.893Z In(05) vcpu-0 Guest: vm3d: Driver=wddm, Version=9.17.06.0003
In the meantime, you could try the following
First, you could try updating the SVGA driver to 9.17.6.5 (either Windows update or from VMware Tools 12.3.5) although quite unlikely it fixes the problem.
Second, is to try to switch to using OpenGL as the renderer instead of DX12. Shut down the VM, add/edit the following lines. I am not sure if mks.forceDiscreteGPU still works for version 17.5 but alternative would be go to Nvidia Control Panel - Manage 3D setting and select the Nvidia as the Default Processor instead of Automatic.
mks.forceDiscreteGPU = "TRUE"
mks.enableDX12Renderer = "FALSE"
mks.enableDX11Renderer = "FALSE"
mks.enableGLRenderer = "TRUE"
Third, Monitor Mode is ULM; that means the VMware hypervisor goes through additional software layers with the Microsoft Hypervisor API (which slows things down). You could refer to this post,
https://communities.vmware.com/t5/VMware-Workstation-Pro/Disabling-Hyper-V-hypervisor-on-Windows-11-...
Although it is very lengthy, this is probably a better reference; some steps may/may not apply as configurations between Windows hosts can and will be different. Once Hyper-V is completely, monitor mode should show as CPL0.
Oddly enough, switching to CPL0 might have a higher chance of fixing the problem assuming it is not a crash of the mksSandbox process but just a lost connection.
