Why does explorer crash on Windows 2008 R2 RDP with an out-of-memory error?

Question

Seal

Full description of the problem - RDP server, HP Proliand DL386G6 with 64 gigs of installed memory. There are more than 200 users. They are constantly spinning back and forth. Things are good. They launch Open Office, Firefox and a local application written in Flex. Clients - motley thin clients from HP. Everything is going well, but with a certain periodicity, the next problem begins to fall out.
At some indefinite point in time, Explorer starts to crash with an error that there is not enough memory to run the application. (There is not enough free memory to run this program) while it does not allow you to open any folder on the desktop. When you try to get into the control panel, the same error occurs, but from :: 26ee0668-a00a-44d7-9371-beb064c98683 - which is understandable.
At the same time, if I call the context menu of the folder and open the folder through it, then everything works.
A quick solution to the problem - restarting the RDP server - is super stupid. The log shows interesting things:
EventID 1530
With every Log Off of any user, event 1530 appears, which says that windows detected your registry file is still in use by other applications or services
In detail, it says that svchost still keeps \REGISTRY\USER\ open *USER-SID*\Printers\DevModePerUser
EventID 7011
Two more services are also corrupted by log errors:
A timeout (30000 milliseconds) was reached while waiting for a transaction response from the netprofm service
This event goes hand in hand with the previous one.
And one more service that starts acting up is A timeout (30000 milliseconds) was reached while waiting for a transaction response from the fdPHost service
These two fellows spit into the log every 30 seconds. These errors start appearing exactly at the moment when explorer starts to crash. The rest is complete silence.
After deep googling, it seemed to me that the HP Universal Printer Driver is to blame for everything, which keeps the registry open (1530). In fact, I have 2 HP and one Kyocera installed on the server. All of them worked together under this universal driver. I said "what the hell?" and sawed out the universal driver, replacing it with the Universal driver for Kyocera and the updated universal driver from HP (one of the printers is as old as the world, only this universal works under it).
After that there were some changes. Earlier, when I tried to log in from the server, I got a warning that the Task Service Host (svchost) did not allow the computer to shut down and suggested that I force Logoff. Now this message is gone. But error 1530 still gets into the logs. Now from two drivers - from Kyocera and from HP.
At the moment, error 7011 does not appear. Only because explorer works fine. But after a couple of days, it will start to fall.
To be honest - the last time I updated this system was in November 2010. It is absolutely internal and has no connection with the outside world, so I scored (I just used the rule “It works - well, let it work for itself”) so maybe this is cured by some patch, but I did not find it.
Intensive googling showed me that something like this arose from Norton - but I don't have Norton. Moreover, I found some tips to close running applications, but with 18 gigs of busy RAM on a machine with 64 gigs, this does not seem like a solution to me.
I tried to log all users. It did not help - after entering, nothing changes.
As information, I myself do not disdain to sit under RDP from the admin account.
Any ideas how to catch it?

Answer 1

My first rule is that all servers must be updated regardless.
There was a farm RDP 2008R2, 1C, an office, a printer - a lot and different, there were no leaks

Answer 2

As comrade Yushchenko said: "For the sake of showing up for new software security, don't fool yourself."

Answer 3

I always immediately install User Profile Hive Cleanup Service
on terminal servers . Event 1530 itself constantly has it from the User Profile Hive Cleanup Service, but they do no harm.
I suspect that they may be due to the transfer of local printers to the terminal session

Answer 4

Catch - silently. An obvious resource or memory leak. Take guides (for example, from Russinovich) and look.
In more detail, unfortunately, I will not prompt.