Spybot 1.6 locking user registry hives

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
 
129260 said:
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* :)
Click to expand...

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. :)
 
haha nope, it is like it was stated above.

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

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

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