Spybot 1.6 locking user registry hives

Hi jjjdavidson,

The PE_C_ keys should be removed when Spybot terminates normally. However when my clients called me and their accounts were locked I ran some tests on my system. I found that for six program starts, the PE_C_ keys were not removed. Then on the seventh time the keys were deleted. I have yet to reproduce this problem again. It seems now my system is removing the keys everytime.

As for the PE_C keys still existing after a reboot, the answer is yes. This is what happened with two of my clients. When this happens a temporary profile is created when the user logs in. The first thing I had them try was a reboot. We had to manually unload the PE_C keys from the Administrator account using regedit. I have tried to reproduce this on my system but have been unsuccessful.
 
i as well....

now experience this issue....it just happened. Weird thing is...the spybot scan was completely finished and the program closed. I logged off, and i let my sister log on. She as well as soon as she logged on, it said temporary user as well. i held in the power button and restarted and everything, her account was rebuilt from scratch. However, i could find all her files in c/documents and settings/(user) and they were in there. However, when she logs on, it looks like the account was just created. I am going to try a system restore to fix this, as i have no idea how to mess with reg hives.
 
just great....

now not only has my sister lost her account, my other limited user account is gone as well. i mean they are there, but now they wont even load the accounts now ether. My sister her account loaded the temp account fine at first. I tried a system restore and now none of the limited accounts work. At least my admin account still loads and works fine. (the one i scanned on) Luckily i was able to recover there data, but i am going to delete the accounts and remake them as i don't know what to do in the registry. Then i will put the data back on...ugh this stinks. I hope deleting the accounts and remaking them fixes this...
 
Last edited:
Hi 129260,

Sorry I did not read about your problem sooner. All you had to do was login to your account which had administrator priv's. Once in your account just run regedit from the Run box. Navigate to the HKEY_USERS section of the registry. Expand the HKEY_USERS section by clicking on the + sign. Find the PE_C_ keys for the accounts that have been locked and remove the keys. You can remove the keys by highlighting them and selecting Unload Hive from the File Menu. That will unlock the accounts and then the user can login again. There should be no side effects to their accounts. All settings and files should be as they were before the problem occurred. FYI I do not recommend using System Restore as it can corrupt your system and make matters worse. You should look into a proven backup software. I use and recommend Retrospect Professional from EMC Dantz. Here is the link...

http://www.emcinsignia.com/products/smb/retroforwin/#
 
haha well to late for that...

i had already tried system restore before you replied. its ok though, thanks. :) Well if this happens again i now know what to do. Thanks for the info. In any rate, deleting the accounts and making them again seemed to have solved the problem. The only thing that happened was avast got corrupted and i had to reinstall it. Not all the shield providers were able to run. Anyway, avast is now working fine, and i am glad this mess it over with. Now I'm just hoping it did not corrupt anything else...

Thanks alot for the info, i appreciate it. :bigthumb:
 
Hi 129260,

Glad you are back in business. I really wish the developers would have a look at this thread. This is definately a serious problem and needs to be investigated. Lets hope the problem is corrected before other have the same issue.
 
ur telling me

MrGreg said:
Hi 129260,

Glad you are back in business. I really wish the developers would have a look at this thread. This is definitely a serious problem and needs to be investigated. Lets hope the problem is corrected before other have the same issue.
Click to expand...

it is, i thought it was mild at first, but now i am seeing how much of a problem this is. I am hoping the spybot team can come up with a solution. :)
 
I'm sorry to hear that you ran into this problem. I'm still waiting on a fix before I install it on systems with more than one account.
 
@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.

Personally, I would also prefer hives that are properly loaded and fully managed by Windows itself and not forced into memory the hard way, but the regular way needs users to be logged on to scan their profiles, but that can be done only with their credentials (which from the security standpoint is ok, even an admin shouldnt be able to imersonate users).

If the hives persist after closing Spybot: does Spybot (or Windows) show any error messages on closing?
 
@ PepiMK

I experienced no error messages when closing spybot or anything from windows after my scan completed. It created a temp account without any notice at all! I logged off after my spybot scan completed, and the program was closed. My sister logged on and it said temp account is being used. I restarted and it still did not fix the problem. I had to delete all limited user accounts and recreate them; because at the time i did not understand how to mess with the registry to get them back.
 
Last edited:
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.
 
PepiMK said:
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.
Click to expand...

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
 
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:
PepiMK said:
@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.
Click to expand...

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! :oops:
 
@ PepiMK...

Do we have any more info on this problem yet? Just wondering! :)
 
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..
 
@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 :lip: 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.
 
PepiMK said:
@n2fc.: tweak added, won't be available until next version after 1.6.0 though (obviously ;) ). But how would you define a "satisfactory" solution?
Click to expand...

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