Page 2 of 9 FirstFirst 123456 ... LastLast
Results 11 to 20 of 84

Thread: Spybot 1.6 locking user registry hives

  1. #11
    129260
    Guest

    Lightbulb hello....

    did everyone not read md spybot fans post?

    http://forums.spybot.info/showpost.p...96&postcount=7

    You are not to be running a spybot scan and then switch users. Spybot was not designed to be running a scan on a account and then switch to another user. If you run a spybot scan and then close the program, and then log off and log on as another user, you might not be able to log on. A simple restart should fix the issue you guys are having. I have never had a issue....i hope that helps.
    Last edited by 129260; 2008-09-03 at 04:56.

  2. #12
    Junior Member
    Join Date
    Sep 2008
    Posts
    6

    Default

    I can understand that. And that is also probably part of the problem. However it was not doing this before in 1.5 and it's doing it now in 1.6. The problem is that while I understand it will do this with many accounts running it does not allow you to simply restart the system and get back in. I walked a few people on the phone and that was the first thing I told them to do was reboot the system and when they tried to log back in to one of the accounts they get the temp profile problem. That is why they used a restore point because something about spybot 1.6 has locked them out. I don't care if they had other accounts running at the same time and switched over and got locked out temporarily until a restart is done, that's besides the fact. The problem is why are the accounts locked even after a restart? So how do they avoid this problem in the future? Do they log into only one account and do a scan and restart without switching accounts.. Why? It all sounds rather system critical to those none advanced windows users to have to dodge so many issues with 1.6 and that is why I've removed spybot 1.6 until you all can figure out a better way to handle this NEW PROBLEM.

    Let's figure this out please. Sorry If I sound a little heated.. I'm tired.. no sleep and people want their Spybot back.

  3. #13
    Spybot Advisor Team [Retired] md usa spybot fan's Avatar
    Join Date
    Oct 2005
    Posts
    5,859

    Default

    Tivon:

    Quote Originally Posted by Tivon View Post
    …However it was not doing this before in 1.5 and it's doing it now in 1.6. …
    In versions of Spybot prior to Spybot 1.5, a scan from one user account did not include the Internet cache, cookies and some other user specific entries of other user accounts. Starting with Spybot 1.5 all user accounts are scanned for those elements. Problems with profiles when switching users while a Spybot scan is running was noted in Spybot 1.5.2.20 when this change was made. For example see:

    The problem was identified and allegedly fixed. However, apparently it was not fixed. See:

    Quote Originally Posted by Tivon View Post
    … So how do they avoid this problem in the future? …
    Just don't switch users while a Spybot scan is running (or if you do a "Stop check" while a Spybot scan is running, reboot).

    Getting an answer is one thing, learning is another.


    Microsoft Windows XP Home Edition running on a 2.40GHz Intel® Pentium® 4 Processor with 512 MB of RAM and a 533 MHz System Bus.

  4. #14
    Junior Member
    Join Date
    Sep 2008
    Posts
    1

    Exclamation Spybot 1.6 locking user registry hives

    I have experienced the same problem on two different PC's, of different manufacturers. Both PC's use Windows XP.

    The restricted users could not access their existing documents in the "My Document" folder which now was blank. Also all e-mails and contacts in Outlook were lost.

    This problem is obviously repeatable. Norton GoBack resolved this temporary disaster. I hope to hear a response on how the SpyBot developers will solve this issue. I have stopped using SpyBot for now.

    JohnT

  5. #15
    Junior Member
    Join Date
    Sep 2008
    Posts
    6

    Default

    Quote Originally Posted by JohnT75 View Post
    I have experienced the same problem on two different PC's, of different manufacturers. Both PC's use Windows XP.

    The restricted users could not access their existing documents in the "My Document" folder which now was blank. Also all e-mails and contacts in Outlook were lost.

    This problem is obviously repeatable. Norton GoBack resolved this temporary disaster. I hope to hear a response on how the SpyBot developers will solve this issue. I have stopped using SpyBot for now.

    JohnT
    Yup, that's what the average user would run into. I did some searching the first time around and noticed that all of that stuff is still on drive it's just that the account profile is locked and loading you into a temp profile. Basically a temp profile is like logging you in with another account, so you will not see any files in the personal folders because they are in another location.

    I told everyone I know what they should do if they want to keep using spybot, but they seem rather reluctant to even bother since things are working without it.

  6. #16
    Member
    Join Date
    Oct 2007
    Posts
    55

    Default

    Hi Everyone,

    Thanks for your reply md usa spybot fan. However your assumtions are incorrect. If you read my post it states that my clients machines are running a scheduled task scan. The scan runs at 3:00 AM in the morning once a week. My clients were sleeping at this time. I would also note that I have fast user switching disabled on my clients systems. So there is no chance that the users switched accounts as they were asleep and fast user switching is disabled. I also stated that the task scheduler log file indicates that the weekly scan completed successfully. This means that process terminated normally and should of unloaded the user hives.

    You will also note that I reproduced the error six times myself on my machine by launching the program interactively. I did not even run a scan. The user hives get loaded when the program is launched not when a scan is performed. The user hives are then unloaded when the program terminates normally. Of course if you run a scan the hives are already loaded.

    A reboot will not fix this problem. When a user hive gets loaded into HKEY_USERS, it must be unloaded by the software that loaded it or manually using the registry editor. For those that experience this problem you must log into an account that has Admin priv's and unload the user hives manually from HKEY_USERS. This will fix the affected user account(s).

    I have not had this problem again yet with any of my clients machines. At least none of them have complained about it. md usa spybot fan is correct that you should not switch user accounts or kill Spybot from the task manager while it is running. This will result in locking the user hives. However it is clear to me that in some cases the user hives are not unloaded cleanly even when the programs terminates normally. Hopefully the developers will look into this problem.
    Last edited by MrGreg; 2008-09-10 at 09:22.

  7. #17
    Junior Member
    Join Date
    Sep 2008
    Posts
    1

    Exclamation Data in User Profile is truly lost

    It seems that I have completely lost all data for my other user profile on my machine due to this problem.

    The first time it happened, I found the data on my drive by searching and backed up the My Documents folder, then successfully followed instructions to restore the old profile. The second time it happened, the lost data is no longer turning up in a drive search and I had forgotten to backup my Firefox bookmarks for that user profile. These now seem to be gone for good. I wish there was a way to get those back now. If anyone has a suggestion to recover that user's bookmarks, please let me know.

    This all began happening the day I upgraded to Spybot 1.6

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

    Default

    Quote Originally Posted by MrGreg View Post
    A reboot will not fix this problem. When a user hive gets loaded into HKEY_USERS, it must be unloaded by the software that loaded it or manually using the registry editor. For those that experience this problem you must log into an account that has Admin priv's and unload the user hives manually from HKEY_USERS. This will fix the affected user account(s).
    I'm no expert on Spybot, but I do know that it is not normal Windows behavior for an HKEY_USERS key to remain after a reboot. The entire HKEY_USERS tree is supposed to be dynamic, rebuilt as needed. Are you sure there isn't something recreating the PE_C_accountname entries when you reboot? Is there a Spybot process that runs at system startup?

    Let's say you log on as admin, start Spybot, then kill it from the Task Manager. That should leave a PE_C_ entry for every user account, plus DEFAULT and ALL USERS. If you manually delete exactly one of those user keys, reboot the machine, and log back on as admin, will all of the PE_C_ keys except that one still be in HKEY_USERS?

  9. #19
    Member
    Join Date
    Oct 2007
    Posts
    55

    Default

    Hi jjjdavidson,

    Thanks for your reply. You are infact correct and I am wrong. I tested this in two ways. First I manually loaded my user account hive (Greg) in HKEY_USERS using regedit from the Administrator account. I then rebooted and sure enough the Greg hive was removed. I then ran Spybot from the Administrator account which created PE_C_GREG under HKEY_USERS. I then killed Spybot using the Windows task manager. I checked to confirm that PE_C_GREG was still loaded in HKEY_USERS and it was. I then rebooted and found that sure enough the PE_C_GREG hive was removed from HKEY_USERS.

    This is getting really strange. Both of my clients that had this problem were instructed by me to reboot their machines. The reboot did not clear the PE_C_accountname from HKEY_USERS. In both cases I had them login to the Administrator account and manually remove the PE_C_accountname key using regedit.

    In my case the scan was run at 3:00 AM in the morning with no user intervention. In both cases the task scheduler log showed a normal completion of the task with an exit code of 0. Which means that the program should of exited normally releasing the other user acount hives. Others in this post have also stated that a reboot did not unlock the user account in question. I would also mention again that I was able to run Spybot manually six times in a row and then terminate it normally and it did not release the other user account hive(s). I have not been able to reproduce this behavior again.

    So how can this happen? It appears that sometimes when Spybot terminates normally it is unable to unload the other user hives from HKEY_USERS. I am fairly certain that Spybot has tried to release the hive(s) but has failed. My guess is that when this happens a reboot will also not release the hive(s). I am not certain how this can occur. If I had to guess the hive(s) must be locked somehow perhaps from an handle that was opened and not closed (i.e. a leaky handle). This is a real mystery to me and I hope someone can shed some light on this one.
    Last edited by MrGreg; 2008-09-11 at 01:35.

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

    Default

    From my own testing (I'm having my own very different problems with Spybot and registry hives) I've seen that if Spybot once exits and leaves those PE_C_ keys lying about in HKEY_USERS, it never gets rid of them.

    If you start a new Spybot session with PE_C_ keys still existing from an earlier (aborted) session, the new session will use them, but won't remove them afterward. Apparently, each Spybot session keeps track of what keys it created, and won't delete any it didn't create. Only a reboot or manual deletion will kill them.

    On a standard Windows XP/2000 system, the following command will remove any PE_C_ keys that Spybot leaves lying. This is all one command that has to go on one line. If you want to put it in a batch (.cmd) file, use %%k wherever I use %k.

    Code:
    for /f "usebackq tokens=3 delims=\" %k in (`dir/s/a-d/b "c:\documents and settings\ntuser.dat"`) do reg unload "HKU\PE_C_%k"
    I'm as baffled as anybody about how accounts could remain locked after a reboot; that's such an unlikely circumstance from a Windows point of view that I'm inclined to put it down to an error of communication. Has anybody following this thread actually seen an HKEY_USERS\PE_C_ key still existing immediately after a reboot?

Posting Permissions

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