[THIN] Re: usrclass.dat not giving up the ghost - taking out servers, driving me nuts

Did you ever sort this issue out ? If so what was the fix ?

 

If not MS have released a new private hotfix that may assist

 

http://support.microsoft.com/kb/944984/

 

M

----- Original Message -----

From: Andrew Wood

To: thin@freelists.org

Sent: Thursday, May 15, 2008 11:52 AM

Subject: [THIN] Re: usrclass.dat not giving up the ghost - taking out servers, driving me nuts

Ah, we'll put it down to 'and another thing..'

 

Thanks for all the responses people – I'm not sure that its AV related as i've run a server without the AV client on and it still happens.

 

That looks a useful utility Rick – I'll give that a whirl - released 15^th may @ 04.28  - how hot off the press is that J

 

From: thin-bounce@freelists.org [mailto:thin-bounce@freelists.org] On Behalf Of Rick Mack
Sent: 15 May 2008 11:32
To: thin@freelists.org
Subject: [THIN] Re: usrclass.dat not giving up the ghost - taking out servers, driving me nuts

 

Hi,

 

This is sad, replying to myself. However there's a free utility just released that might do the trick for you.

 

Check out http://www.tescitrixoupas.net/index.php/2008/xenapp-server-maintenance-oorium-sessions-cleaner/

 

regards,

 

Rick

 

--
Ulrich Mack
Quest Software
Provision Networks Division  


 

On 5/15/08, Rick Mack <ulrich.mack@gmail.com> wrote:

Hi Andrew,

 

Sounds pretty good to me :-)

 

usrclass.dat is the per-user file extension part of the user's profile or what you see in the registry under HKCU\Software\Classes. Under HKEY_USERS, you'll see a bunch of %usersid% and %usersid%_classes keys and %user%_classes corresponds to the user's HKCU\Software\Classes hive.

 

The classic symptom is that when you run up regedit, you'll see ophaned %usersid%_classes keys with no corresponding %usersid% key. Depending on the scenario, which is often just a timing issue because the o.s and uphclean gave up unloading the hive, you can select the orphaned hive and select file > unload hive from the toolbar and voila it's gone. You should then be able to delete the profile folder without a reboot.

 

You see, most times it's not the file that's being held open, it's a registry hive that hasn't been unloaded. When you can't unload the HKCU\Software\Classes registry hive, and it is a separate hive, then you'll end up with an open usrclass.dat file under %userprofile%local settings\application data\microsoft\windows.

 

Anyway, as to why this happens, there are any number of causes from over exuberant virus checkers to Microsoft security hotfixes that have broken part of csrss yet again. Even UPHClean will give up eventually so it doesn't actually handle the orphaned usrclass hives either.

 

So your real problem is how to programmatically unload orphaned usrclass hives and get rid of the folders (and orphaned usrclass.dat) file and profilelist entries before the next user logon when you get multiple %username%.001 etc profiles piling up.

 

I haven't actually tried it, but the script at http://sogeeky.blogspot.com/2007/03/vbscript-unload-non-active-user-hives.html may handle the registry hive unload issue for you. The profile cleanup after the hive unload should be easy with the bomprof utility from http://www.ctrl-alt-del.com.au/CAD_TSUtils.htm. Run tyhe 2 together as an end of day batch job and things should be tolerable.

 

regards,

 

Rick

 

--
Ulrich Mack
Quest Software
Provision Networks Division  
 

On 5/15/08, Andrew Wood <andrew.wood@gilwood-cs.co.uk> wrote:

I'm going to give it another couple of days, then everyone is getting a pencil and a pack of post-it notes.