Our company is in the middle of deploying Terminal Services 2008 R2, however i have noticed that our TS Users profiles do not get removed from local Terminal Server at user logoff.

Now im aware that this is something to-do with a process holding onto a connection to the registry at logoff (or words to that affect).

so i cleared the TS event log logged in as the user, logged out as the user and this event was left in the registry.

Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards.

DETAIL - 2 user registry handles leaked from \Registry\User\S-1-5-21-1145379511-113177986-563163613-1483: Process 968 (\Device\HarddiskVolume2\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-1145379511-113177986-563163613-1483\Printers\DevModePerUser Process 872 (\Device\HarddiskVolume2\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-1-5-21-1145379511-113177986-563163613-1483\Software\Microsoft\Internet Explorer\LinksBar

Now im still fairly new to Terminal Services and its finer bits, however i have no real idea what i should be doing with this error message, google provides some info on the problem but no specific reason for it or cure.

i can see that something within IE's Linkbar is one of the issues and what i can guess is a printer, but neiter error is more specific about what went wrong.

thanks Kris

  • Is the TS server a VMware guest by any chance? – joeqwerty Nov 2 '11 at 17:12
  • yes, the terminal server is running within VMWare VSphere 4. – Kristiaan Nov 2 '11 at 17:14

If you have the Shared Folders component of VMware tools installed then that's what's probably causing the problem. I ran into this as well. Remove the Shared Folders component and that should fix it.

  • Exactly the problem, whilst im aware from other posters above there are other programs and apps that can generate this issue, after uninstalling the VMware Tools component the problem resolved itself. i found that on a "Typical" install of Vmware Tools it does not add the shared folders component so its possible to have the tools without the component that generates the problems. – Kristiaan Nov 3 '11 at 9:38
  • Glad you got it resolved. I've taken to making sure the Shared Folders component of VMware Tools is not installed on any of my VMware guest machines, regardless of their roles. – joeqwerty Nov 3 '11 at 11:24

You need to research the root cause of each handle leak and fix them individually. Find out which service is holding each of the two keys open. Use the Process ID as starting point. In one case maybe a specific printer driver is causing the leak.

Try to disable the offending process/funtionality and check whether that makes the symptoms go away.

Sorry I cannot be more specific - this is detective work.

  • thought of this one :) i have used process monitor to look at the two pid's it mentioned and there both SVCHOST processes that are running between them a large amount of fairly important (some would say) critical windows services. @Helge Klein to give an example pid id 872 is running the following services. winmgmt wuauserv SessionEnv ProfSvc LanManServer IKEEXT GPsvc CertProSVC AeLookupSvc the other process id is no longer running within the list. – Kristiaan Nov 2 '11 at 17:15

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.