Registry not unloaded at logoff

[Mike]

I am having a problem which is described in Knowledge Base
article 319909. When I logoff it takes a very long time.
There is an error posted in the Application event log that
the registry can not be unloaded. I am running Win2000
Advanced Server. The Knowledge Base article states that
this was fixed in Win2000 SP3. However, I have Win2000
SP4 and I am still seeing the problem. I have checked the
file properties of Activeds.dll and they are as follows:

version: 5.0.2195.6601
size: 182032 bytes

 

[Jack]

Mike,

I can't suggest a solution but I am having the same
problem, also under SP4 but on server and professional.

My scenario is that I am trying to use a VBScript file to
force a re-sorting of the Start Menu by deleting the

"HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersio
n\Explorer\MenuOrder\Start Menu" key.

The script works fine in as much as it sorts the start
menu. Unfortunately it causes the problem that you
describe and also causes guest user profiles to remain in
existence (which is somewhat logical under the terms of
the knowledge base article that you quote in your post).

The problem also exists if I use a .REG file to do the
same task under REGEDIT. Interestingly the problem does
not occur if I use Regedit in interactive mode (this does
not help me in what I am attempting to do).

The problem appears to be identical to that described in
the knowledgebase article except that the workaround does
not apply as the IPSEC service is active. I have noticed
that LSASS is a dependent service on RPC which is affected
by the BLASTER worm fix. I have removed the fix but it did
not help.

I am now considering removing SP4 as we have this in
common.

Please advise of any progress that you make in this regard.

Jack.

 

[Jack]

Mike,

Have worked my way back through this newsgroup back to
early June and there is a reference to this sort of
problem before. Again it is SP4 related. I have a feeling
that Microsoft may have done something in SP4 which
undermines the supposed SP3 fix. In my experience SP4 does
some strange things which are probably security related
but un-helpfull under certain circumstances.

Am going to try my script etc. on an SP3 system tomorrow
and see if it works properly. Do not know what what I will
do if it does though as I have 1700 computers to worry
about and I really want them at the latest SP level.

regards,

Jack

 

[Mark V]

Mike wrote in

I am having a problem which is described in Knowledge Base
article 319909. When I logoff it takes a very long time.
There is an error posted in the Application event log that
the registry can not be unloaded. I am running Win2000
Advanced Server. The Knowledge Base article states that
this was fixed in Win2000 SP3. However, I have Win2000
SP4 and I am still seeing the problem. I have checked the
file properties of Activeds.dll and they are as follows:

version: 5.0.2195.6601
size: 182032 bytes

MS has been "fixing" this problem for ages and ages. Each SP
promised to fix it. There was a pre-SP4 patch that actually
aggravated the problem (can't recall the KBA #).

One thing just to try. Stop the Spooler service prior to a shudown.
Sometimes that solves it.... Another cosmetic "fix" is to change
the retry value for saving the profile at logoff to a lower figure.
The default is 60 seconds.

In Group Policy
Local Computer Policy > Computer Config > Admin Templates > System >
Logon,
Maximum retires to unload...

 

[Mark V]

Mark V wrote in
[ ]

to change the retry value for saving the profile at logoff to a
lower figure. The default is 60 seconds.

That's 60 retries.

 

[Wayne]

You can edit the registry through the Group Policy Editor,
to force the machine to shutdown/restart after X seconds,
therefore quitting your registry unloading process.

Take the event ID number you are getting in the
application log and go to eventid.com. Do a search on the
event ID for more details.

 

[Jack]

Mike,

the posts I have seen so far should make your logoff time
quicker but dont solve the problem of actually saving a
connected users profile back to the server as intended by
Microsoft design. The server will therefore have an out of
date copy of the profile left on the client machine which
can cause problems later.

I am still looking to eliminate SP4 from this problem
scenario.

 

[Gary Karasik]

I've had this problem since pre-SP3 (so it's not--at least directly--SP4
related, Jack). There's a long series of reports on this at EventID.NET with
many suggested fixes.

http://www.eventid.net/advanceddisplay.asp?eventid=1000

I've tried them all. None works for me, but one of them might work for you.

There's a resource-kit utility called OH.EXE (which works in conjunction
with GFLAGS.EXE) that reports on open handles, and some people have figured
out how to use this to solve this problem. In my case, though it reports on
which handles are open, there's no indication which one isn't closing. It
does tell me that it can't unload the profile, but I already know that.

GaryK

 

[Mark V]

Gary Karasik wrote in

I've had this problem since pre-SP3 (so it's not--at least
directly--SP4 related, Jack). There's a long series of reports on
this at EventID.NET with many suggested fixes.

http://www.eventid.net/advanceddisplay.asp?eventid=1000

I've tried them all. None works for me, but one of them might work
for you.

There's a resource-kit utility called OH.EXE (which works in
conjunction with GFLAGS.EXE) that reports on open handles, and
some people have figured out how to use this to solve this
problem. In my case, though it reports on which handles are open,
there's no indication which one isn't closing. It does tell me
that it can't unload the profile, but I already know that.

[ ]

OH is a good tip and a tool for some users perhaps. I've found in
many cases that the same service (like Spooler) is responsible time
after time and that simply stopping it prior to shutdown or loggoff
works wonders. Now I'm not saying that will work in all cases or for
any given system or service, but testing it on various is worth the
effort. It also is not the desired solution which MS must address.

What I don't understand is considering the longevity of this issue
why MS or some third party has not written a driver or service that
can watch and record the problem during a logoff. Unless of course
there is one I've missed.

 

[Gary Karasik]

Turning off the spooler service does not solve the problem in my case.

And I too am surprised that there's no utility to record what is causing the
problem.

GaryK

Gary Karasik wrote in

I've had this problem since pre-SP3 (so it's not--at least
directly--SP4 related, Jack). There's a long series of reports on
this at EventID.NET with many suggested fixes.

http://www.eventid.net/advanceddisplay.asp?eventid=1000

I've tried them all. None works for me, but one of them might work
for you.

There's a resource-kit utility called OH.EXE (which works in
conjunction with GFLAGS.EXE) that reports on open handles, and
some people have figured out how to use this to solve this
problem. In my case, though it reports on which handles are open,
there's no indication which one isn't closing. It does tell me
that it can't unload the profile, but I already know that.

[ ]

OH is a good tip and a tool for some users perhaps. I've found in
many cases that the same service (like Spooler) is responsible time
after time and that simply stopping it prior to shutdown or loggoff
works wonders. Now I'm not saying that will work in all cases or for
any given system or service, but testing it on various is worth the
effort. It also is not the desired solution which MS must address.

What I don't understand is considering the longevity of this issue
why MS or some third party has not written a driver or service that
can watch and record the problem during a logoff. Unless of course
there is one I've missed.

 

[Adam]

I have this problem too. In my case it started when I
installed of SP4. Everything was fine with SP3. I tried to
reinstall SP3, but the problem persists.
Any insights are appreciated.

Adam

-----Original Message-----
Turning off the spooler service does not solve the problem in my case.

And I too am surprised that there's no utility to record what is causing the
problem.

GaryK

Gary Karasik wrote in [email protected]:

I've had this problem since pre-SP3 (so it's not--at least
directly--SP4 related, Jack). There's a long series of reports on
this at EventID.NET with many suggested fixes.

http://www.eventid.net/advanceddisplay.asp? eventid=1000

I've tried them all. None works for me, but one of them might work
for you.

There's a resource-kit utility called OH.EXE (which works in
conjunction with GFLAGS.EXE) that reports on open handles, and
some people have figured out how to use this to solve this
problem. In my case, though it reports on which handles are open,
there's no indication which one isn't closing. It does tell me
that it can't unload the profile, but I already know that.

[ ]

OH is a good tip and a tool for some users perhaps. I've found in
many cases that the same service (like Spooler) is responsible time
after time and that simply stopping it prior to shutdown or loggoff
works wonders. Now I'm not saying that will work in all cases or for
any given system or service, but testing it on various is worth the
effort. It also is not the desired solution which MS must address.

What I don't understand is considering the longevity of this issue
why MS or some third party has not written a driver or service that
can watch and record the problem during a logoff. Unless of course
there is one I've missed.

.

 

[Adam]

Had the same problem after installing SP4, seems MS goofs
reintroduced old problem pre-SP3 again. I tried revert to
SP3, but problem still persisted. Finnaly in act of
desperation I created new user with administrator access.
Suprisingly this fixed the problem. What is most spooky I
didn't have to swith to new account. Simply the fact of
creating one fixed the logoff problem for my current
account.

Adam

Nice to be able to switch off fast this piece of junk.

 

[Robin Caron]

Hi Mark,

I have written the service you mentioned: it monitors for the system
attempting to unload user profile hives and makes sure that any remaining
handles to those profiles are closed (if any). The system then proceeds to
unload the profile.

Anyone interested is welcome to contact me via email.

Gary Karasik wrote in

I've had this problem since pre-SP3 (so it's not--at least
directly--SP4 related, Jack). There's a long series of reports on
this at EventID.NET with many suggested fixes.

http://www.eventid.net/advanceddisplay.asp?eventid=1000

I've tried them all. None works for me, but one of them might work
for you.

There's a resource-kit utility called OH.EXE (which works in
conjunction with GFLAGS.EXE) that reports on open handles, and
some people have figured out how to use this to solve this
problem. In my case, though it reports on which handles are open,
there's no indication which one isn't closing. It does tell me
that it can't unload the profile, but I already know that.

[ ]

OH is a good tip and a tool for some users perhaps. I've found in
many cases that the same service (like Spooler) is responsible time
after time and that simply stopping it prior to shutdown or loggoff
works wonders. Now I'm not saying that will work in all cases or for
any given system or service, but testing it on various is worth the
effort. It also is not the desired solution which MS must address.

What I don't understand is considering the longevity of this issue
why MS or some third party has not written a driver or service that
can watch and record the problem during a logoff. Unless of course
there is one I've missed.

 

[Mark V]

Robin Caron wrote in

Hi Mark,

I have written the service you mentioned: it monitors for the
system attempting to unload user profile hives and makes sure that
any remaining handles to those profiles are closed (if any). The
system then proceeds to unload the profile.

Anyone interested is welcome to contact me via email.

Hi Robin,
Interesting and thanks. But first, I am looking for
_reporting/logging_ tool rather than a "fix" utility. Does your work
offer that?

 

[Robin Caron]

Robin Caron wrote in

Hi Robin,
Interesting and thanks. But first, I am looking for
_reporting/logging_ tool rather than a "fix" utility. Does your work
offer that?

It does report as it fixes.