This problem can occur if a handle to a registry key is not closed correctly. This "locks" the registry files so when Windows attempts to copy these files as part of the roaming profile synchronization process it fails (and this event is recorded). Several users have reported this problem as occuring after the installation of various software packages. In most cases, this indicates a bug in those applications.
One of the first steps to take in troubleshooting this problem is to install the latest service pack (currently that is Service Pack 4). We have received many reports on this problem being fixed after the installation of SP3.
In many cases, antivirus programs like Norton or McAfee were causing this error. Most of the users solved the problem by installing the latest patches or software version for the particular program.
Another software that seemed to cause problems to many users is TightVNC. Replacing it with standard VNC fixed this issue.
Some contributors recommended the use of the OH.EXE utility from the Windows 2000 resource kit to identify the application that locked the registry.
In our case, this happened on a W2K terminal server. We tracked it to a printer shortcut refering to a network printer that had been uninstalled. Deleted the shortcut and events stopped.
In one case, the problem was due to the existence of a C:\Documents and Settings\Default User folder that was not set up with the correct rights. While this folder had the wrong Windows NT rights, any non-Admin users that logged on for the first time created a profile that had this error. To resolve this, set up the Default User folder correctly and delete/re-create corrupt profiles.
for a hotfix applicable to Microsoft Windows Server 2003.
for a hotfix applicable to Microsoft Windows 2000.
for a hotfix applicable to Microsoft Windows 2000.
for a hotfix applicable to Microsoft Windows 2000 and Microsoft Windows XP.
If this happens when you start, quit, or log off Microsoft NetMeeting, see ME327612
for a hotfix applicable to Microsoft Windows 2000.
As per Microsoft: " This problem occurs because of a registry handle leak in Windows Installer. This problem was first exposed after the installation of the MS03-026 security update". See ME827825
for a hotfix applicable to Microsoft Windows 2000.
As per Symantec this problem can appear if "you are using Windows 2000 Terminal Server in remote mode and have installed NAV 7.6 Server on some servers, and NAV 7.6 Client on others. This problem has been resolved in Norton AntiVirus Corporate Edition 7.61 build 36". See the link to "Symantec Knowledge Base Document ID: 2001112714405148" for more details.
If closing Citrix published application takes nearly a minute, see the link to "Novell Support TID10094376" for details on fixing the problem.
See "Dealing with Unwanted Spyware and Parasites" if you have "Spyware" on your system.
We had a problem with Windows 2000 SP4 not unloading roaming profiles for 10 minutes after the logout was executed. If you have the SMS 2003 Advanced Client installed, uninstall the client using ccmclean.exe. This fixed for us the problem with the user profiles not unloading.
I had this event occur on a clean system as follows: Win2k Server, SP3, and all windows update patches. After thorough testing using system images, I was able to narrow down my particular problem to a payroll application, Millennium Payroll. On a clean system patched to SP3 level, after installing this app, it took exactly 60 sec for any user account to logoff. I fixed this by installing SP4 and have had no further problems.
As per Microsoft: "This problem occurs because Winmgmt.exe holds a handle to a registry key in the user's profile. Therefore, Windows cannot unload the user profile". See ME322656
for a hotfix.
As per Microsoft: "This issue may occur if Microsoft Windows or third-party programs such as printer drivers or virus scanners do not stop and release resources when you log off your computer". See ME837115
for more details.
Some instances of this problem can be fixed by turning on the IPSec Policy agent. See ME319909
I got this error on a Win2k Terminal Server that is a member server in a Win2k domain. I fixed this by removing the temporary profiles that Windows created. These were in the default profile directory. I deleted these all and the issue was resolved. Also giving the user temporary local admin rights allowed them to at least logon with a default profile.
I fixed this problem by updating my iTouch software from Logitech. They released a new Version in November 2003 that specifically fixes this problem. Before this update, it took minutes to log out of Windows. After installing the new Version 2.20, the logoff went fast again.
I had this problem with the GoToMypc client software. Uninstalling the software fixed it.
After a lot of research I found out that, it was the "Remote Access Connection Manager" that "locked" the registry file. This because I had VPN-connect over the internet installed in my profile and the new PC did not have a standard location configured. I resolved the issue by running the standard location guide that starts the first time you enter the phone and modem options on the control panel.
I had this issue on my Win2K SP3 machine, as soon as ME329170
security patch was applied. Instead of uninstalling the patch, I replaced SPOOLSV.EXE with SP4's version (5.00.2195.6659) and this fixed the problem. There appears to be a second SPOOLSV.EXE issue, related to another security patch (for Terminal Services), and yet another SPOOLSV.EXE hotfix was released by Microsoft to address this. See ME828153
for more details. Note that the often-repeated suggestion to change the registry retry count from 60 to 5 is not a fix, it just hides the problem.
I started receiving this event after I installed WinVNC. To fix this problem I stopped the VNC Helper Service from auto starting. I simply deleted the WinVNC key from "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run". To configure the VNC Server, you can manually start the VNC Helper Service from the Start Menu.
This showed up after I installed Power Chute Business Edition (PCBE) on a Win2K SP4 server but did not go away after I uninstalled PCBE. I was able to pinpoint the cause as "awhost32.exe" (pcAnywhere’s host executable). When I rebooted remotely, "awhost32.exe" was not letting the registry unload. I solved the problem by writing a simple ".bat" file that "NET STOPped" the pcAnywhere host service before it executes "shutdown.exe".
Quote from TightVNC 1.2.9 Release Notes: "Now the HKEY_CURRENT_USER registry hive is being closed properly on restoring display settings, on disconnect. This change should solve the problem with unloading the registry on logout, when WinVNC is running as a service". See the link below to TightVNC 1.2.9 Release Notes for more details.
Check out ME817171
- There is a post SP4 fix for this available from PSS, with specific regards to Terminal Servers.
I got around this error, when I enabled the Userenv logging, using article: ME221833
. From there I could see that the system was unable to read the ownership of the user’s profile. I got the user to log onto a system that was not affected by this problem and got him to browse to his profile and home folder and take ownership of them and of all subfolders and files. Then I logged onto the server that was experiencing the problem and looked in the document and settings folder. I found several temporary folders like "C:\Documents and Settings\TEMP.COILLTE.000". The security settings for these folders had permissions giving full access to those users affected. I deleted these files (you might have to do a clean reboot to be able to do this). Then I did a fresh reboot and everyone was able to log in fine.
I came across this problem after installing Visual Studio.Net Enterprise Architect on a Windows 2000 workstation with Service Pack 4. Debugging a program in Visual Studio would cause the machine to hang at shutdown, and would produce event 1000 Userenv errors in the Event Viewer. After reading some of the posts here, I was made aware that it was due to a registry key not being released before shutting down. To track down the program that was not releasing the key I ran the debugger in Visual Studio and logged out and back in as another user. Then by running "oh.exe -t key user" from the command prompt I could see that there was still a key open from the previous user that had run the debugger. It was “mdm.exe” that had not released the key a.k.a. machine debug manager. Stopping the "machine debug manager" service before shutdown releases the key and prevents the Userenv error. Therefore, I use a batch file that runs before logging off to stop the service. It reads NET STOP "Machine Debug Manager" I added it to Group Policy/User Configuration/Windows Settings/Scripts(Logon/Logoff)/Logoff. This is definitely not a fix but more of a workaround until MS comes out with a real solution.
The issue is that the "c:\documents and settings\" directory has the permissions changed by the installation of service pack 4 for windows 2000. Original install has the security permissions set to "allow inheritable" which in this case includes full control. Once service pack 4 is installed, the permissions are reduced to just R&E, list folders and read for the "everyone" group. This means that anyone trying to log in either as a new user or in particular as a user with a roaming profile that does not have administrative powers on the local PC cannot change anything, hence the local profile is not copied from the server. To fix this simply click the "allow inheritable permissions" at the root of c:\documents and settings\.
I called Microsoft about this problem, and I’m glad I did. It seemed that the problem started to occur around the same time we applied the MS03-026 patch on our terminal servers. When a user with a roaming profile attempted to logoff, their registry was being held by some program (who knows what) and it was unable to save it because it was being held. This resulted in the operating system attempting the save once every sixty seconds (explains slow logoff) and then ultimately failing and not updating the roaming profile. The solution (workaround actually) comes in the form of a service that runs non-stop called "User Profile Hive Cleanup" which waits for the event when a user attempts to logoff, sees the problem with the registry, forces the release of the registry, resulting in a successful logoff event. Suddenly the Userenv entry becomes an informative entry instead of an error.
In a Windows 2000/Citrix Metaframe environment, this issue is caused by the 2 RPC Hotfixes: MS03-026 and MS03-039 (Blaster worm fixes). There were 2 articles that addressed this new issue: ME827825
. Some users have reported mixed success. As of now (9/30/03) these 2 articles are not available, but the hotfixes are by calling Microsoft. More details on Citrix's forum.
As the event 1000 was logged I did nothing but deactivate Norton Antivirus 2001 and restart the computer. After that I could activate Norton again and the event disappeared forever.
We have 2 Windows 2000 servers running Terminal Services in Application Mode and Citrix Metaframe XPa. Our users login and load a roaming profile stored on a 3rd server. When logging in for the first time, we run a script that checks to see if a profile is present, and if its not, it copies one from the current session and a set of items from a "standard" profile based on the users Group membership. We noticed that when new users where logging off for the first time this message "Cannot unload registry file" was generated. We have Symantec Anti-Virus Enterprise 8 client installed on both servers, and Microsoft in ME329718
they mention that AV 7.5 may cause this issue. A call to Symantec revealed that on the "Client Realtime Configuration" settings, if you have "Network" selected (Along with Floppy and CDROM) in this type of environment, could cause this error. The event is generated when the user is trying to unload something to their roaming profile and at the same time SAV was scanning these files/pipes. Turning off the Network check box in "Client Realtime protection" from the "Symantec System Console" was the fix for us.
Kyocera KX Printer Drivers can cause this problem as mentioned above. The drivers cause csrss.exe to leak two handles into the user portion of the registry, and hence the registry hive cannot unload when the user logs off.
The following versions definitely cause the problem:
KX Drivers v1.9.1025
KX Drivers v2.0.0326
The following versions fix the problem:
KX Drivers v2.1.0616 (released on 4th Sept 2003)
PCL5e mini drivers (released on 26th March 2003)
A few notes for those who haven't used oh.exe before (as I hadn't before getting this problem). First install oh.exe on the server from the Windows 2000 resource kit. If you don't want to install the whole resource kit on your server, install on a workstation and simply copy oh.exe from the workstation into the system32 directory on the server.
First, type "oh" at a command prompt to switch on diagnostic logging in the kernel. Reboot the server, you cannot use oh until you have done. Now, at any time on the server you can type "oh -t key user" to produce a list of open handles to the user portion of the registry. It can be a very long list so consider directing output to a text file e.g. "oh -t key user > oh.txt"
To find the application that is causing event 1000, get ready to run oh.exe on the console of the server and then get a problem user to log out. When the users gets the "Saving your settings..." message and it hangs there, run oh.exe on the console before they get logged out. This is easier said than done if it is an intermittent problem as you don't know if the use will get the problem of not.
Examine the output of oh.exe and look for any registry handles left open for the user in question. The oh.exe output refers to users by their internal ID rather than by name (eg. S-1-5-21-1231423735-1728518174-1221738049-1285). To work out which user is which, run regedit while logged in as the user in question, add a string value to HKCU with their name in it, then look in HKU and find the matching string value listed under one of the user keys. You will now be able to search on the internal reference of the user and find what process is causing the problem. This might help immediately, for example if "winvnc.exe" has the open key you know it is VNC causing the problem. If it is a system process such as csrss.exe, you'll have to dig further to find what is causing the problem, could be printer drivers etc.
If oh.exe takes too long to run (it can take a few minutes on a loaded terminal server), you won't be able to run it during the 1 minte that the user logout is hangin. Increase the amount of time you have by using gpedit on the server to alter the number of re-tries up from 60 to say 600. This will give you ten minutes, while they are hanging at the "Saving settings..." message, for you to run oh.exe.
The problem caused by installing the Microsoft security update ME329170
(MS02-070: Flaw in SMB Signing May Permit Group Policy to Be Modified) can be fixed by installing Windows 2000 Service Pack 4, which includes the ME814770
When running from a terminal services session (doens't matter if it's ICA or RDP, nor if the user has a local vs. roaming profile) webfldrs.msi cannot install. When a new profile is created, upon first logoff webfldrs.msi attempts to install. The logoff process takes 30 seconds or longer and the above Event ID appears in the application log.
This is apparently a bug that MS is working to fix. There are three workarounds:
1. Log each user in and out of the console when creating a new profile
2. Rename %systemroot%\system32\webfldrs.msi to webfldrs.old
3. Disable the Windows Installer service
Not sure when MS will fix the problem permanently, but webfldrs.msi only provides the funtionality to save Office files as FrontPage items so renaming the MSI doesn't seem to affect much user functionality.
After reviewing several posts with this error, it looks like several different MSI packages can cause this error. In our case it was corrupting user profiles on a Terminal Server so it was a BIG deal. Although many different MSI packages can cause this, the workarounds should be basically the same.
I recently figured out what was causing my slow logoff and giving me the Event id 1000 USERENV error. After installing PCAnywhere 10.5, I installed the patch to bring it upto 10.5.1. The patch is what caused the error. I am now removing PCAnywhere, to reinstall it without the patch. This is only for W2K server. It works fine for NT 4 server.
I, and others, are working with MS on this one [..] Have you disabled/stopped any default services? Is your "Documents and Settings" folder in the canonical place. I can reproduce the problem right after a restart by simply starting/stopping the NetMeeting client (CONF.EXE, no connection necessary) and then logging off. I have read about others reproducing it by using Netscape, Office 2000, etc... The problem is with two registry files, UsrClass.dat and UsrClass.dat.log (buried in one's profile directory) which the system process always has open and which (here at least) never contain any data. They can't be "unloaded" at logoff, and remain open even after another user logs on (hence the two "leaked" handles reported in %SystemRoot%\Debug\UserMode\userenv.log (there you see that the minute delay at logoff is caused by the system trying once per second for a minute to unload those files).
Some of these problems should be fixed by SP4. See ME285192
for more information.
Not a fix, but here's a workaround that worked in my case: Open the MMC and add the Group Policy snap-in, then open the Group Policy editor. Go to computer Configuration/Administrative Templates/System/Logon and find the policy "Maximum retries to unload and update user profile." Do not click "Disable" nor "Not Configured" as that just will use the default of 60. Rather, lower the number of tries to unload downward from 60. I figured, "If you can't unload it, don't bother trying", so I set mine to 0 and shutdown is (finally!) instantaneous once again.
I was getting the same error on a Windows 2000 Advanced Server. The error was being generated every 2 minutes so I looked at the scheduled tasks and there were a couple of tasks that were running every two minutes. All of them were running under a local admin account and one of them was running under a domain account. I disabled all of them and started each of them to narrow down on the error and the service running under the domain account was the one generating the errors. The domain account was valid (had not expired or been disabled) and I could login using that id on a test machine. I deleted the profile (use the utility delprof from the 2000 resource kit) on the server and started the scheduled task. It started generating the errors again at the 2 minute interval. So I deleted the profile off the domain controller (and local copy from the server) and this time it fixed the problem.
We had the same problem and the pre-SP4-hotfix did not work. Our problem occurred when users were printing. We changed the print drivers and the problem dissapeared.
I had this message on a Windows 2000 member server operating in an NT4 domain. I was able to resolve it by deleting the local Administer profile on the server, logging back on as local administrator and having the profile recreated. Rebooted the machine and the error has not reappeared.
I was receiving this error message on a terminal server every time a user was logging on after we had changed our secondary DNS server and tried ipconfig /registerdns from the command prompt. This then stopped these errors once it had re-registered itself.
Received this error (and Error No. 1001, SceCli) after installing a second NIC. This card was connected to the LAN hub but had autogenerated an IP in the 169.x.x.x range. When we disabled the card, the error messages stopped.
I this problem on a number of W2K computers, I discovered that by "sharing" an installed printer on all of the systems the the problem disappears. I have done this on 6 systems that were plagued with this issue and all 6 were cured. One final comment, I installed a driver for an HPLJ4 on some of the systems even though the printer was not even present, shared the driver and the problem vanished.
I was having this same problem, and referenced the mentioned Knowledge Base articles but I have windows 2000 SP3, so the problem should have been corrected. Through persistence and through a lot of digging, this is what I found, hopefully it will help someone else.
I recently set up a small home network with an SMC wireless router, with a workgroup consisting of a W2K Professional SP3 (mine), and an XP SP1 (roomates, which has an HP Laserjet 1200 printer attached to it). The past month has consisted of a lot of "tinkering" with my computer (the W2K) including a lot of uninstalling and installing of different apps and playing around with the network in an effort to learn more about networking.
Using oh.exe (one can get it from Microsoft) I found that the spoolsv.exe process was the one that was holding onto the HKey_users keys and that it was Userenv that was behind the opening of the keys:
000001D4 spoolsv.exe Event 00c4\BaseNamedObjects\userenv: User Profile setup event
000001D4 spoolsv.exe Key 00d8\REGISTRY\User\S-1-5-21-1417001333-1
I found that if i disabled the spooler service the problem did in fact go away, but obviously this is not a viable solution for most networks. I later came across ME327984
which showed this being a known problem for W2K SP3 as well, but that the fix was to be only for those who have this specific problem and could be obtained by contacting support for the fix. On a whim, I checked the versions of the files on my system, which the article mentioned as being in need of an update, and found them all to be later versions than the mentioned versions. I sorted the winnt/system32 folder by "modified date" and found all of the files in question as modified on 11/01/02, which was also later than the date mentioned in the article. The thing that really caught my eye was that directly above this "group" of files was another "group" with a modified date of 11/01/02 but 5 hours later. This group contained non-other than than the userenv.dll. Turns out I had done a Windows update on 12/19/02 which included both ME328310
(related to a profile security flaw) and ME329170
(related to copying files from an xp client to a win2k server). This was also the date that the problem began showing up in event viewer. Windows update installation history, showed ME328310
as being installed after ME329170
, so I decided since it was probably a good idea to reinstall these, perhaps installment order was a factor. I uninstalled them in reverse order of installment (as to backout the changes that were put in on top of one another) and reinstalled them, this time in sequential order per Q number. While the order may have nothing to do with it, I will note that the event viewer shows a Userenv 1000 for the reboot after uninstalling ME328310
, another 1000 for the reboot after unistalling ME329170
, but then a clean reboot after installing ME328310
and a clean reboot after installing ME329170
, and no more userenv 1000s since. I have yet to copy files from the XP to the W2K, or to play around with the printer settings to see if the problem begins again, but at least this is a step in the right direction and may help someone else.
We received this error for two reasons:
1) We are running a software distribution program called "Cognet". The service was trying to receive updates from the Cognet server during logoff. As a result, the machine was timing out (Default of 60 seconds) during the attempt to update the server copy of the roaming profile.
2) We are running EPO Agent for Mcafee antivirus. If the update was taking place during the logoff, which it was set to do (when idle), then we recived the error. The system waited 60 seconds, and did not update the server copy of the roaming profile. We have rectified the EPO agent and also the Cognet service to try to ensure that these processes will not interfere with the roaming profile update.
I found that stopping the spooler service before logging off "fixed" the taking a long time to log off problem. This problem affects every Windows-updated Windows 2000 SP3 machine I have seen recently. Things that seem related: Symantec/Norton Anti Virus Corporate 8. Spooler Service. Service Pack 2 and 3. Update ME329170
. This problem is new, and persistent (as of late Jan 2003).
A fix for me was to: Use gpedit.msc [Group Policy Editor], add a logon and logoff script to the user policy, \WINNT\system32\GroupPolicy\User\Scripts\Logon [Logoff]. How-To and documentation on writing cmd/batch scripts for this purpose are fairly easy to find.
Here is the file:
1 – logon – netstartspooler.bat
net start spooler
2- logoff – netstopspooler.bat
net stop spooler /y
(/y is an undocumented net switch that will shut down a service and all the services that depend on it without prompting)
As per Microsoft (ME327984
), "A supported fix is now available from Microsoft, but it is only intended to correct the problem that is described in this article."
All recently encountered instances of this error have been caused by the application of ME329170
. Removal of the hotfix has resolved the error in virtually all client installations experiencing the problem.
In my case, I have found a way to solve this problem. I first experienced the problem in joining a server to a different domain. I installed SP3 and this solved the problem. The problem resurfaced again today on the same server and it caused my fax service to fail. To solve the problem I had to boot into safe mode. I then copied the contents of the offending profile before deleting it.
I have also experienced it on 2000 Pro. I have a user that has a laptop and is switching to a desktop. I was preparing the desktop under their login. The user was using the laptop at the same time. This caused the problem since I am redirecting My Documents and Application Data. I had the user shut down the laptop. I then deleted the profile and started again. This solved the problem.
I´ve got that event on several W2K machines in an complex metaframe XPe environment with many 3rd-party Software installad in the domain. After many hours I found the originator of the problem in the installed 3rd-party driver of the Kyocera-Mita printer. In fact all Kyocera-Mita driver with an "KX" extension after the model name causes this event. I´ve installed the "normal" PCL-driver, available from the Kyocera site and anything works fine.