I'm already running the later version that Live Update gives me. I'm not home so I can't check whether it's 20.3.1.22 or not (as that hasn't been released to everyone yet), but when I ran LiveUpdate the other day it said there are no updates.
avanip wrote:Morac,
We are looking into this issue internally. I will get in touch with you via Private Message if I need additional information. I will update this thread once I have more updates to share.
Thanks for your patience and continued support of Norton!
Best Regards,
Avani Patel
Core Performance Team
Any progress? I'm still seeing this. I've been hit by it the past few days. Yesterday, I rebooted, slept for a second and then resumed and everything was good, but then when I woke my laptop today after sleeping overnight, it thought it was idle again.
Hi Morac,
I didn't see it mentioned; are you running 20.3.1, or an older version? I've sent you a link to download 20.3.1, if you'd like to try it out. Thanks.
Tony_Weiss wrote:Hi Morac,
I didn't see it mentioned; are you running 20.3.1, or an older version? I've sent you a link to download 20.3.1, if you'd like to try it out. Thanks.
Hi, Tony. With the release of Video Drivers that support Optimus or Enduro technology - especially when dealing with Laptops - the NIS/NAV idle-mode-detect process has a whole new layer of abstraction - which must be negotiated successfully - for idle-detect to work properly. The issues mentioned in the link below may have something to do with the problems mentioned in this thread.
Have a look at the following for more info:
Hope this helps.
twixt wrote:
Tony_Weiss wrote:Hi Morac,
I didn't see it mentioned; are you running 20.3.1, or an older version? I've sent you a link to download 20.3.1, if you'd like to try it out. Thanks.
Hi, Tony. With the release of Video Drivers that support Optimus or Enduro technology - especially when dealing with Laptops - the NIS/NAV idle-mode-detect process has a whole new layer of abstraction - which must be negotiated successfully - for idle-detect to work properly. The issues mentioned in the link below may have something to do with the problems mentioned in this thread.
Have a look at the following for more info:
Hope this helps.
I'm pretty sure it's not related (or at least not in my case) as I don't use a screen saver and I'm not running Optimus or Enduro drivers. My laptop is too old to support those anyway.
NIS's Idle/sleep detection simply seems unreliable in general. Sometimes it shows my laptop as "Sleeping" when it's in standby, other times it says it was active the entire time in standby, other times idle.
I primarily run into the idle detection issue when NIS thinks the computer was sleeping as it will show as active briefly after resuming and then switch to saying it's idle and stay there. If NIS doesn't believe the computer went to sleep, the problem usually doesn't occur. These aren't hard fast rules though as I've seen it successfully recover from "sleeping" and unsuccessfully recover from "active" standby.
Morac wrote:
twixt wrote:
Tony_Weiss wrote:Hi Morac,
I didn't see it mentioned; are you running 20.3.1, or an older version? I've sent you a link to download 20.3.1, if you'd like to try it out. Thanks.
Hi, Tony. With the release of Video Drivers that support Optimus or Enduro technology - especially when dealing with Laptops - the NIS/NAV idle-mode-detect process has a whole new layer of abstraction - which must be negotiated successfully - for idle-detect to work properly. The issues mentioned in the link below may have something to do with the problems mentioned in this thread.
Have a look at the following for more info:
Hope this helps.
I'm pretty sure it's not related (or at least not in my case) as I don't use a screen saver and I'm not running Optimus or Enduro drivers. My laptop is too old to support those anyway.
NIS's Idle/sleep detection simply seems unreliable in general. Sometimes it shows my laptop as "Sleeping" when it's in standby, other times it says it was active the entire time in standby, other times idle.
I primarily run into the idle detection issue when NIS thinks the computer was sleeping as it will show as active briefly after resuming and then switch to saying it's idle and stay there. If NIS doesn't believe the computer went to sleep, the problem usually doesn't occur. These aren't hard fast rules though as I've seen it successfully recover from "sleeping" and unsuccessfully recover from "active" standby.
Hi, Morac. Whether you use a screen saver (or not) is only partially relevant to the issue. There are two levels of sleep management involved. The first is for the stage where the Screen Saver is active (this one is optional). The second is for when the screen is disabled (backlight goes off). The second is a power-management-event, regardless of whether a Screen Saver is activated.
So, regardless of the presence/absence of video-related sleep issues - what you describe in your originating post is a Power Management issue. This is the hardware/software/OS subsystem that controls what Windows "sees" as far as hardware is concerned - as well as what is "awake", what is "asleep", what needs to "wake up", what needs to "go to sleep" - and finally "what does the OS need to remember so that when it comes back out of sleep, it can return the hardware to the state it was in when the OS put that hardware to sleep?".
If any of the "wake up" procedures fail - NIS/NAV (which is a complete slave to the OS in this regard) can only "react" to the Power Management Events that the OS presents for NIS/NAV to "sniff". It is very common, even in older non-Optimus or non-Enduro video drivers - for there to be power-management bugs - as well as other bugs in the System Tray Control Panel Application which cause problems with restarts after LiveUpdate events. Bugs which can mess up the relationship between the reality of power management found in the hardware - and the reflection of that reality in what the OS is presenting to its subsystems.
Missing power-management-event when the system returns from idle? NIS/NAV has no idea it's supposed to "wake up".
Things to check:
1. Are you running the latest BIOS for your laptop? The first and most fundamental aspect of Power Management is BIOS support. If that is wonky - everything else on top of that is working with incorrect or invalid data.
2. Are you running the latest Power Management utilities from HP for your Laptop? All Laptop manufacturers have endless problems with their Power Management utilities. The Laptop manufacturers often get "surprised" by Microsoft Updates that break their Power Management linkages - leading to the need for updated software that works properly now that Microsoft have closed the security holes which older versions of the Laptop Manfactuer's Power Management Software were exploiting to keep track of the link-and-power-status-state of the various hardware/software subsystems.
3. Are you running the latest Drivers for your Hard Disk controller? Again, this is a critical issue because the Hard Disk controller is one of the critical items that must send the proper "wake up" signals to all the various subsystems - and to all the various software on your Laptop - when the system resumes from sleep. This has gotten much much more complex since Sandy Bridge - and there are "gotchas" that can only be fixed by a combination of the latest AHCI/RAID BIOS inserts in the BIOS itself - as well as the latest AHCI/RAID Hard Disk Controller drivers - before all the hardware subsystems and Windows software subsystems "straighten out and fly right".
4. HP, Sony and Lenovo all have dedicated "Live Update" utilities for their own native software packages on their laptops. Have you manually run those utilities to completion - and updated your system with all the "recommended' (not automatically installed) pieces of their software that go with the "critical" updates (the ones the utility flags and says download me Now!)?
5. Then there is the whole issue of Video Drivers. HP and Sony are notorious for not upgrading their Video Drivers for their Laptop products - once those products reach active-mid-life (middle of the way through that product's actual sell-date range). And as we know, Video Driver updates do impact power-management - and thus need to be updated far beyond the level where HP/Sony abandon the user to the vagaries of fate. Ditto for the Power Management utilities (although those tend to get upgraded for newer products, where those updates are applicable to older products as well).
There. Doing that set of Research Tasks ought to keep you busy for a while. Enjoy... 
Note: The above does not necessarily mean NIS is completely blameless in regard to the problems mentioned in your originating post in this thread. It's just that if NIS is working properly - and there are problems as detailed in the above paragraphs of this post - then NIS will react as described as part of the complaints in this thread. Quite correctly so, because NIS is supposed to "follow the lead" of power-management in this regard.
Remember the Engineer's Lament: "Nothing is ever simple..."
Hope this helps your understanding.
I am experiencing the issue complained about by the OP. Norton thinks my PC is idle while I am trying to use it, resulting in everything running slow and sticky while Norton does stuff it calls background tasks. This is annoying as it makes my PC unusable just when I want to be using it. This only started after upgrading from NIS 2012 to NIS 2013. I am experiencing this issue with 20.3.1.22 running on fully patched XP pro SP3 on a Dell laptop with the most recent drivers that Dell provide. NIS 2012 was the best ever but I need to get this problem with 2013 sorted out or I shan't be renewing my subscription (on 6 PCs in total). I am surprised to see that the issue was reported several months ago but having read the thread it seems it is still not fixed. Liveupdate says no updates or restarts required - all fully up to date. Please fix this Norton!
Here's a new twist. Today the background processes kicked off 10 minutes after I resumed from Standby. which it should for Live Update, but the Norton Task window said they ran while idle and all the tasks ran (including ones that should only run while the system is idle). Tthe Performance window showed that the system was not idle though.
So basically Norton is showing the system is not idle, but decided to run all the background processes anyway and said it ran them while idle.
Morac wrote:Here's a new twist. Today the background processes kicked off 10 minutes after I resumed from Standby. which it should for Live Update, but the Norton Task window said they ran while idle and all the tasks ran (including ones that should only run while the system is idle). The Performance window showed that the system was not idle though.
So basically Norton is showing the system is not idle, but decided to run all the background processes anyway and said it ran them while idle.
Hi, Morac. NIS has a "safety feature" - which pushes the priority of QuickScan from "Idle" to "Shared" if a QuickScan has not been performed in a timeframe NIS considers a risk to System safety. This is normal and correct.
Here is my understanding of the situation. Scenario is as follows:
1. User puts the Computer to sleep, or the Computer goes to sleep due to inactivity. The machine sleeps for 6 hours or more.
2. User touches keyboard, mouse, etc - whatever is required to bring Computer (Eg: Laptop) out of sleep. Computer wakes up.
3. NIS sees that "Live Update" is very much out-of-date - and performs a Live-Update in order to bring the status of the NIS installation up to current operational parameters.
4. Because the Computer has been in Standby or Off for a substantial period of time - it is almost certain that the Live Update performed upon resume will contain an updated set of VirusDefs.
5. Upon completion of any "Live Update" with a set of VirusDefs - NIS will want to run a QuickScan. Because - in this particular case - the QuickScan is also far out-of-date - NIS elevates the priority of the QuickScan from "Idle" to "Shared" - after the Idle Timeout Delay has elapsed - thus the QuickScan runs as a background process when the machine is not idle. This is also normal and correct.
6. Once the machine is in its normal working state, with an up-to-date QuickScan, the next subsequent LiveUpdate Event which contains a VirusDef update (which may be 6 or 7 LiveUpdate cycles down the stack) goes through exactly the same set of checks-for-urgency detailed in item 5 above - and NIS reacts in exactly the same way.
7. If that next set of VirusDef updates occurs within the "safety window" - as far as NIS' monitoring of QuickScan is concerned - the QuickScan will "yield" to user activity as you expect. This is normal and correct.
8. If that next set of VirusDef updates occurs after the "safety window" has expired - as far as NIS' monitoring of QuickScan is concerned - the QuickScan will not "yield" to user activity as you expect. This is also normal and correct.
The reason things work this way is because VirusDefs are not useful until they are applied to the System.
Thus, if circumstance conspires to force NIS "out of the picture" due to standby/hibernation/silent-mode/whatever - NIS will eventually "run out of patience" with being sidelined - and QuickScan will be promoted from "Idle" to "Shared" mode.
QuickScan only yields when a previous QuickScan was performed within the "validity timeframe" that NIS considers to be "reasonably safe". Once that timeframe is exceeded, QuickScan gets "bumped" in priority to the point where it runs - and properly verifies whether the user's System is clean - in order to ensure the user is Secure - regardless of what the user is doing. This is normal and correct.
The only way around the above is to establish a "Quiet Mode" scenario where NIS is instructed to defer a QuickScan "no matter what" - until that program is no longer running on the machine. That this is dangerous to System safety should be self-evident.
Hope this helps your understanding.
twixt wrote:Hi, Morac. NIS has a "safety feature" - which pushes the priority of QuickScan from "Idle" to "Shared" if a QuickScan has not been performed in a timeframe NIS considers a risk to System safety. This is normal and correct.
While that's interesting, it's also completely irrelevant. Regardless if QuickScan was being forced to run because it hadn't run recently, which wasn't the case as it ran yesterday (very out of date for QuickScan is a few days), it wouldn't say it ran while idle and neither would all the other tasks. Tasks only report having run while idle if the system is actually idle when the at ask ran. If it was not, the "Ran During Idle" value is "no".
Morac wrote:
twixt wrote:Hi, Morac. NIS has a "safety feature" - which pushes the priority of QuickScan from "Idle" to "Shared" if a QuickScan has not been performed in a timeframe NIS considers a risk to System safety. This is normal and correct.
While that's interesting, it's also completely irrelevant. Regardless if QuickScan was being forced to run because it hadn't run recently, which wasn't the case as it ran yesterday (very out of date for QuickScan is a few days), it wouldn't say it ran while idle and neither would all the other tasks. Tasks only report having run while idle if the system is actually idle when the at ask ran. If it was not, the "Ran During Idle" value is "no".
My understanding is QuickScan "out of date" priority has been promoted to a shorter timeframe than a couple of days - as part of the latest Engine updates. I don't know the exact value - but I suspect it is now less than 24 hours and maybe less than 12.
Considering that I've seen VirusDef updates as often as 3 times a day lately - and considering the virulence of the latest malware - and considering Microsoft's holes in IE over the past few months and the holes in Flash and Java over the past few months have essentially created "open season" for drive-by-shootings when visiting malware-infested websites - I think it is utterly necessary for QuickScan to be rendered "out of date" in our current computing environment far more quickly than a matter of days.
There are a couple of reasons why the "Ran During Idle" tag may be incorrect. First, it may occur because the tag is reflecting the previous run of QuickScan and not the current run. I do not know what mechanism Symantec is using to "keep tabs" on the "Ran During Idle" tag. The mechanism may have changed in order to lessen the NIS CPU load when NIS is "idling" - which may impact how quickly the tag is updated after the current QuickScan has completed.
Or, it may be a bug. It's good that you reported your findings here - because if it's a bug it needs attention. And even if it is just "slow status updating" - that should be attended to as well.
As per all the other Power-Management "glitches" mentioned in this thread - which seem to be slowly getting sorted out as part of the LiveUpdate process - as well as users understanding the rest of their software stack needs to be right if NIS is going to do its Power-Management gyrations correctly as well - we all continue to monitor the situation and report on our findings. This is good - since holding Symantec to a higher standard of quality assurance seems to be a necessary requirement these days.
However, it is still important to understand that Power-Management is a co-operative venture between many disparate hardware and software vendors - and that Device Driver design for this "Post-Sandy-Bridge" stuff is only just coming out of diapers. 
Gawd only knows what's going to happen when Haswell hits...
You’re focusing too much on Quick Scan. From my experience even things like Live Update will only report that they ran during idle, if the system actually was idle. As you can see from my screen shot, all of the ones that ran on 11/12 reported as running during idle, including the Pulse Update that ran just before I took the screen shot.
I lined up the performance graph along with the norton tasks and system clock to show the discrepancy.