banackm's Posts

We'd love to make that number report higher if we could, yeah.... Our development team may yet find a clever solution here. The mksSandbox.exe now runs most of the graphics workload for the VM.  So it shouldn't be doing any extra work from what we did in prior versions, it's just moved out of the vmx process and into this new one.

You can get it to read 128MB on older hardware versions, but we were unable to make that number go any higher using our old design.  The newer hardware versions actually allow applications to get access to more memory even though that number reads lower. We're definitely not happy that applications are explicitly checking that value to determine compatibility, and we don't have any good solutions for that at the moment.  But our actual graphics architecture runs applications better now with our new design.

We can't talk about dates for specific features on the forums other than to quote any official announcement VMware has made.  But we do have a dedicated team working on graphics that tries to deliver performance improvements with every major release.

@lasponger  Yeah, the deeper problem you're running into there is that Adobe requires DirectX 12, and today we only support DirectX 11.  There's no easy fix for that, but it's certainly something we're working towards.  Assuming we could do something about the memory value, I suspect that wouldn't actually help without also supporting the higher DirectX version. @VMHappyUser  You can check in your vmware.log to see which host graphics card we started on.  But the memory limitations here are a function of our virtual graphics hardware, and not anything to do with the host graphics card. There's no way at the moment to increase the Dedicated Display Memory to 1.5 GB for any host/guest configuration, because unfortunately the way that we are doing the graphics virtualization makes that proposition more complicated than it sounds. That said, we're aware of these issues, and we're certainly open to anything we can do on our end to make Adobe software work better in a VM.  So our development team will do our best to find a solution here.

With 3d acceleration disabled, you're using Microsoft's in-guest software renderer for your Direct3D graphics rendering.  So the "12GB" of memory that they display there is really misleading and just notes that their software renderer can use that much memory. When 3d acceleration is enabled, then Microsoft starts using our Direct3D graphics driver and is subject to the memory capabilities of our virtual graphics device.  But it will really be running on your host's GPU in that case.  I'm comparing us to an integrated graphics card only in terms of the layout of our virtual PCI device.  We will still accelerate your the VMs graphics rendering on your host's graphics card regardless of whether you have an integrated or discrete GPU on your host. The 4MB that it displays there for "VRAM" is also misleading, because it can only be used for your primary display output, and not for general graphics rendering. I'm not sure what specific application you're running that isn't seeing a benefit from enabling 3D acceleration in the VM, but possibly it requires a version of Direct3D higher than what we support.  We should be able to support up to Direct3D 11 depending on your host configuration, but if an application requires Direct3D 12 then it may be running on Microsoft's in-guest software renderer.

I suspect the issue here is that the 3rd party mouse driver for your Razor is doing something to mangle the mouse events after they've been initially submitted to Windows, and that's occurring after we've done our initial mouse processing.   We have some code to try and drop duplicate mouse events that has a timing element to it, and I think when you stop moving the mouse briefly those scroll events are going through, whereas if you're actively moving the mouse we think it's a duplicate event and drop it. We have a config option that will let you opt-out of the timing detection that might get the scroll events working, although it's also possible that it will make you start double-processing other kinds of mouse events like button clicks.  But you can at least give it a try and see if it helps: #Disable timer for duplicate mouse detection mks.win32.useTimedMouseHookEvents=FALSE

So it looks like your vmware-vmx exists there, but it's in some kind of kernel call or something? You might see if you can attach a debugger and get a backtrace.  If something's going wrong on your system, I'd expect to see that in some kind of a system call into your kernel that might tell us what's going on. It's also possible it's trying to call into VMware's kernel modules, and something there is broken?  You might try uninstalling and re-installing Workstation.  If your host kernel upgraded for instance, maybe it's not correctly figuring out it has to re-compile our kernel modules.

@KevinGG  Yeah, I'm not sure what those error messages mean, but it looks pretty clearly like the VM process is still running, but either part of it is hung, or something has happened so that the guest isn't making forward progress any more, probably related to the disk activity.  I'm going to file a bug internally with the disk/file-sharing team to take a look at your logs. So probably you were hitting the 3D crash because it was detecting an actual hang, as opposed to most of the cases here where it looks like we're falsely detecting a timeout when we shouldn't.

Normally it means the UI process is trying to connect to the process running the VM itself.  So it looks like your VM is hanging very early in start-up, before the UI can properly connect to it to open your console. Can you check if the vmware-vmx process is still running at that point?  And if so, is it using CPU or is it hung?

@KevinGG  There shouldn't be any mksSandbox process running when 3D is disabled, so you can't hit this particular crash when 3D is disabled. The last round of vmware.log's you posted in the last round don't show this same issue, and the mksSandbox.log's you have in there are stale, from the last time you did have 3D enabled. What your vmware.log's do show there all just stop with a message about WM_ENDSESSION ?  I think that happens when your user session logs off (because of Log Out, idle, or host sleep/shutdown?), and we try to suspend your VMs, but Windows will often give up on us because it takes too long to suspend the VMs and it just kills them.  So I think at this point you're hitting a different issue with your file-copies. You may still have some underlying host clock issue that's triggering both things though.  There are some indications that something timed out or had a clock jump right before the logs cut off.  But the WM_ENDSESSION thing is really suspicious by itself, and sounds like there's some other involvement with something on your host?

So that log doesn't have 3D enabled?   You're saying this reproduces without 3D ? The log just stops in early PowerOn, so if you're sure that's a case where you hit it (and the timestamps aren't stale, and there's nothing else in /tmp/vmware-youUserName that looks more recent), then something on your system is hanging right there, or else something killing it very suddenly (like the OOM killer or something). Can you power on a VM with very low memory settings and 3D disabled?

@KevinGG Yeah, if you could post here or send me in a private forum message the vmware-*.log and mksSandbox-*.log from the VM folder for the VM hit this that would be really useful.  If they have "PANIC:" in there you have the right log files and they haven't cycled out yet.

We still haven't been able to reproduce this internally yet, but our best theory is that there's something quirky happening with the host clocks/timing.  @Dr_Acrobat__no_ , your logs in particular show 30-90min jumps in the timestamps right before the problem hits. We're not clear on what exactly is going wrong there, whether it's a bug in your host hardware, or we're doing something funny picking our timing source, but a jump like that would certainly trigger our timeout detection artificially. So if the other timeout value I suggested isn't working for you, we'd suggest you try setting an extremely large one, such as: #43200000 ms = 12 hours mks.sandbox.socketTimeoutMS = "43200000" It should work either with/without quotes around the number, but possibly some editors will do funny things with whitespace/line-ends  and mess that up?  So if people are having better luck with the quotes on, it's fine to put them there.  

>I just assumed it had all the files you would need. Yeah, it's supposed to, but it sometimes doesn't go find all the correct VMs on disk for various reasons. Both of you have logs that are showing the VM losing it's connection to the graphics system.  There's a large time gap before that which might indicate something was hung, or might just mean everything was idle. What's happening on your host systems when the crash happens?  Like, are you suspending/sleeping the host?  Are there other heavy graphics/disk/memory workloads running?  Because I can't explain just from the logs why this would either timeout or start dropping the connection. Besides increasing the timeout config value I provided, if you're running the latest 16.2.1, you could try turning down the graphics memory on the VMs?  That should scale down the amount of memory involved in running 3D graphics under the theory that your host is running out of memory resources.  But both of you are hitting a very similar issue that we're going to have to try and reproduce internally.

@ATSmatthewb, I don't see the actual VM logs with the crash in that bundle for some reason.  They should be in the VM folder named something like vmware-#.log and mksSandbox-#.log .  If you can post those I'll take a look.

Unfortunately, I wouldn't expect a fix for this from the VMware-side any time soon.  We are correctly reporting how our virtual graphics card is representing it's memory layout, it just happens to be unusual for high-end graphics cards to not have much Dedicated memory, and so this causes application compatibility issues.  We have to dig into them individually and usually work with the 3rd-party software vendor to resolve them, so we typically can't resolve them quickly. We're aware of the Photoshop issue, and we've seen issues with Chrome that tend to come and go as they release new versions. If there are other applications that are running into graphics memory problems please let us know the specific applications and we'll see what we can do. Otherwise the best advice I can offer in general would be to try and contact the other software vendor and see if they have a work-around or a fix they can offer to force their accelerated path on.

It's possible a host graphics driver update will fix the problem for some users, and as noted switching X11<->Wayland seems to also fix it. on some configurations.  But I would expect this generally needs a patch from the VMware side. Small benchmarks with very high frame-rates (such as glxgears/vkcube) are going to be the most impacted by the Vulkan->X11 presentation work-around.  Apps with lower frame-rates and higher 3D workloads should be less impacted.

This issue would be specific to Linux, but there may be other issues that hit on Windows.  You may want to follow the thread here for a similar sounding issue that hits on Windows hosts: https://communities.vmware.com/t5/VMware-Workstation-Pro/VM-Crash-16-2-1-build-18811642/td-p/2877469