"Windows cannot unload your registry file."

  • Thread starter Thread starter JG
  • Start date Start date
J

JG

In my even viewer I'm getting:

Source: Userenv
Event ID: 1000
Usert: NT AUTHORITY\SYSTEM

Windows cannot unload your registry file. If you have a roaming
profile, your settings are not replicated. Contact your administrator.

DETAIL - Access is denied, Build Number ((2195))


This is on a Win2K server sp3 running Terminal Services.
 
Go to www.eventid.net and look up error 1000 userenv. You'll see you're not
alone. Read through the suggestions to see if any apply/help. If no joy
there--this is one of the most persistent and annoying and hard-to-resolve
problems in all of MS's post-NT4 OSes--email (e-mail address removed) and ask
for a copy of UPHCLEAN.EXE. This free utility installs a service that will
close the open handles that are stalling the registry unload. It also may
help you identify the problem.

GaryK
 
Gary said:
Go to www.eventid.net and look up error 1000 userenv. You'll see
you're not alone. Read through the suggestions to see if any
apply/help. If no joy there--this is one of the most persistent and
annoying and hard-to-resolve problems in all of MS's post-NT4
OSes--email (e-mail address removed) and ask for a copy of
UPHCLEAN.EXE. This free utility installs a service that will close
the open handles that are stalling the registry unload. It also may
help you identify the problem.

GaryK
Click to expand...

Thanks Gary. Since this mentions roaming profiles, do you think it
would cause terminal server clients problems connecting each time?
 
The problem is with the Spooler service, SPOOLSV.EXE.
Here are the two most likely scenarios:

-- Microsoft released a post-SP3 security patch (see article
Q329170 in their technical database) that caused this issue.
If you're on SP3, either uninstall the Q329170 hotfix, or
apply SP4, or simply expand & copy SP4's version of
SPOOLSV.EXE into your SP3 installation:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q814770

-- Microsoft released another security patch (post-SP4)
dealing with Terminal Services that caused this issue once
again, and they released yet another version of SPOOLSV
to address it. See:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q828153

Rick
 
I couldn't say about Terminal Services; don't use it. Some of the related
entries in EventID mention TS, so there's probably some useful info there
for you. However for diagnostic purposes, TS can help when using OH.EXE
(referenced in EventID). OH (Open Handles) is a downloadable, MS
resource-kit utility that will identify the handles that don't close at
logoff and that thus prevent the registry from unloading. Using TS allows
you to have two sessions logged on at once, so OH remains active when you
log off one of the sessions and thus keeps monitoring/recording the open
handles. There's quite a lengthy description of how to do this in the
EventID entry (which, because of how common this issue is, has gotten really
long).

Rick has suggested that the problem is caused by the Spooler service, and
apparently turning off/fixing the spooler does clear this up for some, but
it didn't solve the problem in my case. In my case, the problem was caused
by AWHOST32.EXE, which is the pcAnywhere Host-service executable.
Ultimately, after trying for months to solve this, I was able to identify
the problem only with Robin Caron's UPHCLEAN.EXE. UPHCLEAN would have
allowed the unloading of the registry, but after putting so much time/energy
into this, I wanted to try to actually solve the problem. As Symantec wasn't
going to fix its software, the solution I came up with was to create
SHUTDN.BAT . This uses SHUTDOWN.EXE to stop and/or restart the server, but
first it stops the pcAnywhere service (NET STOP "PCANYWHERE HOST SERVICE").
Once AWHOST32.EXE is shut down, the registry unloads just fine.

GaryK
 
Gary Karasik said:
Rick has suggested that the problem is caused by the Spooler service, and
apparently turning off/fixing the spooler does clear this up for some, but
it didn't solve the problem in my case. In my case, the problem was caused
by AWHOST32.EXE, which is the pcAnywhere Host-service executable.
Ultimately, after trying for months to solve this, I was able to identify
the problem only with Robin Caron's UPHCLEAN.EXE. UPHCLEAN would have
allowed the unloading of the registry, but after putting so much time/energy
into this, I wanted to try to actually solve the problem. As Symantec wasn't
going to fix its software, the solution I came up with was to create
SHUTDN.BAT . This uses SHUTDOWN.EXE to stop and/or restart the server, but
first it stops the pcAnywhere service (NET STOP "PCANYWHERE HOST SERVICE").
Once AWHOST32.EXE is shut down, the registry unloads just fine.
Click to expand...

Gary, it's probable that the error is not in Symantec's software.
This issue was reported from a wide range of third-party
developers, from Citrix to Novell, and is a result of errors in
Microsoft's code (SPOOLSV.EXE).

Rick
 
We were having the same problem.

We had call Microsoft for two patches:
KB828153
KB827825

Then we were also have a very slow logoff issue when logging out of a Citrix
ICA session. The logoff would sit on wlnotify.dll for a long time and then
finally save the user roaming profile.
KB828326 fixed that issue.

Even after this, there are a few accounts that still have problems where the
registry hive is not unloaded. We're still searching for the answer.

Dwayne
 
Hi,

I know this is asking for much but our company has been experiencing
the same problem for the past month. A lot of attempts have been made
but no luck. Is it possible I could get those patches off of you?
Hopefully this will reduce our call volume pertaining to this
particular problem. Want to say thank you very much in advance for
this.
 
Back
Top