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

  • From: "M" <mathras@xxxxxxxxxxxxxxxx>
  • To: <thin@xxxxxxxxxxxxx>
  • Date: Wed, 2 Jul 2008 23:21:17 +0100

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@xxxxxxxxxxxxx 
  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 15th may 
@ 04.28  - how hot off the press is that J

   

  From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf 
Of Rick Mack
  Sent: 15 May 2008 11:32
  To: thin@xxxxxxxxxxxxx
  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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx> wrote: 

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

Other related posts:

  1. Home
  2. thin
  3. Archive
  4. 07-2008