View Full Version : Spybot 1.6 locking user registry hives
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...
Can anyone shed some light on this problem? It would be most appreciated.
Thanks for the support..
Hi Everyone,
I am still waiting for anyone to reply to this thread. Thanks for the support...
Anyone have an answer for me?
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...
Stll waiting on anyone that can shed so light on this one. Thanks...
md usa spybot fan
2008-08-29, 12:36
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:
ajmoyerxr7
2008-09-02, 04:39
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.
Bozoleet
2008-09-03, 00:51
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
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.
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:
md usa spybot fan
2008-09-04, 15:08
Tivon:
…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:
Spybot Corrupting user profiles
http://forums.spybot.info/showthread.php?t=25448
The problem was identified and allegedly fixed. However, apparently it was not fixed. See:
Fast User Switching during a scan (http://forums.spybot.info/project.php?issueid=201)
Terminal Services & user profiles (http://forums.spybot.info/project.php?issueid=200)
… 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).
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
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. :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.
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
jjjdavidson
2008-09-10, 21:51
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?
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.
jjjdavidson
2008-09-11, 05:25
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.
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?
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.
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.
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...
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/#
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.
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.
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 (http://wiki.spybot.info/index.php//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?
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.
jjjdavidson
2008-09-22, 17:11
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.
jjjdavidson
2008-09-22, 17:36
There's a simple command line parameter to suppress the loading of user hives: /nouserhives (http://wiki.spybot.info/index.php//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
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...
@MrGreg: haven't seen this thread before, sorry!
There's a simple command line parameter to suppress the loading of user hives: /nouserhives (http://wiki.spybot.info/index.php//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! :oops:
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 (http://wiki.spybot.info/index.php/Registry_Tweaks#DisableUserHivesLoading), 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.
Update: Name loaded user hives after SID (http://forums.spybot.info/project.php?issueid=290)
@n2fc.: tweak added (http://wiki.spybot.info/index.php/Registry_Tweaks#DisableUserHivesLoading), 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!
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* :)
it's not just limited user accounts
I have a Game profile that has full rights and it done it to it also
after last update it only done it to my game profile and it redirected it to C:\Documents and Settings\TEMP
in the registry
I had to change it back to Game
I think it might have to something to do with a early crash or shutdown
it's not putting things back, useing the X would be constiered a unproper shutdown
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* :)
Even without Fast User Switching, maybe someone logged into one account and then logged off before you logged in and did the scan?
I'm waiting for 1.6.1, and after that checking here many times to be sure things are safe again. :)
Even without Fast User Switching, maybe someone logged into one account and then logged off before you logged in and did the scan?
I'm waiting for 1.6.1, and after that checking here many times to be sure things are safe again. :)
nope, i was the first user logged on :)
no one logged on and off before i did, nor before i started the spybot scan. In any rate, i restart now every time i run a spybot scan so that this issue does not occur again. So far nothing has happened.
A beta update (tested the last three days here) that fixes the user login problems by using the same key names a user login (see project tools) would create is now available in the download section (http://forums.spybot.info/downloads.php?id=37) :)
A beta update (tested the last three days here) that fixes the user login problems by using the same key names a user login (see project tools) would create is now available in the download section (http://forums.spybot.info/downloads.php?id=37) :)
Great! I will test that asap
jjjdavidson
2008-10-09, 23:21
PepiMK, I've tested the 1.6.1.33 beta on two of machines, and I've got a couple of questions:
1) When 1.6.1.33 closes, is it supposed to unload the new SID keys the way 1.6.0 (usually) unloads the PE_C keys? On my main machine it loads the SID-named keys just fine, but never unloads them.
2) Is this version supposed to stop automatically enabling /nouserhives on machines with Terminal Services? I've been suspecting that /nouserhives was behind my problem in this thread, so I've been waiting for this update to come out.
I tried 1.6.1.33 on one of the two machines that was giving me trouble, and it still doesn't load any user hives (even with /allhives). If the Terminal Services check was supposed to be disabled in 1.6.1.33, then something else is keeping Spybot from loading user hives.
Thanks!
1. Yes it should. I also had the warning dialog when this does not work re-enabled for a short time, but then, we discussed the confusion of users who would not understand that a user switch might have been the reason for that.
2. Oh, someone describing a problem that clearly and I missed it :/
I'll immediately add a new command line parameter /userhives to force these on Terminal Services! The beta was not yet supposed to disable the special treatment of Terminal Services, for two reasons: 1. the amount of testing, and 2. while XP and above are said to have no registry size limit, I experienced some, and TS servers might possibly have quite a lot of users.
As soon as I've come to update the Hint of the Day thing, there'll be another update :)
Hi Everyone,
I just tried the 1.6.1.33 beta version. The new SID hive(s) are not unloading on my machine either. The good news is that if you log off and then login to another user account with the SID hive(s) still loaded, the temporary profile is not created. It seems the SID hive(s) have solved the problem. However the SID hive(s) should still be unloaded when Spybot terminates. At least an attempt to unload them should occur. Thanks for fixing this one up PepiMK
Improved the unloading, did some testing re: Hint of the Day, update soon :)
Improved the unloading, did some testing re: Hint of the Day, update soon :)
Looks like people are working on this problem.. Yep, the sweat smell of progress is happening here. :banana:
Anyone else tested the new release? :)
Got an advcheck.dll and a tools.dll beta update coming tomorrow as well - a week after that, probably a beta 1.6.1 installation package :)
jjjdavidson
2008-10-23, 18:47
I just downloaded and briefly tested SpybotSD.exe 1.6.1.35 on two Windows XP Pro machines. Things are looking up!
On the machine where I couldn't get user hives to load, 1.6.1.35 still doesn't load them by default, but your new /userhives parameter does cause them to load. (I'd still like to know why /nouserhives is apparently the default on this machine and one other. Could it have anything to do with the XP Remote Desktop feature?)
On both test machines, the user hives still stay loaded after 1.6.1.35 is shut down normally, as they did with 1.6.1.33. Since you now use the SID key name, I can switch users without a problem, but I don't know if the open hives tie up any memory or other system resources.
Yes, the Remote Desktop feature might be the reason. User hives do not get loaded if WTS (Windows Terminal Services) is detected to be running, and the remote desktop seems to be just that (I even tested WTS with the Remote Desktop feature because it was easier than doing so on a real server).
As for resources, MS says that XP etc. do not have a registry size limit any more. But I already wrote about that ;)
Think I found a possible reason for the later one. We still have two kind of user registry keys - SIDs can only be used for hives of the current system. Hives from inactive installations would still have the old name, and unloading had problems seeing the difference and deciding there. Going to finish that testing tomorrow :)
Hi Everyone,
I just tested 1.6.1.35 on my system. I am the same as jjjdavidson in that the other user hives are still not unloading after normal termination of Spybot.
jjjdavidson
2008-10-25, 02:56
User hives do not get loaded if WTS (Windows Terminal Services) is detected to be running, and the remote desktop seems to be just that....
Is WTS the Terminal Services service? If so, it runs all the time on all of my XP Pro systems, the two that always load the user hives and the two that don't. The description under Services.msc says, "The underpinning of Remote Desktop (including RD for Administrators), Fast User Switching, Remote Assistance, and Terminal Server" (italics mine), so I guess it's supposed to be.
I have used Remote Desktop on the two problem systems, but not for several months (and dozens of reboots). So if RDP is the problem, then using RDP once apparently makes a permanent change in system settings that Spybot is detecting. Am I off base here?
(By the way, since 1.6.1 seems to beautifully resolve MrGreg's original problem, should we swap this discussion back to my more specific thread?)
Made a 1.6.1.36 (http://forums.spybot.info/downloads.php?id=37).
WTS is "Windows Teminal Services", yes. For detecting it, WTSEnumerateSessions (http://msdn.microsoft.com/en-us/library/aa383833%28VS.85%29.aspx) is used to determine the count of sessions. If the Remote Desktop / Assistance / Terminal Server is active, there are at least two sessions.
Hi PepiMK,
The link to 1.6.1.36 is not working. There are only links to 1.6.1.33 and 1.6.1.35.
Hi PepiMK,
The link to 1.6.1.36 is not working. There are only links to 1.6.1.33 and 1.6.1.35.
You really think? :)
5 second...
http://www.spybotupdates.biz/files/beta/SpybotSD.exe-1.6.1.36.zip
Hehe, true, but .36s new dialogs are not yet well integrated with the localization, and I have a .37 with some special PE booting improvements nearly ready, so I disabled the download page entry ;)
Hehe, true, but .36s new dialogs are not yet well integrated with the localization, and I have a .37 with some special PE booting improvements nearly ready, so I disabled the download page entry ;)
SpybotSD 1.6.1.36 russian localization:):
2632
Hi everyone,
I have just tested 1.6.1.36. The results look good. The new SID hives are now unloading correctly for other user accounts. Thanks for getting it fixed up PepiMK. When can we expect the official 1.6.1 release?
1.6.1.37 now online :)
Official 1.6.1?
We need feedback on TeaTimer still.
Hi PepiMK,
I have just tested 1.6.1.37. The SID hive unloading still looks good on this release. I do not use TeaTimer so I can not help with any feedback. What I mean buy an official release is the non beta release that will be available for download on the main download page. When do think that will be available for all? Thanks for your support.
madeline
2008-10-31, 03:09
Eureka! I've been struggling with User Profile problems for weeks, seeking help from techie friends and even from Microsoft Support (since the trouble started after updating to SP3 for XP, altho in retrospect that might have been coincidental.) I have SpyBot 1.6.0.30 and also AVG Free 8.0.175. Originally had 2 User accounts (both Administrative), neither of which had any problems for >3 yrs. After XP3 update and SpyBot download, one of the user account profiles was inaccessible, and Windows loaded that user with a default user profile. I then created a new user account to start fresh, but this morning after doing a SpyBot update, THAT user profile also wouldn't load its settings.
I've read this entire thread, and wonder what to do now - will downloading the new SpyBot patch (1.6.1.37 ?) fix everything? Where best to download it? Or, if I need to edit the registry using regedit, which PE_C keys should be deleted, and which saved?
Please help, this whole thing has been so very frustrating. I thought this was an XP SP3 problem all along and am surprised that SpyBot is involved. Maybe AVG is, too?
This happens wheneven Spybot closes "not normally", but the situatios should be solved after a reboot, just fast user switching and logoff/login situations should be affected when something has "killed" Spybot (like thep udate which forces Spybot a bit harsh to close).
Other applications, especially security/monitoring applications, might be "at fault" as well because they detect the loaded registry and look into it when Spybot tries to unload it again.
Please do not delete any PE_C_ keys. They should be no longer loaded after a reboot.
If you want to use this file, the archive includes just SpybotSD.exe, which needs to be extracted to C:\Program Files\Spybot - Search & Destroy\, replacing the SpybotSD.exe that is there. You probably need to make hidden and system files visible in Explorer to do that.
Hi Madeline,
I just wanted to comment on your problem. I partially disagree with PepiMK about the PE_C keys. Under normal circumstances if the PE_C keys do not get unloaded when Spybot terminates, they will be removed after a reboot. However two of my clients that use Spybot, had the PE_C key get stuck in such a way that a reboot did not remove the stuck keys. Others that posted in this thread also experienced a stuck PE_C key that was not removed after reboot. In this case you will need to use Regedit to remove the stuck keys.
First reboot the machine. Log in to an account that has Administrative privileges (Not the account you are having trouble with). Do not run Spybot after reboot. Then run regedit and expand the HK_USERS hive. If you see any PE_C keys then these keys are stuck and need to be removed. Highlight the PE_C keys one at a time. The click on File in the menu bar and select Unload Hive. Click yes to the confirmation message and the hive will be unloaded. You will now be able to login to the account(s) that were inaccessible. Hope this helps...
As for resources, MS says that XP etc. do not have a registry size limit any more. But I already wrote about that ;)
Sorry for the slight thread jack, but at what point did you experience the problems. According to windows my profile is 2.39GB and the wifes is 1.98GB. I figured the two profiles would allow her to be able to install things she like without affecting my installs and settings very much. Also, maybe I missed it, seven pages of reading does that, but does the version that you download from the main download page have the /noprofile (or what ever it was) set or do I need to update my shortcuts untill the next version is out?
Could someone please take a look at the first half of another thread I started, Titled; Problems After Updating? Reading this thread here makes me think I may have a similar issue, but I'm not advanced enough to tell. Just the first half of the thread. I'm using version 1.6.0.31 WinXP home SP3. Here's the link;
http://forums.spybot.info/showthread.php?t=35866
Thanks
madeline
2008-11-01, 01:10
Hi Mr. Greg,
Thanks for commenting. I agree that rebooting does not fix whatever problem I have, since I've rebooted and also completely shut down many times over the past few weeks. The new user account that I set up earlier is now working again, so that one might have been somehow repaired with a reboot. But my main (old) user account (which has 1.42 GB of important data) still won't let me open any files or programs.
Using the new user account, I could not find any PE_C keys under the HKEY_USERS section using Regedit - there were a bunch of different folders there, starting with ".DEFAULT" and then lots of folders with numbers similar to 5-1-5-18. All of these folders contained different folders, and I'm wondering if the PE_C keys might be somewhere inside one of those? (I'm not that familiar with registry folders, as you can tell). One question: If you adjust the registry using one (administrative) User account, does the change apply to all other user accounts on the computer?
I did finally get a suggestion from a MS Tech, to rename (in Safe Mode) the UsrClass.dat file (found in C:\Documents and Settings\problem user account\Local Settings\ApplicationData\Microsoft\Windows\for the problem user account to UsrClass.datold. For some reason, I could not rename the file in Safe Mode - my keyboard input was not recognized at the cursor in the file rename box. I rebooted and renamed the file in regular mode, but it didn't fix anything.
(Of course I changed the settings so that all the hidden files and system files are displayed.)
I'm wondering if Uninstalling Spybot might help, although I'm reluctant to do that, but I'm getting desperate. Also, what about AVG Free 8.0, maybe I should uninstall that? It gets so complicated, all in the name of security.....
Any ideas will be much appreciated!
Hi Madeline,
I just wanted to comment on your problem. I partially disagree with PepiMK about the PE_C keys. Under normal circumstances if the PE_C keys do not get unloaded when Spybot terminates, they will be removed after a reboot. However two of my clients that use Spybot, had the PE_C key get stuck in such a way that a reboot did not remove the stuck keys. Others that posted in this thread also experienced a stuck PE_C key that was not removed after reboot. In this case you will need to use Regedit to remove the stuck keys.
First reboot the machine. Log in to an account that has Administrative privileges (Not the account you are having trouble with). Do not run Spybot after reboot. Then run regedit and expand the HK_USERS hive. If you see any PE_C keys then these keys are stuck and need to be removed. Highlight the PE_C keys one at a time. The click on File in the menu bar and select Unload Hive. Click yes to the confirmation message and the hive will be unloaded. You will now be able to login to the account(s) that were inaccessible. Hope this helps...
madeline
2008-11-01, 01:14
Thanks for commenting. What happened to the beta "hot fix" for user profile problems mentioned earlier, is that no longer available? Rebooting does not help. (Yes, all hidden and system files are visible.) Do you think a complete Uninstall of Spybot might help?
Thank you!
If you want to use this file, the archive includes just SpybotSD.exe, which needs to be extracted to C:\Program Files\Spybot - Search & Destroy\, replacing the SpybotSD.exe that is there. You probably need to make hidden and system files visible in Explorer to do that.
Hi Madeline,
But my main (old) user account (which has 1.42 GB of important data) still won't let me open any files or programs.
Does this mean that when you log into the old account it is creating a temporary profile or you are able to log in without Windows creating a temporary profile and you can not access files or programs?
All of these folders contained different folders, and I'm wondering if the PE_C keys might be somewhere inside one of those?
No the PE_C keys are located at the same level as .DEFAULT and the other S-15- keys. So if you did not see any then your account(s) should not be locked.
If you adjust the registry using one (administrative) User account, does the change apply to all other user accounts on the computer?
That depends on which section of the registy you are changing. The HKEY_CLASSES_ROOT and HKEY_LOCAL_MACHINE are used by all accounts on the machine. HKEY_CURRENT_USER only applies to the account that is current logged in. In HKEY_USERS each folder applies to to a different account.
I'm wondering if Uninstalling Spybot might help, although I'm reluctant to do that, but I'm getting desperate. Also, what about AVG Free 8.0, maybe I should uninstall that?
No uninstalling Spybot and AVG will not solve your problem. Please let me no the answer to my first question about can you log in to your old account or is it creating a temporary profile when you try to login. With this answer I can help you proceed.
The link to the latest beta version is here 1.6.1.37 is here http://forums.spybot.info/downloads.php?id=37
This version will keep the accounts from ever getting locked but will not solve your immediate problem of getting you old account going.
Hi K-Rock,
The /nouserhives is in the release that you download from the main download page. This switch is not enabled by default you must update your shortcuts if you wish to use it. Here is a link to the explanation of the switch. http://wiki.spybot.info/index.php//nouserhives
An alternative would be to download the latest beta SpybotSD.exe and replace it. You may find it here. http://forums.spybot.info/downloads.php?id=37
Hi patmac,
The answer is yes. Spybot was unable to unload the registry hive for your limited account. Good news that the reboot unlocked the hive as this has not solved the problem for some.
Hi Madeline,
I just wanted to comment on your problem. I partially disagree with PepiMK about the PE_C keys.
The "which should I delete" made me extra-careful there, so I just shouted "stop" ;)
You pointed at unloading, which would be the correct description and action, thanks :)
Sorry for the slight thread jack, but at what point did you experience the problems. According to windows my profile is 2.39GB and the wifes is 1.98GB.
The "profile" does not equal the registry. What counts in regards to the registry size is the ntuser.dat file inside the profile, which might be around 1 to 2 MB on a standard installation without too many "experiments". Ever the time, while Windows is used over the years and you try this and that, it might grow to 5 to 10 MB based on the amount of things you do. The limits I eperienced where somewhere around 120 MB, which would mean quite a lot of user accounts over quite a lot of time.
But: the extension to which software uses the registry varies.
I agree that rebooting does not fix whatever problem I have, since I've rebooted and also completely shut down many times over the past few weeks. [...] But my main (old) user account (which has 1.42 GB of important data) still won't let me open any files or programs.
I think we need some more error details now. Since below you wrote that you do not see any PE_(drive letter)_ keys in HKEY_USERS, the problem might be something else.
You wrote that you old iser account does not let you open programs or files. Does that mean you can login using it? Previously you wrote that it was inaccessible or would not load settings. Could you let us know which error message you receive exactly at which point? Error during login? When starting programs? ...
All of these folders contained different folders, and I'm wondering if the PE_C keys might be somewhere inside one of those?
S-1-5-18, S-1-5-19 and S-1-5-20 are system accounts which are used internally by Windows; please do not touch them! .DEFAULT is, well, a default settins template, please do not touch that either.
S-1-5-21-...-...-500 is the system administrator account. S-1-5-21-...-...-501 usually the "Guest" account.
Regularly created user accounts start at S-1-5-21-...-...-1000.
madeline
2008-11-02, 00:19
Hi Mr.Greg & PepiMK,
Thanks for commenting on my user account problems. Yes, now I can log on to my (old, corrupted) administrator user account, but cannot access any of my programs (i.e., MS Office, Photoshop, Dreamweaver, FileZilla, Adobe Reader). The pop-up error message is always the same: "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item." I can open .txt and .jpg files, yipee.
I also cannot access the internet from this user account, since IE 7 appears to be stuck in a loop trying to access "http://runonce.msn.com/runonce.3aspx." (This seems to be associated with a "Customize Your Settings" page.) I can connect if I run IE without browser add-ons (by right-clicking on the IE desktop shortcut and selecting "Start without Add-ons"). Then going to "Tools > Manage Add-ons > Add-ons currently loaded in IE", there are 10 listed. I don't know much about these, but 3 look questionable to me, and I figured I could disable one at a time and see if that helped the IE7 situation. Unless you have some better ideas!
All programs and IE7 work normally in the other original administrator account on this PC (my better half's), AND in the new administrator account I set up for myself when the troubles began with my original (3 yr. old) account. Something just messed up my own account - whether it was the XP SP3 download combined with Spybot update, and maybe even AVG 8, who knows?
I guess transferring all my old files to the new administrator account is a solution, though tedious, but being burdened with a scientific mind, remaining questions are always troublesome.
I will completely understand if you guys want to bow out - it is so frustrating, and boring, and life is too short. (I'm thinking a Mac, and Safari, next time.)
Hope you're all having a good weekend, in this great weather (in DE anyway).
Some more of my two cents on this....my issue of a Lost Local Profile ( on Limited User Account ) started after the last updates I obtained for SBS&D, on 10/27.
Have never had this problem before this date. I was going to do a System Restore back prior to the updates, but then my Spybot defs would be outdated hence forth. It sounds like I'm lucky here, that a reboot unlocked whatever was (to my untrained eye, sounds like Sbybot was ) holding my Local Profile in limbo.
I have not tried to recreate the problem, since reading this thread, it all sounds dicey. One of the odd things about the last list of updates (from 10/27), was an IE plugin update-SDHelper and a TeaTimer update-TeaTimer, both dated 9/24(Sept. 24th).
Is this worth noting.....that this problem ONLY started after the last updates?
Thanks...still way over my head......
Hi Madeline,
It sounds like you have a permissions problem. It could either be file or registry permissions. Since you can access programs from your new account, I am guessing that it is registry permissions. I am uncomfortable in directing you to change registry permissions. If you make a mistake you could render your system useless. I think the best course of action is to copy your files over into your new account. Please let me no how it goes and if I can further assist you...
Hi Patmac,
The updates and your user profile locking are coinsidental. I say this because I was able to lock my profile in testing without ever running a scan.
In this case the definitions did not come into play. I just ran Spybot and then exited without scanning. It does not happend everytime so it may not lock your other account profiles. Hope this helps...
Is this issue dead?
I'm respectively struggling with why my situation is "coincidental":red:
I always follow the same routine....log out of the Limted User account, log onto the Admin account, download any updates, disable the network connection, run the scans, if all is clean I create a system restore point, enable the network connection, log out of the Admin account, then into the Limited User account to face the web.
Never, until last week(after SBS&D up dates, then scan) have I had a "lost or corrupt local profile" issue.
Today I changed things up alittle, and checked after scanning with AVG, MalwareBytes, and Ad-Aware...logging out of the Admin account, into the Limited User account successfully after each. It wasn't until after SBS&D's scan does it happen.
I checked Task Manager on the Admin account, while the local profile was locked/lost, and found TeaTimer was using 100% of the CPU. Once I rebooted the system, that stopped, even while TeaTimer was enabled...
Does this mean, if I want to continue using SBS&D, I need to kill TeaTimer after everytime I scan with Spybot? Sorry, but that's nuts.
That's why I'm revisiting this thread, hoping, the MANY people smarter than me(that's not hard) here can help....
As you can tell from my posts, I have very limited knowledge here, that said, I need an app that I don't have to try and figure out too many things, I do enough of that at work.
Thanks again for your time...
I have been reading these posts and have to join in. I had the same problem. After upgrading to 1.6.0 and running Spybot S&D as Administrator (with no one else logged in) I was not able to access my settings when logging in as a Limited user, even after rebooting. This happened on two PCs. I 'uninstalled' Spybot using Windows Restore to go back to the day before and all was well.
I did not install Tea Timer.
Windows XP Home SP3
Avast antivirus installed.
Hi Patmac,
Ok it sounds like your limited account profile is getting locked by Spybot. Let me explain what Spybot is doing. When you start Spybot from your Admin account, it will load any other user account profiles on the machine. It does this so it can scan all profiles for potential problems as well as immunize all accounts if you choose to do so. When Spybot is terminated, it should unload any other account profiles that were loaded. If it fails to unload your limited account profile then Windows will create a temporary profile when you try and log in to your limited account. A reboot should normally correct this problem. However some including myself have seen the reboot does not always clear the locked profile. In these cases a manual unload of the affected account must be done using regedit.
This problem has been corrected and is available in a Beta release. The beta is just the spybotsd.exe executable so just download 1.6.1.37 zip file and replace the exe in your spybot folder. You may download the beta here
http://forums.spybot.info/downloads.php?id=37
You do not need to kill Tea Timer before your scans. I do not use Tea Timer but if I had to guess the 100% CPU usage might of been related to your limited account profile being locked. Hope this helps and let us no if you still have problems using the latest beta.
Hi Fixit,
Sorry to here that you were also affected by this problem. You download the latest Beta release here http://forums.spybot.info/downloads.php?id=37
that will correct this problem. In your case a reboot did not unlock you profile. In this case you can login to your Admin account and run Regedit. Open up the HKEY_USERS section of the registry. If you see and keys named PC_driveletter_accountname then highlight and click on File Unload Hive. This will free any profiles that Spybot has locked. Using system restore worked in your case but I have found that it can cause problems sometimes. Hope this helps.
MrGreg,
Thanks. Is it safe for a limited knowledge user like myself to use a beta release? :snorkle:
Hi Patmac,
First I would like to say that you are not as limited in knowledge as you might think. The fact that you have two accounts, one Admin and one limited is a very smart approach to keeping your machine clean. Surfing the web with Admin priv's is a huge mistake that most people make. Surfing as a limited user as you do protects your machine from getting infected for the most part. Secondly you have the knowledge that you need to perform Antivirus and Spyware scans on a regular basis. This tells me you no more than most folks. The beta release is very stable and should cause you no problems. Please give it a try and let me no if this solves your problem. The official 1.6.1 release will be out soon. When it is released simply upgrade.