While running multiple Windows Server 2008 R2 RDSH farms we are experiencing an issue where the RDSH servers all are having their Registry bloated to the maximum value 2048MB. Using Sysinternals Registry Usage (ru.exe) we were able to determine over 1000MB of the registry being used up by Samsung Universal Printer related keys.

  • Samsung Universal Print Driver: Version 2.3.90
  • Samsung Universal Print Driver 2: Version

Registry Sections where the bloat is occurring:


Each of those subkeys has over 500+ keys where Registry Usage is reporting they are taking up 30-40MB each.

Example subkey: HKU\.default\software\ssprint\spe__\{BCC489E0-E2CA-442B-A5A5-9B849579BE1F}

Looking into the data of the keys "Capabilities", "MUIData", etc. You can definitely tell they are Samsung Universal as the values reference Samsung Universal when you view them.

Taking one of the servers out of the mix I tried cleaning up these keys and was able to. Cleaning the ".Default" section also cleaned the "S-1-5-18" keys, so I'm thinking these are a reference link within the Registry. When I did it I cleared the HKU\.default\Printers\DevModes2 as well since this section would not even open in Regedit. In order to remove I had to CLI the to remove the "DevModes2" key and then recreate the key in Regedit.

As soon as I login with an account that has a printer deployed to them with the Samsung Universal Print Driver these keys start appearing and bloat out the registry. Because the registry is so filled up we have been experiencing User Profile issues causing Temporary Profiles to load. When we disabled the ability to have a Temporary Profile the users then may run into a "The User Profile Service service failed the logon. User Profile cannot be loaded." message.

Has anybody out there experienced this issue?

Is there some setting in the Samsung Universal Print Driver to prevent this behavior or to have it clean up after itself?

  • I feel your pain. HP Universal Drivers weren't much better some years ago, where the spooler would crash with thousands of HP processes running. I'll be watching this question for sure. – pauska Oct 4 '13 at 19:49
  • Samsung support created a case today when I called in. Hopefully, they will have an answer soon. – Arachnid Oct 4 '13 at 20:59
  • After some research found the DevModes2 key issue was related to support.microsoft.com/kb/2871131 and we did have the hotfix installed. However, the hotfix doesn't clean up the mess it apparently just keeps it from growing. When it comes to the Samsung SSPrint they are back growing after cleaning up. In order to get the registry down below the 2048MB we had to perform some registry hive cleanup (support.microsoft.com/kb/2498915). Now we're just monitoring and preparing to put servers in drain mode until we have a solution with the Samsung drivers. – Arachnid Oct 8 '13 at 12:42
  • @Archanid Interesting! How are you monitoring the situation? – pauska Oct 8 '13 at 14:34
  • 1
    NOTE for anybody else out there using Samsung Universal Print drivers and Windows Server 2008 R2 for Remote Desktop Session Hosting (RDSH). You will also experience registry bloat on individual user profiles. If you are using Roaming User Profiles you may experience issues where the registry will bloat to the point that a Registry HIVE load and Export is necessary with Group Policies defined to Delete SSPrint related keys. HKCU\Software\SSPrint\spe__ HKCU\Software\SSPrint\spd__ HKCU\Software\SSPrint\ssp6m The keys above refer to specific Samsung Print Processors used by the drivers. – Arachnid Feb 11 '14 at 19:37

I had the exact same issue and can confirm it is fixed in the new version of Samsung Universal Print Driver 2 (2.50.5) . I was also running 2.50.2 and the key in question was using 275MB. Simply uninstalling the old version and installing the new version on the server (I did not update any client drivers) reduced the size of the key to 3MB. I also tried logging on and back off and can confirm it now deletes the keys when you log off, unlike before.

If you're curious, before it would not delete the keys. In a single user environment this isn't a problem but since the printers are named for the user and the session, it is an exponential problem (for a 20 user server like mine you generate up to 400 keys... and that's if you only have 1 printer per client)

edit: the new key is called usp01 instead of spe__

  • JaredEpp, glad to hear Samsung managed to fix their issue. Perhaps, sad for Samsung we made a company-wide decision to not purchase Samsung printers due to this issue and have not purchased any since. I ended up making a number of Group Policy Preferences Registry Cleaners and some handy PowerShell scripts for loading Roaming User Registry Hives which then would clean and compress the users NTUSER.DAT files. – Arachnid Jun 3 '15 at 12:57

HP has this exact same problem. The issue is that the driver is not very smart when it comes to multiple users connected to the same printer mapping at the same time and it keeps trying to reinstall itself for each user. We never figured out exactly how to fix this, but we came up with two workarounds:

Solution A (easy fix but is a total hack)
Set the Windows Installer service to disabled. Stops the problem dead in its tracks. The downside is obvious though. As soon as you need to do an install or run updates, you must turn the service back on and the registry will immediately begin swelling again.

Solution B (ugly fix but is stable and supported)
Enforce the Remote Desktop EasyPrint driver via Group Policy. This makes print jobs render on the clients instead of the server. The downside here is that you will then need to manually remove every user's printer connection from every printer on every server in the farm, and then delete the drivers. I hope you're good with scripting!

  • Have you tried installing the driver in terminal services installer mode? At the command prompt, type change user /install and then install the drivers. Then type change user /execute to return to regular user mode. support.microsoft.com/kb/320185 I'd really like to know if that works. – Thomas May 29 '14 at 16:06
  • The drivers don't get installed that way. They get pushed by the print server when a user connects to a particular printer so there is no changing the execution mode. Even aside from that, HP's driver is still wonky even on workstations. If you look at your registry, under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations, there's almost always something there from HP. Just FYI, that key is used by installers to delete/modify system files on the next reboot. HP's driver is always trying to do something. I just wish I knew what it was. – Wes Sayeed May 29 '14 at 20:47
  • I see, you're using a print server. The OP is using RDS, so setting installation mode might make a difference in his case. – Thomas May 30 '14 at 5:29
  • From my experience, the Remote Desktop EasyPrint is not much of a solution for anybody using a non-Windows RDP Client such as a WYSE OS Thin Client. Because of this limitation we have actually completely stayed away from Remote Desktop EasyPrint as it just will not work in our environment We deploy the printers via Group Policy Printer Connections (User Configuration Level) {Deployed Printers in Print Management}. Some research was done to change this to use Group Policy preferences but the targeting/testing of users for each site has not been completed. – Arachnid Jun 10 '14 at 13:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.