Page 4 of 9 FirstFirst 12345678 ... LastLast
Results 31 to 40 of 84

Thread: Spybot 1.6 locking user registry hives

  1. #31
    Junior Member jjjdavidson's Avatar
    Join Date
    Jan 2007
    Location
    Central USA
    Posts
    27

    Default Getting back to a user profile

    For future reference, here's how you can use the registry editor to reset your profile path. This works if Windows created you a new profile because your old profile was locked up for some reason, not if your old profile was actually corrupted.

    Start REGEDIT while logged on your administrator account (don't use "Run as" from your regular account) and look at the key,

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

    Each key under ProfileList corresponds to one of the internal system security IDs (SIDs) that Windows assigns to accounts. The short ones are internal Windows functions; the long ones are actual users. (The long one ending in -500, for instance, is the default administrator account.)

    Under each SID key is the string value ProfileImagePath, which gives the actual disk path to your profile folder (files, desktop, shortcuts, personal documents, and so on). Skip through the SID keys until you find one with ProfileImagePath pointing at your newly-created profile, and carefully change the path to point back to your original profile. (Don't change the "%systemroot%" string to "C:".)

    If your old profile wasn't actually corrupted, it should come up normally the next time you log on your regular account.

  2. #32
    Junior Member jjjdavidson's Avatar
    Join Date
    Jan 2007
    Location
    Central USA
    Posts
    27

    Default

    Quote Originally Posted by PepiMK View Post
    There's a simple command line parameter to suppress the loading of user hives: /nouserhives.
    On machines with Terminal Services, this is even the default.
    PepiMK, just what are "machines with Terminal Services"? I posted a couple of weeks back about how some of my computers were failing to open the limited user hives. These are plain Windows XP workstations, nothing special that I'm aware of.

    The /nouserhives parameter isn't listed on the FAQ page for command line parameters. Is there a syntax to suppress the option when it's already the default? (I already tried /userhives and /allhives; neither one of them worked.) At the moment I'm using a batch file that manually loads all the user hives into HKEY_USERS before I run Spybot.

    Thanks! Jay

  3. #33
    Member
    Join Date
    Oct 2007
    Posts
    55

    Default

    Hi PepiMK,

    Thanks for checking in on this one. Ok here is the deal. I am aware of the /nouserhives switch but that is avoiding the problem. If you use the /nouserhives switch then you must scan for all user accounts. This is a step back in time to older versions of Spybot. This is a tricky problem because it seems to be intermitent. However I have figured out how to reproduce the problem every time. More on how in a moment.

    To answer your question, there is no error message generated when Spybot terminates normally and does not unload the other user hive(s). This means you must not be checking the return status when you unload the hives as the unload is clearly failing. Once this problem occurs a reboot will not correct the problem. I do not no why but others in this thread also agree that a reboot does not unload the hive(s). This is evident when Windows loads a temporary profile. I have not been able to reproduce the hive(s) sticking after a reboot. However here is how you can get the hive(s) to not unload every time.

    1. Run Spybot from an account with Admin priv's. This will load all the other user
    hive(s) under HKEY_USERS.

    2. Run Regedit and open HKEY_USERS. The locate one of the user hive(s)
    PE_C_accountname. Open the hive up and highlight any key in the hive.
    I highlighted the Console key.

    3. Now close Spybot normally via the red X or File Exit.

    4. Refresh the Registry Editor by View Refresh. You will see that the
    PE_C_accountname hive that you had open is still there.

    5. To remove the hive highlight the PE_C_accountname and select File
    Unload Hive... in the registry editor.

    So what does this mean. When you have the hive open with the registry editor you have opened a handle on the key you have highlighted. With this handle open on the hive, Spybot can not unload the hive. So how does this happen under normal operation of Spybot. If Spybot leaves a handle open after a scan in one of the PE_C_accountname hives, then the unload will fail on that hive. Leaving a handle open is called leaking a handle.

    As I stated earlier, Spybot must not be checking the return status of the call that unloads the user hive(s). This needs to be corrected. The code also needs to be checked to ensure that every handle that is opened gets closed. The only mystery to me is why a reboot does not clear the stuck hive(s). I tried a reboot with the hive stuck and sure enough it was cleared on reboot. However two of my clients machines would not clear after reboot along with several others in this thead. I hope this will help clear up this serious problem. Thanks for your support...
    Last edited by MrGreg; 2008-09-23 at 01:18.

  4. #34
    Junior Member
    Join Date
    Jun 2008
    Posts
    8

    Default

    Quote Originally Posted by PepiMK View Post
    @MrGreg: haven't seen this thread before, sorry!
    There's a simple command line parameter to suppress the loading of user hives: /nouserhives.
    On machines with Terminal Services, this is even the default.

    As for the reboot, I have to agree with jjdavidson that loaded hives do not persist over reboots.

    @Tivon: if you schedule scans you don't want te interrupt login processes, simply use /nouserhives.
    May I suggest another reg tweak to FORCE this option (/nouserhives) for those who are now leary about this potentially toxic problem?

    Simpler to globally turn off the global user scan until a satisfactory resolution is at hand than to risk a corrupted system! Since the whole purpose of S&D is to PREVENT corruption, any hint of damage to a user's system should be avoided at all cost!

  5. #35
    129260
    Guest

    Lightbulb @ PepiMK...

    Do we have any more info on this problem yet? Just wondering!

  6. #36
    Member
    Join Date
    Oct 2007
    Posts
    55

    Default

    Hi 129260,

    I am still waiting on PepiMK to respond to my latest post. I have tried to send him a PM but his box is full. I sent spybotsandra a PM asking her to contact him about this so I hope she will. If you no how to get a hold of him please do. Thanks..

  7. #37
    Member of Team Spybot PepiMK's Avatar
    Join Date
    Oct 2005
    Location
    Planet Earth
    Posts
    3,601

    Default

    @n2fc.: tweak added, won't be available until next version after 1.6.0 though (obviously ). But how would you define a "satisfactory" solution?
    @MrGreg: ah yes, my inbox always fills up faster than I can answer topics, that's probaly never going to change


    Hmmm... well, yes, if you manually open a handle in that hive, it is still in use, right. There are no memory leaks in the scanner I'm aware of though (we use special tools to test for them, and due to registry access capsulated in objects everywhere, a leaked handle would necessarily mean leaked memory), so it would be a very special situation one. Would be helpful to know the exact handle.


    Since you already mention other regedit, it does not have to be Spybot keeping the handle open... what about other security apps? Or any other app that notices another "logged in user". Using Process Explorer on such a machine to test who owns the open handle would probably be quite useful to determine that.

    As for the checking of return values, it does do that. It just does not inform the user any more, hmph We removed that message when hive loading was still a live CD only thing with no user switches possible and a reboot done anyway.

    I noticed Vista has introduced a new hive loading call that would unload the hive when no longer needed, but that wouldn't solve the situation here, nor would it be available for any older OS.
    We haven't used SIDs for the user hives names so far because that would mean an inconsistency with hives from inactive installations, but it might be worthwhile exploring if Windows will continue to use them in the case of user switches if they're named the same way it would name them. We're now testing that.
    Just remember, love is life, and hate is living death.
    Treat your life for what it's worth, and live for every breath
    (Black Sabbath: A National Acrobat)

  8. #38
    Member of Team Spybot PepiMK's Avatar
    Join Date
    Oct 2005
    Location
    Planet Earth
    Posts
    3,601
    Just remember, love is life, and hate is living death.
    Treat your life for what it's worth, and live for every breath
    (Black Sabbath: A National Acrobat)

  9. #39
    Junior Member
    Join Date
    Jun 2008
    Posts
    8

    Default

    Quote Originally Posted by PepiMK View Post
    @n2fc.: tweak added, won't be available until next version after 1.6.0 though (obviously ). But how would you define a "satisfactory" solution?
    Thanks so much for the quick tweak addition!

    In general, I try to dissuade multiple user accounts/profiles since it usually will cause a problem at SOME point, but I understand it is feature that many enjoy!

    What I meant by a "satisfactory solution" was a resolution that makes this issue go away... Not sure if that is doable at this point, but I have had people bring me machines with corrupted user profiles and never thought that SB might have been involved, until I tripped onto this thread... In the future, I intend to always use either DisableUserHivesLoading=1 or /nouserhives to avoid ANY potential issues... Better safe than sorry!

  10. #40
    129260
    Guest

    Lightbulb so do we have a solution in progress?

    because this problem happened to me even when i did not switch users, (if you look at my posting in this thread.) I have fast user service disabled, so i know it was not that that caused the problem. It just happened after finishing the scan, closing spybot and then logging off and logging on under a limited user account-i got the temp user thing. Even a restart did not help...

    I am hoping this does not cause a problem with any more users, as this is a pain in the butt.

    Going to run spybot scan-*fingers crossed this does not happen again*

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •