Spybot 1.6 locking user registry hives

M

MrGreg

New member
Hi Everyone,

I have uncovered an nasty problem with 1.6. I run a weekly scheduled scan using the Administrator account on all of my clients machines. I received several calls this morning from clients saying that they all are receiving the message "Windows cannot find the local profile and is logging you on with a temporary profile." when logging into their limited accounts. Their accounts are limited accounts for security reasons.

I had one of my clients login to the Administrator account to investigate. When we examined the HKEY_USERS hive, we discovered a folder call PE_C_HARVEY. Harvey is the name of the limited user account that is yielding the error message and creating a temporary profile. We unloaded the hive and Harvey was able login with his normal profile. We then checked the scheduled tasks logfile and discovered that the weekly Spybot scan completed successfully with and exit code of 0.

I investigated this further on my machine and discovered that when Spybot runs it creates a folder under HKEY_USERS for each account that is not currently logged in. I assumed that this is done so the immunize and scan functions can process all user accounts on the system. The problem is that when Spybot terminates it is not all ways unloading the temporary hives PE_C_USERNAME that it is creating. Three of my clients also had a folder called PE_C_ALLUSERS in their HKEY_USERS hive. I could reproduce this on my machine but can not understand how this folder would ever be created since the ALLUSERS profile does not even have a registry hive.

I reproduced this problem running Spybot interactively six times in a row closing the program using the red X in the upper right corner. Then I tried terminating the program using File Exit from the menu and the temporary hives were removed. I then went back to closing with the red X and the hives were removed six times in a row. This is very strange and inconsistent behavior.

This problem can be very serious as it will lock the user registy hive forcing Windows to create a temporary profile. A system reboot will not release the hive, you must unload the hive using regedit. This can really mess up the average user that does not understand this stuff. It sounds like this is what happened to ninjat in this recent post...

http://forums.spybot.info/showthread.php?t=33042

The final point that I would like to make is that I did not have any problems with weekly scans using 1.52 with XP Service Pack 2. I updated all of my clients machines to XP Service Pack 3 and Spybot 1.6 at the same time. I am not sure if the SP3 update, or 1.6 or the combination of both is causing this problem. Can anyone else reproduce what I am seeing on multiple systems? Thanks for your support...
 
Last edited:
Hi Everyone,

I keep adding a reply to this post so it will not get lost in the forum. Can anyone assist me with this issue? I would greatly appreciate it. Thanks for the support...
 
MrGreg:

If you left the thread with a zero (0) reply count rather than bumping the thread daily, perhaps you would have received a reply sooner.

__________

I do not believe that the problem you encountered has anything to do with the loading of user registry hives. The problem is most likely caused because Spybot locks the profile of other user accounts while it is doing a scan and your "clients" are logging on to another user account while the Spybot scan is running.

Because Spybot locks the profile of other user accounts while it is doing a scan, you cannot:
  • Switch users while a Spybot scan is still running.
  • Kill the Spybot scan and then switch users.
If either of these situations occur, reboot the system and everything should return to normal.
 
Thank God I'm not the only one having this problem! :)

I have two people here that have come to me for help on this. Both times I just restored their systems to save myself some time. But then they would go home and run a scan and be right back with me the next day! I figured it was a Trojan or something that might be taking the system down with them once Spybot removed them, but no dice to confirm that because others scanners are working just fine. Kaspersky, Malwarebytes.. Did the SpywareWarriors forum and Found Nothing out of the norm.

Both of these systems have many accounts on their computers. I can confirm that there is no problem without spybot 1.6 on their computers. Just to be safe I've run every scanner there is and found nothing. HiJackThis showed nothing that I could think of that would cause this problem. But sure enough those accounts have been looked from the Registry as decribed above. It seems to happen with the latest Spybot version. After running the spybot scan on their accounts with either Admin or User, they are greeted with the "Temp Profile" even after a full reboot.

If I had to guess Spybot locks parts of the registry while doing scans and malware removel. However at the end of the scan it fails to remove the block on the accounts from the registry, thus causing the Temp Profile problems.

This is a BIG problem for me now! So I'm removing SpyBot S&D from all of these computers that I manage until a comfirmed fix has been done.

If there is anything the Spybot Team needs I'll try to help. Spybot is kickass software and I would like to feel safer using it rather than being scared of it.

P.S. I'm sorry if by me replying to your thread causes this to be bumped again and prolongs the reply of the system admins. :red:
 
I too can toss in my two cents and say that I'm having the same issue. Didn't start till I downloaded and installed 1.6 TODAY! Been pulling my hair out till I stumbled onto this.

I've got three accounts on this PC, when I've run spybot and then switched to a different user (having let spybot complete its checks and immunizations, and then closing the program) I get a corrupted user profile error, restoring to a previous setpoint seems to take care of this for me, but needless to say I won't be running spybot till it's cleared.
 
I'm having a similar problem...
After I updated from .5x to .6, scanned and restarted...
the scan didn't show any malware except alexa toolbar...
so it problably isn't related to it...
my computer won't pas by the "blue screen with a windows xp logo" just after the windows xp black loading screen
I guessed that it "deleted" my only user (admin) until I saw this topic
I need some help to fix it...
I have a winxp sp2 install cd with me also
 
hello....

did everyone not read md spybot fans post?

http://forums.spybot.info/showpost.php?p=229196&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:
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. :red:
 
Tivon:

Tivon said:
…However it was not doing this before in 1.5 and it's doing it now in 1.6. …
Click to expand...
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:
Tivon said:
… So how do they avoid this problem in the future? …
Click to expand...
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).
 
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
 
JohnT75 said:
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
Click to expand...

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. :fear:
 
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:
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
 
MrGreg said:
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).
Click to expand...

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?
 
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:
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?
 
You must log in or register to reply here.
Back
Top