behealed's Posts

I encountered this bug while running a virtual machine that was playing a modern 3D game, and while using relative cursor positioning. This bug can get triggered in certain cases when using a relative positioning mouse. Does not matter if it is a USB or PS/2 mouse. Doesn't matter if the relative positioning is because of using "gaming mode" mouse, or by various options available to switch to relative mouse in the VMX config file. While the cursor is grabbed, the MKS thread is repeatedly calling the same functions over and over, in the code where it "hides" the cursor on the host. The cursor is successfully hidden, however, the repeated allocations needed for CreateCursor, has a memory leak which gradually causes the host to run slower and slower. Shutting down vmware-vmx.exe, and restarting the guest, does not clear up the leaked resources. Only thing I can find to get the resources back (and get the frame rate back) is to fully reboot the host machine. The exact location where these calls to CreateCursor are made, is in the VMWARE-VMX.EXE, in the same function and same general location where it checks the value of mks.noColorHostCursor. This is the function where it hides the cursor on the host. Without this function, the host's cursor would still be visible and stationary on the host, even while grabbed by the guest, which looks ugly. NOTE: There are actually two different spots where vmware-vmx.exe makes calls to "CreateCursor". The spot that gets called 1k times per second, is NOT the spot that's located in the same function where it checks the value of mks.noColorHostCursor. But rather, it's the other call, located in the other spot. Trust me. Rather than call CreateCursor repeatedly, it might be better to simply move the host's cursor off the edge of the screen. That would hide it from view, without the need to call CreateCursor to hide the cursor. This would solve the memory leak. But, whatever. Also, you're welcome. This took me days to find. If vmware would like me to find more bugs like this, gimme the pdb file. I'm subscribed to this thread, so any questions, just reply.

Right click desktop -> display settings -> advanced display settings -> Display adapter properties -> Monitor -> Screen Refresh Rate. For my VM, the screen refresh rate is set to 60hz, and there's no option to change it to anything higher. I've installed VM Tools, which successfully installed the graphics driver.  My physical monitor is 360 hz, and I'm on a very powerful gaming computer. 3D acceleration of course is activated for the VM.  I previously worked with VMware 15, and it did not support higher than 60hz frame rates. Does version 16 support it now? I saw people online talking about how they were getting 100 FPS in some games on workstation 16, which got me excited. However, after installing version 16 myself, I don't see any options under monitor settings to go higher than 60hz. So I'm assuming that all these people who think it's giving them 100 FPS, are mistaken. Right? Because some games will actually report that they are rendering at 100+ FPS, but in reality, you're still seeing just the 60hz that your monitor is limited to. So I assume that everyone who thinks version 16 is rendering at higher than 60hz.... they are mistaken. But if anyone can definitely tell me that they were able to set the VM's monitor fresh rate to something higher than 60hz, please tell me how you did it. Thanks!

If I delete the VGA.ROM file from the vmware-vmx.exe's folder from my host's hard drive, and try to boot up a windows VM, it displys an error message saying that it couldn't find the VGA.ROM file as soon as I start the VM,however, it gets past the error message with seemingly no further problems and loads into windows, but everyting is in black and white and set to 640x480 resolution. If I install VM Tools, the display problems seem to entirely dissappear and it seems to have all the features of a full 1080p, with I assume 3d acceleration as well, even though the VGA.ROM file was deleted. I thought that was kind of interesting, but, that's not even my question... So here's my question... If I DO NOT install VM Tools, and I'm in windows with no VGA.ROM, with black and white only, 640x480 resolution, and nothing but the microsoft basic display adapter... if I go to device manager and look at details on the display adapter, under hardware id, it gives me this: PCI\VEN_15AD&DEV_0405&SUBSYS_040515AD&REV_00 That VEN_15AD is the vendor ID number for VMWare, which means that windows is seeing the virtual device's hardware id number. That hardware ID is always the same. It's the same if I install or don't install VM Tools, and it's the same if I delete or don't delete the VGA.ROM file. It seems like no matter what, windows always knows and see's that same hardware ID string for the display adapter: PCI\VEN_15AD&DEV_0405&SUBSYS_040515AD&REV_00. My question is, where is windows getting this information? I've deleted the VGA.ROM file, and it still somehow knows and sees this hardware id number. In a physical machine, I would conclude that windows is directly accessing the physical device through the PCI port, and that the device is telling windows what it is. However, in this case, I've deleted the VGA.ROM file, which i assume is supposed to be the device's bios file. Without that, I can't see how the virtual adapter is telling windows anything AT ALL (I'm surprised it even boots, but admittingly I don't really know how rom files work to be honest). But since this is a virtual device, I know windows is not talking to a physical device. Windows must be talking to a piece of software, and that software must be giving windows that hardware ID string. i checked the windows reigstry, and it's not there either. So my question is... if it's not in the registry, and not VGA.ROM or VM Tools or any driver (no drivers are installed), then what path is windows taking to get this information, and what peice of software is sitting at the end of that path, communicating this hardware ID information back to the VM?

As a developer, I know it's a deeply disturbing question when someone asks if your splash screen can be changed. But before I unload my long and complicated (but fairly legitimate) reason for why I'm asking this question... is it even possible? I'm using VMWare Workstation Player 15.

I have windows 10 installed on the VM. When I right click the desktop -> Display Settings -> Advanced display settings -> Display adapter properties for Display 1 -> Monitor -> Screen Refresh Rate -> it only gives me the option for 60hz. My host has a GeForce RTX 2060 and is set to 144hz with a 144hz physical monitor. The VM has accelerated graphics enabled in the settings, and I can get "250+ frames per second" running games on the VM (depending on the game), but because the VM's "virtual monitor adapter" is set to only 60hz, I can only actually see 60 frames per second.

I am running Workstation Player 15, on windows 10 pro. My VM's are set to use 3GB of RAM, 3GB of graphics RAM, 2 CPU cores, and 60GB of HDD. My host machine has 8GB of RAM, 8GB of graphics RAM, 4 CPU cores, and 1TB of HDD. I only ever open one virtual machine at a time, never multiple VM's open at once. I have a total of 10 virtual machines set up. When I suspend a virtual machine, here's what happens. TL;DR: It takes only about 5 seconds to suspend and VMWare window is fully closed, then "System" sits in task manager using huge hard drive activity for about 5 whole minutes, during which time I cannot restart the VM that I just suspended (various hangs if I try), and if I attempt to start any other VM it literally freezes my host and I have to hard restart the host by holding down power button. However, if I wait 5 minutes for hard drive activity to finally end, then I can restart the VM and it resumes from sleep very quickly, in under 20 seconds. UPDATE: I added the line mainMem.useNamedFile = "FALSE" to my config.ini file, as some others had suggested on other topics, and now "System" doesn't sit there for 5 minutes using HDD, and I can resume the VM immediately after I suspend it. However, the new problem is, it now takes 2 whole minutes to suspend / resume, because now it spends a lot longer "Saving Virtual Machine State" and "Restoring Virtual Machine State". Is this normal? Previously it was VERY fast to suspend and resume, except I had to wait 5 minutes for "System" to quit hogging 100% hard drive after every suspend. Now I don't have to wait for HDD to stop, but now I have to wait 2 minutes on the "Saving Virtual Machine State" and "Restoring Virtual Machine State" screens. Is there any way I can make this faster, or is this normal? This is with no applications running on the VM, just the windows desktop. I can't understand how adding this line to my config.ini file would cause it to take much longer to suspend the machine? Message was edited by: Aaron Brown

So here's the steps to reproduce: 1) Host machine is set to 1080p. 2) VM settings is set to "use host display settings/resolution" (the recommended setting). 3) Start the VM, put it in normal window mode (not full screen, and not unity, just the resizeable window), and set guest windows to 720p resolution. 4) Now enter Unity mode, then exit Unity mode. 5) Observe that the resolution should return to 720p, windowed mode, as expected. 6) Enter unity mode again. 7) Now, start a video game, and tell the video game to go into "full screen at 1080p" resolution. Unity mode streches to fit the whole host screen, as expected. 9) Now exit the video game. You are back on the desktop, which is at 720p resolution. 10) Now exit unity mode. 11) Observe that exiting unity mode has now forced windows to quit being 720p, and changed the resolution to 1080p. Sorry for the long repo steps, but the last step is where the issue appears. If you are in Unity, and you run an application that temporarily changes the resolution from 720p to 1080p, then Unity mode will accomidate that change, but then when you exit that program and return to windows desktop, the resolution of windows desktop is 720p, but unity mode doesn't recognize that anymore and as soon as you leave unity mode it will change windows' resolution to whatever was the biggest resolution that it experienced (aka the higher 1080p resolution that occured while the game was running). The root of the problem seems to be that unity doesn't seem to recognize the resolution of the windows desktop. It only respects the resolution of whatever app or game you run (and many games do change the resolution, especially if they are running in the game's "full screen" mode). Unity seems to recognize the game's resolution, and makes it work on the host, no problem. But then after the game is closed, and you return to the desktop, unity mode doesn't seem to notice that the resolution went back to whatever is the desktop's resolution. And so if you then exit unity, it will put the resoltuion to the higher resoltuion that the game previously was running at, and you lose the resoltuion you set for your desktop. I like running my desktop at 720 because it lets me keep VMWare running on the side of my screen without hogging my whole host screen. But then when I run a game, I have it at 1080p so it fills my whole host screen. After the game is over, I exit unity mode, and it's changed the desktop resolution to 1080p. But again, this problem doesn't occur if I don't actually play a game. For example, if I'm on the desktop, and I simply enter unity and then exit unity, it goes back to 720p. It only changes the desktop's resolution if I actually enter a game while I'm in unity mode, and the game temporarily changes the resolution... then it's messed up, and when I exit unity, it'll change the desktop resoltuion to whatever the resolution of the game was. Hope I explained this issue thoroughly enough.

I saw a page in the docs that says this results in "extremely poor performance, because the host machine can't process background tasks if all cores were assigned to the VM" (paraphrased). source: Selecting the Number of Processors for a Virtual Machine Why is this? I mean, doesn't the host also get to use all 4 of those cores? Or is VMware workstation set to realtime priority or something? If not then I can't see how the VM could actually block the host from using the cores. Can anyone explain this to me better?

Today I noticed that every few minutes I lose the ability to send mouse clicks or keyboard inputs to the VM. I'm using VM workstation 15 player. After about 5 seconds, the input starts to work again. I see no errors or anything. During the 5 seconds, I'm still able to see my mouse cursor moving when I move it, but when I click, there's no click received by the VM. Also no key presses work during that time either. It's around 5 seconds but it can be longer or shorter than that. I'm playing video games on the VM so, obviously, losing input for 5 seconds is bad. Curious to know if anyone else has seen this, or if anyone could suggest what might be the cause of these periodic input losses? If I need to research this out myself, it would be helpful if anyone could tell me the whole pipeline of how input is received by the VM, so I could try to understand where along that pipeline the problem might be occuring.