Windows 8.1 guest on Windows 10 host will only run for a few minutes before getting memory error message.
Have had to hard reset host machine 3 times this evening when guest VM running in background.
Happens even when nothing running in guest OS.
Windows 10 host seems to run fine so far without VMware running.
Thanks for your information!
one more question, what's the arch of your windows 10? x86 or x64? And also the Horizon client, 32bit client or 64-bit client. We will continuously try to reproduce this in house.
64 bit OS & 64 bit client
Same, 64 bit OS & 64 bit client.
Would you check the the version of agent and broker? Thanks!
Hi JDTheMatrix,
Would you pls check the the version of agent and broker? Thanks!
Hi JDTheMatrix
Could you please try to update your Horizon client to version 4.4 and take a try again? The 64-bit installer of Horizon client 4.2 was still using 32-bit binaries, so that could be the problem because we also see the memory leak on "32bit client over 64 bit system" scenario.
We already reproduced this issue on Horizon 4.2 client, but not with Horizon 4.4 client. So please take a try to see if the issue persist.
How can I get these versions?
I was also going to try and uninstall and install the windows UWP version. We will see what happens.
FYI, we've had the same problem with Horizon client 4.4, 64-bit. In fact, that's what we were using when the problem first started on Windows 10 Pro 64-bit version 1703. We then tried using older versions of the client (3.4.0, 3.5.2) to see if that would make a difference, but the same problem happened.
The only way we were able to get the Out of Memory issue to stop occurring was to rename the .dll to disable Thinprint. This is not ideal as we do need to print. But it does allow us to use VMware without the workstations crashing.
Thanks.
You can download 4.4 clients from Download VMware Horizon Clients
I attempted to install and use the 4.4 client but unfortunately kept getting a disconnected message. Its possible my company has not upgraded/updated to that version of the host.
That will help us to confirm if your issue is as same as we already know. wdaley The process splwow64.exe will eat out the memory, and that's the issue we currently know.
Curious if there has been any solutions found for this memory issue? I have been having the same issue with no resolution. Currently using 64bit windows and 64bit horizon client version 4.4
Any news related to the problem?
We are a large organisation with a lot of Horizon view users.
The workaround with renaming thinprint.dll isn't a ideal situation.
Will there be any fix available soon?
I'm getting this same issue when using the RDP protocol. I was troubleshooting an unrelated issue and switched my VDI from the VMWare Blast protocol to RDP. I immediately started getting out of memory errors and system crashes. Switching back to Blast works normally.
I noticed that the process memory usage was showing normal in the task manager, but the "Committed" memory had been slowly growing and growing until it was over 30GB, eventually crashing or causing weird display glitches. Even when closing the Horizon client, it didn't reduce the committed memory, so I have to reboot to clear it.
(I'm using Horizon server 7.1, agent version 7.1, EUC 3.0, with client 4.4.0 on Windows 10 build 1703)
I've had this same issue running Win10 Pro Creators Update. Started with Horizon 4.2, downgraded to 3.5.2 because I had it handy, then went to 4.4. All three had the same problem. Committed memory creeps up until the machine is out of memory and then the display driver gets killed off and I have an unrecoverable black screen. I renamed the thinprint dll file as suggested earlier in this thread, and it works perfectly now. I'm still on Horizon 4.4.
Before I circumvented the issue by renaming the thinprint dll, I did save a service dump from Horizon while the leak was occurring. I'm happy to upload it if someone will tell me where.
System Info:
Horizon 4.4.0.6474 Build 1571611 (downloaded today from VMware)
Host OS: Windows 10 Pro 6.3.15063 (Creators Update) All Windows Updates are up to date as of today.
Guest OS: Windows 7 Enterprise SP1 64 Bit, 4Gb RAM
Host Hardware/Software Information:
OS Name | Microsoft Windows 10 Pro |
Version | 10.0.15063 Build 15063 |
Other OS Description | Not Available |
OS Manufacturer | Microsoft Corporation |
System Name | |
System Manufacturer | Dell Inc. |
System Model | Latitude E7270 |
System Type | x64-based PC |
System SKU | 06DB |
Processor | Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz, 2496 Mhz, 2 Core(s), 4 Logical Processor(s) |
BIOS Version/Date | Dell Inc. 1.5.3, 4/18/2016 |
SMBIOS Version | 2.8 |
Embedded Controller Version | 255.255 |
BIOS Mode | UEFI |
BaseBoard Manufacturer | Dell Inc. |
BaseBoard Model | Not Available |
BaseBoard Name | Base Board |
Platform Role | Mobile |
Secure Boot State | On |
PCR7 Configuration | Elevation Required to View |
Windows Directory | C:\WINDOWS |
System Directory | C:\WINDOWS\system32 |
Boot Device | \Device\HarddiskVolume1 |
Locale | United States |
Hardware Abstraction Layer | Version = "10.0.15063.0" |
User Name | |
Time Zone | |
Installed Physical Memory (RAM) | 8.00 GB |
Total Physical Memory | 7.88 GB |
Available Physical Memory | 3.97 GB |
Total Virtual Memory | 9.13 GB |
Available Virtual Memory | 4.79 GB |
Page File Space | 1.25 GB |
Page File | C:\pagefile.sys |
Device Encryption Support | Elevation Required to View |
Hyper-V - VM Monitor Mode Extensions | Yes |
Hyper-V - Second Level Address Translation Extensions | Yes |
Hyper-V - Virtualization Enabled in Firmware | Yes |
Hyper-V - Data Execution Protection | Yes |
Which protocol are you using? I'm getting this issue when using RDP with the Horizon Client. But it doesn't not happen when using VMWare Blast
I'm using RDP as well. My organization doesn't support PCOIP or Blast for some reason. The DLL file you change the name of to prevent the problem (see earlier posts in this thread) is TPCInRDP.dll, which would seem to indicate that it is specific to RDP. You can see below, I added "--OLD" to the name which effectively disables the service and prevents the memory leak associated with the splwow64 service. I can also confirm that that service was in fact running when the memory leak was happening (but not after renaming the dll file), and that killing that service immediately releases the committed memory, essentially "resetting" it to the proper levels. Unfortunately the service auto-starts again pretty quickly and the leak starts again. Someone more clever than me could probably write a script that restarts the splwow64 service every 5 minutes or so. This may be a viable work around if you have people that need to print from their VDI. Hopefully VMware will release a patch for this soon since it is the same problem that people were having with VM Player in the OP, and that has been patched.
Darius,
https://communities.vmware.com/thread/560861?start=75&tstart=0
There are several people still waiting on VMware to provide a solution to this problem of the memory leak in the ThinPrint service using various versions of Horizon. I understand that the issue has been corrected with MVware Player, but this Horizon issue still persists. I've provided several informative (I think) posts to this thread over the past few days, and other have been looking for updates since the end of May, but no response from VMWare staff.
Can you or one of your co-workers please pick up this thread again and work to provide a solution to this issue with Horizon?
Thank you,
Mike
I had hopes with the 4.5 release a few days ago the problem would be resolved. But it is not, the same commit memory leak exist. Until this is fixed we have users switch to use Blast.
I've put in a request for someone with Horizon experience to review this thread. I've never worked with Horizon and it's waaaaay outside my area of expertise, so there isn't much I can provide in the way of knowledge or insight.
I will say that it's odd that we're seeing reports of this happening with 64-bit Horizon Client, since we recently published a KB article (Horizon Client printer redirection feature consumes too much memory on Windows 10 Creators client) which itself suggests that the problem should only occur with 32-bit Thinprint, which was included in the 32-bit Horizon client and in some older (pre-4.4) versions of the 64-bit Horizon client. Since 4.4 at least, it seems the 64-bit version of Horizon Client should include a 64-bit Thinprint instance, which should not be affected by this particular problem.
Is there any chance that your system still contains an old 32-bit version of Thinprint, maybe a remnant of an earlier Horizon Client installation or perhaps even included with Workstation or Player co-installed on the client?
That's about all I've got... Hopefully one of the Horizon folks can pick up from here.
Cheers,
--
Darius