Thanks for any help. After scanning for tracks I wanted to set to further ignore one of the results. Unfortunately by mistake I rather have set to ignore the History. When checking in "ignored items" I easily found the other item I had set to ignore but could not find the history setting thus was unable to restore it for future scans. Where could I find it, is it possible to set it back to scan the next time? thanks.
restore ignored history tracks
- Thread starter chercheur
- Start date
md usa spybot fan
Spybot Advisor Team [Retired]
chercheur:
Which exclusion did you use?
If you did an "Exclude this product from further searches" it looks like you discovered a bug because "History" does not appear to be listed in "Ignore products".
What Windows OS are you running?
Which exclusion did you use?
- "Exclude this detection from further searches"
--- or --- - "Exclude this product from further searches"
If you did an "Exclude this product from further searches" it looks like you discovered a bug because "History" does not appear to be listed in "Ignore products".
What Windows OS are you running?
Using XP Pro SP2 and the latest version of Spybot (upgraded just two days ago after uninstalled previous version).
To exclude, I right-clicked on the result. I am not sure which option I clicked but from a test I just did I am pretty sure it was "exclude this product because the option "exclude this detection" does not seem to be active for a group but only for a single detection within the group, and right now I have no History group showing, however I have a Internet Explorer group that shows but that only contains "typed urls" and I am sure I had a History group earlier which I excluded by mistake because I tried to restore it and could not do so because the check box becomes unavalaible once the option to exclude is selected.
My mistake had been to just bring my mouse over the desired item and right click before making sure that the right item was highlighted.
I searched in "Ignore single entries" and in "Ignore products" (paying more attention to "all products" and "tracks.uti")
There is absolutely no exclusion showing in "Ignore single entries".
As for "all products" the only things that are checked for exclusion are the default CDilla and SideStep as well as Microsoft Security Center which is the exclusion I had meant to add, given we had willingly disabled it because we use another firewall and keep our security softwares up-to-date ourselves without needing to be bugged by microsoft about it.
To exclude, I right-clicked on the result. I am not sure which option I clicked but from a test I just did I am pretty sure it was "exclude this product because the option "exclude this detection" does not seem to be active for a group but only for a single detection within the group, and right now I have no History group showing, however I have a Internet Explorer group that shows but that only contains "typed urls" and I am sure I had a History group earlier which I excluded by mistake because I tried to restore it and could not do so because the check box becomes unavalaible once the option to exclude is selected.
My mistake had been to just bring my mouse over the desired item and right click before making sure that the right item was highlighted.
I searched in "Ignore single entries" and in "Ignore products" (paying more attention to "all products" and "tracks.uti")
There is absolutely no exclusion showing in "Ignore single entries".
As for "all products" the only things that are checked for exclusion are the default CDilla and SideStep as well as Microsoft Security Center which is the exclusion I had meant to add, given we had willingly disabled it because we use another firewall and keep our security softwares up-to-date ourselves without needing to be bugged by microsoft about it.
md usa spybot fan
Spybot Advisor Team [Retired]
chercheur:
The "Ignore products" exclusions are stored in the following file:
What you can do however is go into that file (without Spybot running) and remove the "History". Then start Spybot (all entries will be eliminated), go into Spybot » Mode » Advanced mode » Settings » Ignore products and re-add CDilla, SideStep and Microsoft Security Center. Note: The CDilla and SideStep entries are added by default during the installation of Spybot.
The "Ignore products" exclusions are stored in the following file:
- C:\Documents and Settings\All Users\Application Data\Spybot - Search & Destroy\Excludes\Bots.sbe
What you can do however is go into that file (without Spybot running) and remove the "History". Then start Spybot (all entries will be eliminated), go into Spybot » Mode » Advanced mode » Settings » Ignore products and re-add CDilla, SideStep and Microsoft Security Center. Note: The CDilla and SideStep entries are added by default during the installation of Spybot.
restore ignored history tracks: SOLVED
SOLVED! Thanks a bunch MD, the history scan is now back. In fact I should say that spybot seemed to have brought the history back by itself after I ran the software under other users' accounts in both normal and safe modes (the history had remained available from other accounts). However, it seemed to forget the exclusions every time I had run the software from within another account. I deleted the file as you said, and had to re-add the exclusions from each user's account, at first spybot seemed to forget them when I logged as another user, but I re-added them from every account even from the default xp admin account and perseverance finally won... now spybot both scans for the history tracks and remembers the products exclusions. It would probably have taken less time reinstalling (providing the reinstall would have cleaned up all the said files, which I have not tested) but then we would have learned nothing
However I still have a few questions. Might be a different topic but not sure if related to the previous situation so I'll ask here. The first regarding the system internals exclusions. Spybot remembers those exclusions if I only run it from the same user account... but if in the meantime another user opened the software, then spybot forgets the system internals exclusions. I mean even if they make no change to the system internals exclusions and don't run the scan either, even if they stay in easy mode and do nothing at all and immediately close spybot after being warned they are not using an admin account, then the products exclusions stay but the system internals exclusions disappear (not only for this user, but for the admin account as well) and I have to re-add them again when I later run spybot from the account that has administrative privileges (the system internals page is blank so I have to run a system internal scan to re-add the said exclusions). This is to say almost every time, as for security reasons I had asked the other users to log mainly with normal user account and try power user account if a specific software they needed to run would not function for normal user, and only go to the admin account if absolutely necessary. I can live with it though, I just have to save a text file mentionning the exceptions I had previously authorised, and use it to refresh my memory about which detections I had previously chosen to be ignored. But now I wonder if I should delete the spybot shortcut from the other accounts to force the other users to log into the account with admin privileges everytime they want to run a check (but then it might mean that they would think of spybot less often then if they saw a shortcut on their desktop). Of course I presume that if I run update and immunisation and scans from under any account that has administrative privileges, it would also update and immunize and scan all other accounts on the same computer, right ?
When using an account which does not have admin privileges, and trying to open the tea time page, I am warned that I don't have the rights to do it, but then spybot lets me do it nevertheless, and even lets me activate spybot from there! wonder why it lets me do it after telling me I have no right to ...
Speaking of tea-timer, when I want to log in from a different account, I am asked to authorize the change of default user ... if I deny then it keeps asking until I authorize... but even if I check 'remember' it will ask again next time I want to switch accounts. Just as it also asks everytime for SchedLgU.Txt and ntbtlog.txt (when I ask to clean after a scan, and then upon reboot) even though I authorise every time and say to remember (but in this case I suppose it may be that these files get different id from the date which would mean it's normal?). I can live with it, but other users might get confused and be unsure if they should allow or deny, specially that the msg is in english and they are neither bilingual nor computer savvy. Unfortunately the langage choice becomes active only once the software is fully loaded
Also given spybot also tells me that the immunization is incomplete when I open it from a non-admin account, I wonder if the other accounts are fully protected by spybot providing I immunize from any admin account... because I get this message even if I previously ran spybot with admin privileges under this non-admin account. Tea-Timer always says I have 128360 products blocked and 283740 cotes are known, but then it says the same even from the account with admin privileges so I suppose I don't have to worry about that? But is the immunization fully active in the background for all users, if I only did it from one of the admin accounts? or would it be safer, despite the fact we have a home network and a full time connection, to always work from an administrative account in order to be fully protected by spybot? I'd prefer the admin account to be used only when strickly necessary in order to protect my sensitive and system files both from potential hackers and from inexperimented but sometimes daring or curious users
Sorry for such a long post and all those questions ... but be assured that I don't intend to bug you often, it's the very first time in 20 years that I resort to posting on a forum! I fully appreciate your help, and consider spybot as one of the very few softwares I strongly recommend (and I specially appreciate the fact that it works for both newer and older OS... not everyone can afford to just throw old equipment to the garbage and they still need these oldies to be protected as best as possible, and spybot fortunately does a good job at it, thus offering protection to the entire web). I'm not rich and most of the computers I work on belong to others who ask for my help, but spybot is one of the few softwares I would not go without, and because the same version still works for all OS from 95 to Vista and is still free, for those two reasons I consider it worth to stick to and even give a donation for, and there are no more than 2 or 3 softwares I'd say the same about; I also appreciate that spybot tries to help the inexperienced user but also lets one choose for themselves, contrary to other products who try to force their own choices on us. You mention Trendmicro and McAfee as sometimes deserving to be considered pups but they're not the only ones unfortunately, I'd say Microsoft is getting to be one of the worst and if it was not that it has become almost impossible to avoid all of their products completely I'd say they often deserve to be included in the PUPs ;-). Spybot still is easy to use even for a newbie, and respects the user's rights to be protected no matter their present financial situation and to have control over their own computer, and I like that
Thanks for the great work! I was specially amazed that you were so prompt to help me out in this forum even though my problem was not as urgent as others, be assured that it's more than appreciated!
SOLVED! Thanks a bunch MD, the history scan is now back. In fact I should say that spybot seemed to have brought the history back by itself after I ran the software under other users' accounts in both normal and safe modes (the history had remained available from other accounts). However, it seemed to forget the exclusions every time I had run the software from within another account. I deleted the file as you said, and had to re-add the exclusions from each user's account, at first spybot seemed to forget them when I logged as another user, but I re-added them from every account even from the default xp admin account and perseverance finally won... now spybot both scans for the history tracks and remembers the products exclusions. It would probably have taken less time reinstalling (providing the reinstall would have cleaned up all the said files, which I have not tested) but then we would have learned nothing
However I still have a few questions. Might be a different topic but not sure if related to the previous situation so I'll ask here. The first regarding the system internals exclusions. Spybot remembers those exclusions if I only run it from the same user account... but if in the meantime another user opened the software, then spybot forgets the system internals exclusions. I mean even if they make no change to the system internals exclusions and don't run the scan either, even if they stay in easy mode and do nothing at all and immediately close spybot after being warned they are not using an admin account, then the products exclusions stay but the system internals exclusions disappear (not only for this user, but for the admin account as well) and I have to re-add them again when I later run spybot from the account that has administrative privileges (the system internals page is blank so I have to run a system internal scan to re-add the said exclusions). This is to say almost every time, as for security reasons I had asked the other users to log mainly with normal user account and try power user account if a specific software they needed to run would not function for normal user, and only go to the admin account if absolutely necessary. I can live with it though, I just have to save a text file mentionning the exceptions I had previously authorised, and use it to refresh my memory about which detections I had previously chosen to be ignored. But now I wonder if I should delete the spybot shortcut from the other accounts to force the other users to log into the account with admin privileges everytime they want to run a check (but then it might mean that they would think of spybot less often then if they saw a shortcut on their desktop). Of course I presume that if I run update and immunisation and scans from under any account that has administrative privileges, it would also update and immunize and scan all other accounts on the same computer, right ?
When using an account which does not have admin privileges, and trying to open the tea time page, I am warned that I don't have the rights to do it, but then spybot lets me do it nevertheless, and even lets me activate spybot from there! wonder why it lets me do it after telling me I have no right to ...
Speaking of tea-timer, when I want to log in from a different account, I am asked to authorize the change of default user ... if I deny then it keeps asking until I authorize... but even if I check 'remember' it will ask again next time I want to switch accounts. Just as it also asks everytime for SchedLgU.Txt and ntbtlog.txt (when I ask to clean after a scan, and then upon reboot) even though I authorise every time and say to remember (but in this case I suppose it may be that these files get different id from the date which would mean it's normal?). I can live with it, but other users might get confused and be unsure if they should allow or deny, specially that the msg is in english and they are neither bilingual nor computer savvy. Unfortunately the langage choice becomes active only once the software is fully loaded
Also given spybot also tells me that the immunization is incomplete when I open it from a non-admin account, I wonder if the other accounts are fully protected by spybot providing I immunize from any admin account... because I get this message even if I previously ran spybot with admin privileges under this non-admin account. Tea-Timer always says I have 128360 products blocked and 283740 cotes are known, but then it says the same even from the account with admin privileges so I suppose I don't have to worry about that? But is the immunization fully active in the background for all users, if I only did it from one of the admin accounts? or would it be safer, despite the fact we have a home network and a full time connection, to always work from an administrative account in order to be fully protected by spybot? I'd prefer the admin account to be used only when strickly necessary in order to protect my sensitive and system files both from potential hackers and from inexperimented but sometimes daring or curious users
Sorry for such a long post and all those questions ... but be assured that I don't intend to bug you often, it's the very first time in 20 years that I resort to posting on a forum! I fully appreciate your help, and consider spybot as one of the very few softwares I strongly recommend (and I specially appreciate the fact that it works for both newer and older OS... not everyone can afford to just throw old equipment to the garbage and they still need these oldies to be protected as best as possible, and spybot fortunately does a good job at it, thus offering protection to the entire web). I'm not rich and most of the computers I work on belong to others who ask for my help, but spybot is one of the few softwares I would not go without, and because the same version still works for all OS from 95 to Vista and is still free, for those two reasons I consider it worth to stick to and even give a donation for, and there are no more than 2 or 3 softwares I'd say the same about; I also appreciate that spybot tries to help the inexperienced user but also lets one choose for themselves, contrary to other products who try to force their own choices on us. You mention Trendmicro and McAfee as sometimes deserving to be considered pups but they're not the only ones unfortunately, I'd say Microsoft is getting to be one of the worst and if it was not that it has become almost impossible to avoid all of their products completely I'd say they often deserve to be included in the PUPs ;-). Spybot still is easy to use even for a newbie, and respects the user's rights to be protected no matter their present financial situation and to have control over their own computer, and I like that
Thanks for the great work! I was specially amazed that you were so prompt to help me out in this forum even though my problem was not as urgent as others, be assured that it's more than appreciated!
md usa spybot fan
Spybot Advisor Team [Retired]
chercheur:
re: Exclusion lists being cleared.
I had mentioned before that Spybot protects the exclusion files from alteration by malware and deletes all entries if the file is changed outside of Spybot. Well there is also defect in that protection scheme that causes all the entries to deleted when running Spybot from two or more users. The files themselves are stored in a common location for all users but the controls that protect the files from alteration are store for each user. It is like a case were the left hand doesn't what the right hand is doing. When you change one of the exclusion files from one user and then start Spybot under another user the protection controls are out of synchronization and the entries are removed from the exclusion file as if malware had made the initial change.
re: Change in the "DefaultUserName" change.
Please see the discussion in the following thread concerning the "DefaultUserName" change:
Unlike in the past, all accounts should be protected when you immunize from the administrator account. The most likely cause of immunization being reported as incomplete from a limited account is because the limited account does not have the necessary privileges to see the registry entries involved.
What "Profiles" (categories) are being reported as incomplete?
re: Exclusion lists being cleared.
I had mentioned before that Spybot protects the exclusion files from alteration by malware and deletes all entries if the file is changed outside of Spybot. Well there is also defect in that protection scheme that causes all the entries to deleted when running Spybot from two or more users. The files themselves are stored in a common location for all users but the controls that protect the files from alteration are store for each user. It is like a case were the left hand doesn't what the right hand is doing. When you change one of the exclusion files from one user and then start Spybot under another user the protection controls are out of synchronization and the entries are removed from the exclusion file as if malware had made the initial change.
re: Change in the "DefaultUserName" change.
Please see the discussion in the following thread concerning the "DefaultUserName" change:
- Tea Timer 1.6.0.30 not running on XPpro SP3 as User
http://forums.spybot.info/showthread.php?t=45749
Unlike in the past, all accounts should be protected when you immunize from the administrator account. The most likely cause of immunization being reported as incomplete from a limited account is because the limited account does not have the necessary privileges to see the registry entries involved.
What "Profiles" (categories) are being reported as incomplete?
MD USA SPYBOT FAN:
Thanks again for your time.
--
re: Exclusion lists being cleared.
quote: "the protection controls are out of synchronization"
Yes, but seems to be impossible to synchronize them... For the products exclusions it involved time but it was rather easy to do... ( I lost them again tonight while checking all account regarding the immunisation warnings, but going through all the accounts one after the other to re-add them has done the trick, even after a reboot they were still there). For the system internals however the scan results are different... as admin I get 5 results, but when logged on as a user with less privileges I get about 20 results (mostly about location of uninstall files... I guess spybot expects to find them in the same user profile but the softwares are installed by the admin account so ... ). Thus I presume it is impossible to synchronize the system internals, and thus I'll just have to live with it and exclude anew each time if I let the other users the possibility of opening spybot from within their account. I could hide the shortcuts from their desktop and start menu, but why I hesitate is that I'm not always there and I figured that if they see the shortcut they would at least think of running a scan once in a while... I thought it's better to get partial results and repairs than no scanning at all and maybe they'd learn that when they see this message about missing privileges they should switch to the admin account but only for the purpose of running the scan... But once logged on, one tends to forget under which account they are logged and run other softwares without switching user name, which might be a potential hazard but also create lack of synchronization in other softwares as well... I can see them having part of their emails in every user profile! Nice mess LOL (it's the same email account thus it would be possible to download from any profile, but could make it difficult to retrieve old emails).
Oh well, maybe some day Spybot will be able to be fully run by multiple users, without loosing the compatibility with older softwares In the meantime I guess we can live with those limitations as long as you can assure me that all accounts are fully protected full time even if spybot is never opened from under certain accounts.
--
re: Change in the "DefaultUserName" change.
Thanks for the link. Even though this user is running SP3 while I still run SP2, the situation is the same, and there is presently no solution, given his present last post (post number 6) states "getting SBSD to 'remember' the registry change only works if you reboot back to the same User profile each time. As soon as you logon as something else you change the key back and up pops the registry change warning in my case." I can confirm, it's exactly what it does here (although on a very few occasions it did not pop up for the admin account, it did most other times, and seems to always pop up when a non-admin account is trying to log). So is there or is there not a way to force Tea-Timer to silently accept the change of user as long as the change is one that has been accepted before? If not, then so be it... at least we're getting protection and it's not a huge issue. Specially that if the change is refused, spybot keeps nagging for an answer, so one would eventually either switch to another profile or accept the change... so either way there would be no harm and we can live with that for the time being. The biggest problem about it is that these messages are by default in english only, even if another langage option has been selected from withing spybot, some complain that they are confused by the cryptic registry key messages but the difficulty is even greater for people who don't understand english.
--
re: Immunization.
quote: "all accounts should be protected" "most likely cause of immunization being reported as incomplete from a limited account is because the limited account does not have the necessary privileges to see the registry entries involved"
Yes, from what I saw tonight it seems to be exactly what's happening. The items that I could see as non protected in the immunization window were some IE 64 bits items belonging to other users, so I would tend to agree with you that the protection is there but that the registry key cannot be fully viewed from limited accounts.
Great! as long as everyone is fully protected full time, all is well. Thanks for the explanation.
But do you mean the immunisation is there providing I previously immunized with admin privileges? if the limited account cannot see the registry keys, I presume it cannot update them either, and thus the immunisation would really be incomplete if done through a limited account, am I right? it seems to be what the software says...
Please reassure me... if I am not running spybot as admin and nevertheless try to immunize, am I reducing the immunisation level to the items that a limited user can have access to? or do I still keep all the previous full immunisation but am only unable to see the registry keys that confirm so and to upgrade immunisation on those same keys? because it's not too much of a huge problem if I still keep the same level of protection I had been granted as admin and loose none of it, but it would be a problem if by trying to use the option while not an admin I'd in fact loose some protection I previously had until I run again as admin! It has reassured me when you said that once I immunize as admin I am in fact fully immunising all accounts, but I suppose that it would not be so if I tried to immunise while not having admin privileges, right? or would it affect all accounts nevertheless at least in the keys the limited account has access to?
I admit that I have Spybot set to immunize on start-up if there has been an update. Tonight there was no update, and it is not set to check for updates by itself, but maybe it nevertheless tries to immunize or at least check the immunization status, given on some accounts it gives me the "incomplete immunisation" warning while loading? I have not had time to check if I would receive the "incomplete immunisation" message while loading if I had disabled the "immunize if updated" option. I had set this option active because other users tend to still be a bit confused about the different steps and thus tend to forget to immunize. Would it be better to desactivate it and rely on manual immunisation?
You asked: "What "Profiles" (categories) are being reported as incomplete? "
The "GUEST group" and the "LIMITED USER group" both give me the "incomplete immunisation" warning while loading, and in both these groups the immunisation page also mentions 20387 unprotected items. The POWER USER group and the ADMIN group do not give me that warning while loading, and the immunisation page mentions 0 unprotected items, but different numbers for protected items.
As for the protected items, the immunisation page says 132994 protected items when I run from the default xp guest account, 102564 protected items when I run from either the user-created guest account (which is rather in-between guest and user, having been granted specific privileges) or from the "limited user" account (which also has slightly more privileges than the standard limited user) or from the "power user" account. Whether I run directly from the admin accounts or run them in the other profiles by right-click, when running as admin I get 356647 protected when I run from the user-created admin account, and 387079 protected when I run from the hidden default xp admin account.
--
Thanks again MD, you're really giving a great service.
Thanks again for your time.
--
re: Exclusion lists being cleared.
quote: "the protection controls are out of synchronization"
Yes, but seems to be impossible to synchronize them... For the products exclusions it involved time but it was rather easy to do... ( I lost them again tonight while checking all account regarding the immunisation warnings, but going through all the accounts one after the other to re-add them has done the trick, even after a reboot they were still there). For the system internals however the scan results are different... as admin I get 5 results, but when logged on as a user with less privileges I get about 20 results (mostly about location of uninstall files... I guess spybot expects to find them in the same user profile but the softwares are installed by the admin account so ... ). Thus I presume it is impossible to synchronize the system internals, and thus I'll just have to live with it and exclude anew each time if I let the other users the possibility of opening spybot from within their account. I could hide the shortcuts from their desktop and start menu, but why I hesitate is that I'm not always there and I figured that if they see the shortcut they would at least think of running a scan once in a while... I thought it's better to get partial results and repairs than no scanning at all and maybe they'd learn that when they see this message about missing privileges they should switch to the admin account but only for the purpose of running the scan... But once logged on, one tends to forget under which account they are logged and run other softwares without switching user name, which might be a potential hazard but also create lack of synchronization in other softwares as well... I can see them having part of their emails in every user profile! Nice mess LOL (it's the same email account thus it would be possible to download from any profile, but could make it difficult to retrieve old emails).
Oh well, maybe some day Spybot will be able to be fully run by multiple users, without loosing the compatibility with older softwares
In the meantime I guess we can live with those limitations as long as you can assure me that all accounts are fully protected full time even if spybot is never opened from under certain accounts.--
re: Change in the "DefaultUserName" change.
Thanks for the link. Even though this user is running SP3 while I still run SP2, the situation is the same, and there is presently no solution, given his present last post (post number 6) states "getting SBSD to 'remember' the registry change only works if you reboot back to the same User profile each time. As soon as you logon as something else you change the key back and up pops the registry change warning in my case." I can confirm, it's exactly what it does here (although on a very few occasions it did not pop up for the admin account, it did most other times, and seems to always pop up when a non-admin account is trying to log). So is there or is there not a way to force Tea-Timer to silently accept the change of user as long as the change is one that has been accepted before? If not, then so be it... at least we're getting protection and it's not a huge issue. Specially that if the change is refused, spybot keeps nagging for an answer, so one would eventually either switch to another profile or accept the change... so either way there would be no harm and we can live with that for the time being. The biggest problem about it is that these messages are by default in english only, even if another langage option has been selected from withing spybot, some complain that they are confused by the cryptic registry key messages but the difficulty is even greater for people who don't understand english.
--
re: Immunization.
quote: "all accounts should be protected" "most likely cause of immunization being reported as incomplete from a limited account is because the limited account does not have the necessary privileges to see the registry entries involved"
Yes, from what I saw tonight it seems to be exactly what's happening. The items that I could see as non protected in the immunization window were some IE 64 bits items belonging to other users, so I would tend to agree with you that the protection is there but that the registry key cannot be fully viewed from limited accounts.
Great! as long as everyone is fully protected full time, all is well. Thanks for the explanation.
But do you mean the immunisation is there providing I previously immunized with admin privileges? if the limited account cannot see the registry keys, I presume it cannot update them either, and thus the immunisation would really be incomplete if done through a limited account, am I right? it seems to be what the software says...
Please reassure me... if I am not running spybot as admin and nevertheless try to immunize, am I reducing the immunisation level to the items that a limited user can have access to? or do I still keep all the previous full immunisation but am only unable to see the registry keys that confirm so and to upgrade immunisation on those same keys? because it's not too much of a huge problem if I still keep the same level of protection I had been granted as admin and loose none of it, but it would be a problem if by trying to use the option while not an admin I'd in fact loose some protection I previously had until I run again as admin! It has reassured me when you said that once I immunize as admin I am in fact fully immunising all accounts, but I suppose that it would not be so if I tried to immunise while not having admin privileges, right? or would it affect all accounts nevertheless at least in the keys the limited account has access to?
I admit that I have Spybot set to immunize on start-up if there has been an update. Tonight there was no update, and it is not set to check for updates by itself, but maybe it nevertheless tries to immunize or at least check the immunization status, given on some accounts it gives me the "incomplete immunisation" warning while loading? I have not had time to check if I would receive the "incomplete immunisation" message while loading if I had disabled the "immunize if updated" option. I had set this option active because other users tend to still be a bit confused about the different steps and thus tend to forget to immunize. Would it be better to desactivate it and rely on manual immunisation?
You asked: "What "Profiles" (categories) are being reported as incomplete? "
The "GUEST group" and the "LIMITED USER group" both give me the "incomplete immunisation" warning while loading, and in both these groups the immunisation page also mentions 20387 unprotected items. The POWER USER group and the ADMIN group do not give me that warning while loading, and the immunisation page mentions 0 unprotected items, but different numbers for protected items.
As for the protected items, the immunisation page says 132994 protected items when I run from the default xp guest account, 102564 protected items when I run from either the user-created guest account (which is rather in-between guest and user, having been granted specific privileges) or from the "limited user" account (which also has slightly more privileges than the standard limited user) or from the "power user" account. Whether I run directly from the admin accounts or run them in the other profiles by right-click, when running as admin I get 356647 protected when I run from the user-created admin account, and 387079 protected when I run from the hidden default xp admin account.
--
Thanks again MD, you're really giving a great service.
md usa spybot fan
Spybot Advisor Team [Retired]
chercheur:
Specifically what "Profiles" (items in the listing) are being reported as having unprotected immunization items and from which accounts (limited user and guest)? i.e.
Internet Explorer (32 bit)
\SOFTWARE (Cookies)
\SOFTWARE (Domains)
\SOFTWARE (IPs)
\SOFTWARE (Plugins)
Etc.
Specifically what "Profiles" (items in the listing) are being reported as having unprotected immunization items and from which accounts (limited user and guest)? i.e.
Internet Explorer (32 bit)
\SOFTWARE (Cookies)
\SOFTWARE (Domains)
\SOFTWARE (IPs)
\SOFTWARE (Plugins)
Etc.
MD USA SPYBOT FAN:
Sorry I had misunderstood your question!
The items that show as unprotected are in the section "Internet Explorer (32/64 bit):
(Cookies)
(Domains)
(IPs)
(Secure Domains)
As for the users to which these items refer... what can I say... I'm somewhat confused myself, as spybot seems to be acting a bit erratic!
One thing though: I can confirm that if I disable the "immunise on program start if the software has been updated" option, then I don't receive the warnings while it is loading (I still receive them when I go to the immunisation page though) so the warning during loading of the program is really because it's trying to run an immunisation whether or not there has been an update (but then I wonder why the settings specify "immunize IF the program has been updated").
Now here's why I say it's having an erratic or rather unpredictable behaviour.
I was telling you that I did not receive the warning while loading from the power user and admin accounts... in fact I had written from the limited user and admin, but then it puzzled me because of course the limited user has less rights then the power user so I went back to double-check and it was now the limited user who showed the warning and not the power user, thus I edited my reply to say that the warning did not show while loading from the power user and admin accounts. Well an hour ago I tried several times and each time I now received that warning from the power user account but not anymore from the limited user account (which seemed weird given the power user has more rights then the limited user)! Now after an update I receive that warning during loading from ALL accounts except those from the ADMIN group. And there is more...
I can nevertheless confirm that the "unprotected items" do not refer to the user who is actually running the program, but to one or two other users, however the user(s) these items refer to are not always the same, thus the difference in the number of unprotected items, the number remain the same for each item but depending on the number of users that are "seen" then the total number differs.
An hour ago the limited user (when running the program from that account) showed 0 unprotected items and 102562 protected. After an update it now shows 41618 unprotected items and 104672 protected (because now it makes a reference to both admin accounts, while it did not make any reference to any other account an hour ago).
The items that showed as unprotected ... an hour ago they referred to the "standard user" which was always (at the time) the only one that was "seen" besides the account that was running... After an update of the definitions, the standard user is not mentionned at all when running from other accounts, but both admin accounts are now showing and the unprotected items now refer to both the admin accounts.
I wonder why it is that spybot does not always "see" the same user related keys... I first thought maybe it's seeing the last user that has run the program, but it is not the case, then I thought maybe the last user who tried to run an immunisation (whether fully successful or not) but it is not the case either... I have no explanation why the user, or rather the group, that is mentionned as not fully protected, has changed.
The "default xp guest account" sees the admins as being protected in firefox, but the other accounts only see themselves in firefox.
The items are always the four items of the IE(32/64 bit) group mentionned above, and the numbers related to each of them are always the same no matter what user is mentionned:
other_user_name (Cookies) 193 unprotected (after update 193 also)
other_user_name (Domains) 10079 unprotected (after update 10290)
other_user_name (IPs) 36 unprotected (after update 36 also)
other_user_name (Secure Domains) 10079 unprotected (after update 10290)
Given the numbers and items are always similar, and that when I log as admin the same items and same numbers show as protected for each and every user of the computer, then I tend to agree with you that the immunisation is there and should be complete, but that what belongs to a different user is not necessary seen by a non-admin user, and would not actually be needed either, right? ...
As a note, tonight I updated the definitions and immunized directly from an admin account... Given that account should rarely be used, what would be better, to use or not to use the automatic "check for updates" and "immunize if updated" options, given I presume the program will more often than not be opened from a non-admin account (disabling the automatic immusation option for one user disables it for all users).
__
A quick question on another topic... the "logs" in the tracks usage request for removal a run-once change... I accept, and on reboot it asks me permission to delete this key, and I accept again given it's the key that only needed to run once, but if I immediately run the tracks scanning again, there are still 4 files in the logs ... Maybe you can confirm if I should have accepted both prompts as I did, and if it's normal for those files to still show, if the tracks have been deleted but the files have been recreated for the purpose of adding further data later, or if they simply cannot be erased or else maybe I myself prevented the erasing when accepting the after-reboot prompt (both before and after reboot I clicked on remember this decision). The files names in the scan are each followed by the mention (save the file, nothing done) and the files are:
Log: Activity: SchedLgU.Txt
Log: Activity: ntbtlog.txt
Log: Shutdown: System32\wbem\logs\wbemess.log
Log: Shutdown: System32\wbem\logs\wbemprox.log
(I was logged as admin and after reboot logged back as admin).
Sorry I had misunderstood your question!
The items that show as unprotected are in the section "Internet Explorer (32/64 bit):
(Cookies)
(Domains)
(IPs)
(Secure Domains)
As for the users to which these items refer... what can I say... I'm somewhat confused myself, as spybot seems to be acting a bit erratic!
One thing though: I can confirm that if I disable the "immunise on program start if the software has been updated" option, then I don't receive the warnings while it is loading (I still receive them when I go to the immunisation page though) so the warning during loading of the program is really because it's trying to run an immunisation whether or not there has been an update (but then I wonder why the settings specify "immunize IF the program has been updated").
Now here's why I say it's having an erratic or rather unpredictable behaviour.
I was telling you that I did not receive the warning while loading from the power user and admin accounts... in fact I had written from the limited user and admin, but then it puzzled me because of course the limited user has less rights then the power user so I went back to double-check and it was now the limited user who showed the warning and not the power user, thus I edited my reply to say that the warning did not show while loading from the power user and admin accounts. Well an hour ago I tried several times and each time I now received that warning from the power user account but not anymore from the limited user account (which seemed weird given the power user has more rights then the limited user)! Now after an update I receive that warning during loading from ALL accounts except those from the ADMIN group. And there is more...
I can nevertheless confirm that the "unprotected items" do not refer to the user who is actually running the program, but to one or two other users, however the user(s) these items refer to are not always the same, thus the difference in the number of unprotected items, the number remain the same for each item but depending on the number of users that are "seen" then the total number differs.
An hour ago the limited user (when running the program from that account) showed 0 unprotected items and 102562 protected. After an update it now shows 41618 unprotected items and 104672 protected (because now it makes a reference to both admin accounts, while it did not make any reference to any other account an hour ago).
The items that showed as unprotected ... an hour ago they referred to the "standard user" which was always (at the time) the only one that was "seen" besides the account that was running... After an update of the definitions, the standard user is not mentionned at all when running from other accounts, but both admin accounts are now showing and the unprotected items now refer to both the admin accounts.
I wonder why it is that spybot does not always "see" the same user related keys... I first thought maybe it's seeing the last user that has run the program, but it is not the case, then I thought maybe the last user who tried to run an immunisation (whether fully successful or not) but it is not the case either... I have no explanation why the user, or rather the group, that is mentionned as not fully protected, has changed.
The "default xp guest account" sees the admins as being protected in firefox, but the other accounts only see themselves in firefox.
The items are always the four items of the IE(32/64 bit) group mentionned above, and the numbers related to each of them are always the same no matter what user is mentionned:
other_user_name (Cookies) 193 unprotected (after update 193 also)
other_user_name (Domains) 10079 unprotected (after update 10290)
other_user_name (IPs) 36 unprotected (after update 36 also)
other_user_name (Secure Domains) 10079 unprotected (after update 10290)
Given the numbers and items are always similar, and that when I log as admin the same items and same numbers show as protected for each and every user of the computer, then I tend to agree with you that the immunisation is there and should be complete, but that what belongs to a different user is not necessary seen by a non-admin user, and would not actually be needed either, right? ...
As a note, tonight I updated the definitions and immunized directly from an admin account... Given that account should rarely be used, what would be better, to use or not to use the automatic "check for updates" and "immunize if updated" options, given I presume the program will more often than not be opened from a non-admin account (disabling the automatic immusation option for one user disables it for all users).
__
A quick question on another topic... the "logs" in the tracks usage request for removal a run-once change... I accept, and on reboot it asks me permission to delete this key, and I accept again given it's the key that only needed to run once, but if I immediately run the tracks scanning again, there are still 4 files in the logs ... Maybe you can confirm if I should have accepted both prompts as I did, and if it's normal for those files to still show, if the tracks have been deleted but the files have been recreated for the purpose of adding further data later, or if they simply cannot be erased or else maybe I myself prevented the erasing when accepting the after-reboot prompt (both before and after reboot I clicked on remember this decision). The files names in the scan are each followed by the mention (save the file, nothing done) and the files are:
Log: Activity: SchedLgU.Txt
Log: Activity: ntbtlog.txt
Log: Shutdown: System32\wbem\logs\wbemess.log
Log: Shutdown: System32\wbem\logs\wbemprox.log
(I was logged as admin and after reboot logged back as admin).
Last edited:
md usa spybot fan
Spybot Advisor Team [Retired]
chercheur:
When a user logs their user registry hive is loaded. In Windows XP it appears that that registry hive stays loaded even when the user logs off.
In the past Spybot could only immunize the user accounts that were loaded which required logging on to each user account to fully immunize those accounts. Spybot now loads a copy of other user registry hives so that from a computer administrator account you can immunize other use accounts to fully immunize without logging into every user account. Spybot unloads the copy of the registry hives it loaded when immunization is completed.
When looking at immunization from a Limited account or Guest account, probably what you are seeing is a combination if what user registry hives are loaded (other users that logged before the current user) or those that Spybot attempted to load as well as what registry hives that account can actually access (which is required to verify immunization).
The code for the immunization process could probably be improved so that if a particular user account cannot actually access another user's registry hive to immunize or verify immunization, it either not list it at all or present question marks or something rather than actual numbers.
_____
Some usage tracks can not be deleted because that are always in use. See:
When a user logs their user registry hive is loaded. In Windows XP it appears that that registry hive stays loaded even when the user logs off.
In the past Spybot could only immunize the user accounts that were loaded which required logging on to each user account to fully immunize those accounts. Spybot now loads a copy of other user registry hives so that from a computer administrator account you can immunize other use accounts to fully immunize without logging into every user account. Spybot unloads the copy of the registry hives it loaded when immunization is completed.
When looking at immunization from a Limited account or Guest account, probably what you are seeing is a combination if what user registry hives are loaded (other users that logged before the current user) or those that Spybot attempted to load as well as what registry hives that account can actually access (which is required to verify immunization).
The code for the immunization process could probably be improved so that if a particular user account cannot actually access another user's registry hive to immunize or verify immunization, it either not list it at all or present question marks or something rather than actual numbers.
_____
Some usage tracks can not be deleted because that are always in use. See:
- Why can I not remove the Sti_Trace.log (or SchedLgU.txt) file?
http://www.safer-networking.org/index.php?page=faq&detail=6
MD USA SPYBOT FAN:
Thank you very much once again. Your explanations were clear. About the numbers, at least they finally allowed us to prove that in fact everything was indeed immunised for every account once the immunisation has been done by an administrator. As for the running processes, I had already followed the advice given by the link to which you pointed me and added Sti_Trace.log to the exclusions... however I had forgotten that this article also mentionned SchedLgU.txt and also I was puzzled about the task scheduler because I do not presently use it and could not see it either in the start-up items (no matter if I looked through spybot or through the bar or through msconfig or through Ctrl-Alt-Del) but after your answer I took a closer look to msconfig and opened the services page... the reason I had not previously found the task scheduler entry was that instead of being loaded through the start-up page of msconfig as on Win98, it is now, on XP, loaded as a service! By clearly mentionning both the process name and its usage, your answer prompted me to search further and allowed me to identify it in the services, and it is indeed running! So everything is explained.
So if I understood well, the immunisation is complete for all users if ran as admin, but if someone tries to run it without administrative rights, the immunisation would also be fully completed for that same user, but not for the others... so I guess that as long as only this limited user normally loads daily, it would be ok for him to run the immunisation process to protect himself, as long as once in a while I run it from as admin to protect all the others. Agreed?
I notice that spybot also suggests to the limited user to use the task scheduler to run the updates and immunisations as admin on a regular basis... Does that mean that the scheduled task would run and fully update and immunise all users even if the user himself is not logged as admin? If so, could you please clearly indicate the steps through which we could configure the task scheduler to make spybot update and immunize the whole computer without actually any human user running as admin? And please confirm also if the scheduler would then, in the event of available updates, simply list them and let the limited user decide which should be downloaded, or if the scheduler would itself download and install all of them? the reason for this last question is that the updater now offers to download and install upgrades as well, rather than simply mentionning as in the past that they are available, and that I have seen on the forums that some had trouble when the upgrade installed automatically and that it was safer to simply download the upgrade manually and then uninstall the previous version before upgrading to the new version.
Thank you very much once again. Your explanations were clear. About the numbers, at least they finally allowed us to prove that in fact everything was indeed immunised for every account once the immunisation has been done by an administrator. As for the running processes, I had already followed the advice given by the link to which you pointed me and added Sti_Trace.log to the exclusions... however I had forgotten that this article also mentionned SchedLgU.txt and also I was puzzled about the task scheduler because I do not presently use it and could not see it either in the start-up items (no matter if I looked through spybot or through the bar or through msconfig or through Ctrl-Alt-Del) but after your answer I took a closer look to msconfig and opened the services page... the reason I had not previously found the task scheduler entry was that instead of being loaded through the start-up page of msconfig as on Win98, it is now, on XP, loaded as a service! By clearly mentionning both the process name and its usage, your answer prompted me to search further and allowed me to identify it in the services, and it is indeed running! So everything is explained.
So if I understood well, the immunisation is complete for all users if ran as admin, but if someone tries to run it without administrative rights, the immunisation would also be fully completed for that same user, but not for the others... so I guess that as long as only this limited user normally loads daily, it would be ok for him to run the immunisation process to protect himself, as long as once in a while I run it from as admin to protect all the others. Agreed?
I notice that spybot also suggests to the limited user to use the task scheduler to run the updates and immunisations as admin on a regular basis... Does that mean that the scheduled task would run and fully update and immunise all users even if the user himself is not logged as admin? If so, could you please clearly indicate the steps through which we could configure the task scheduler to make spybot update and immunize the whole computer without actually any human user running as admin? And please confirm also if the scheduler would then, in the event of available updates, simply list them and let the limited user decide which should be downloaded, or if the scheduler would itself download and install all of them? the reason for this last question is that the updater now offers to download and install upgrades as well, rather than simply mentionning as in the past that they are available, and that I have seen on the forums that some had trouble when the upgrade installed automatically and that it was safer to simply download the upgrade manually and then uninstall the previous version before upgrading to the new version.