You're right, Imacri. It doesn't seem to be related to system specs, and it seems Auto Protect does take way too many resources.
On my current desktop, I've had NIS 2010 onwards, right up to the current version.
Having said that, I don't check things specifically unless there's a problem, but in the normal course of events, I haven't noticed any slowing up of my computer with any of the versions.
My specs are nothing spectacular, and I even have integrated graphics on this machine ! 
Just a hint to users who might be wondering if they have the same issue on their computer:
If you see this constant level of "blue" CPU activity in your Norton Performance graph during idles that cannot be accounted for (i.e., you click in this area of the graph and the pop-up says "No Activity" or something like "1% NIS.exe" or "1% svchost.exe" but doesn't account for the remaining 15% or so of CPU activity) and you monitor your system idles in real time with Task Manager, the name of the responsible process is not NIS.exe or ccSvcHst.exe.
SYSTEM is the process responsible for this "missing" idletime CPU activity, as shown in screenshots in message # 1 and message # 5. If you dig deeper with a utility like Sysinternal's Process Explorer and examine the different threads running under the parent SYSTEM process (see the Microsoft support article here), you should see Symantec's Real-time AutoProtect SRTSP.SYS as the cause of this high activity.
The most noticeable symptom of this disk thrashing by SRTSP.SYS during idles (aside from the constant blinking of my HDD indicator light), is a significant increase in my CPU and HDD temperatures which in turn cause my cooling fan to run constantly during idles. Once I take my system out of idle the disk thrashing stops and there is no noticeable impact on my system performance as long as I'm working on my computer.
------------
MS Windows Vista Home Premium 32-bit SP2 * Firefox 26.0 * IE 9.0 * NIS 2013 v. 20.4.0.40
HP Pavilion dv6835ca, Intel Core2Duo CPU T5550 @ 1.83 GHz, 3.0 GB RAM, NVIDIA GeForce 8400M GS
Hello
Arter looking over an article about this sort of thing, may I recommend that you stop off at one of the malware removal sites to make sure that it isn't some malware that is masqurading as that system. This would be just to eliminate the possibillity that it is not malware which is causing this to happen. Since it seems to happen after an idle quick scan, perhaps it is happening because the scan is either finding something or perhaps it is some sort of malware that is causing this to happen. I am in no way saying that malware is the culprit. Stopping off at one of the free malware removal places could possibly rule out malware as being the root cause of this problem. I'm thinking of this also since it only seems to show up in a few computer configurations of those people who come to the forums. Glanced over this site just to see what they had to mention. I am not recommending to do what was said to be done in that site.This site did mention the possibiility of malware. http://www.fixpcdll.com/repair-dll-exe-errors/srtsp.sys-fix-srtsp.sys-error.html Under no circumstances am I recommending to do anything mentioned in this article since I am not quallified to determine if malware is the cause nor am I recommending anything in that article to be done to fix the possible problem.
Hi floplot:
I'll keep your suggestion in mind, but my SRTSP.SYS file located at C:\Windows\System32\drivers\NIS\1404000.028\ is digitally signed by Symantec and shows a detection ratio of 0/47 when submitted for analysis at VirusTotal, so I'm reasonably certain that I'm using a legitimate Symantec file.
I'm not discounting the possibility that everyone having this problem has some third-party software running in real-time (e.g., network monitoring software) that causes Symantec AutoProtect to "wake up" and monitor our systems after a Quick Scan, but we won't know until someone at Symantec compares diagnostic logs from our systems to determine if there is a bug in the NIS 20.x and 21.x software.
------------
MS Windows Vista Home Premium 32-bit SP2 * Firefox 26.0 * IE 9.0 * NIS 2013 v. 20.4.0.40
HP Pavilion dv6835ca, Intel Core2Duo CPU T5550 @ 1.83 GHz, 3.0 GB RAM, NVIDIA GeForce 8400M GS
Sorry I can't help.
But I wanted to say that is some excellent detective work you did and backing it up with the screen shots you made clearly documents the problem your seeing.
I also hope it was a simple oversight that Norton items running through "system" are not included on the performace monitor.
Dave
Hi DaveH:
I wish I could take all the credit, but elsewhere identified SRTSP.SYS as the process responsible for this "hidden" CPU and disk I/O activity in NIS 20.x here in Cooloutac's thread titled Norton Performance Monitor back in December 2012, and if I'm not mistaken I think he also posted about this same issue in the Norton 21.0 Public Beta board (which is no longer accessible).
I'm also curious as to why Symantec AutoProtect is running as a thread under the generic SYSTEM process during idles and not under the ccSvcHst.exe or NIS.exe process, but someone from Symantec will have to solve that particular mystery.
------------
MS Windows Vista Home Premium 32-bit SP2 * Firefox 26.0 * IE 9.0 * NIS 2013 v. 20.4.0.40
HP Pavilion dv6835ca, Intel Core2Duo CPU T5550 @ 1.83 GHz, 3.0 GB RAM, NVIDIA GeForce 8400M GS
Both of you deserve a big thanks for your hard work.
I don't think SRTSP.SYS is the only thing that runs under "System". In the past I once had a laptop that the hard drive kept grinding away and the task manager always showed high resources being used for system. It turned out to be something with "Norton Community Watch". I would have mentioned that earlier but I really don't think that would use the real time protection driver.
Dave
Hi,
The point is that SRTSP.SYS should not continue to run during idle time when an idle quick scan finishes.
I'm more or less sure that this prolonged activity has some side-effects in long term for the OS.
It needs to be investigated and resolved.
Regards,
lmacri wrote:
[...]
I'm not discounting the possibility that everyone having this problem has some third-party software running in real-time (e.g., network monitoring software) that causes Symantec AutoProtect to "wake up" and monitor our systems after a Quick Scan, but we won't know until someone at Symantec compares diagnostic logs from our systems to determine if there is a bug in the NIS 20.x and 21.x software.
Hi lmacri
Just a quick clarification; all of my systems are 32-bit and I'm seeing this issue on all of them. My Vista system only started experiencing this issue when I upgraded it from NIS 19 to NIS 20.
At this stage, what we need is some volunteers to test and confirm whether or not they are also seeing this issue. The more users that test for the issue and report their results in this thread the better the outcome will be. I think it's a bug but what we need to establish is whether or not this is a global issue that affects all Norton v20 users and above.
To reproduce under Norton Internet Security 20 and above:
Prerequisite:
Norton Internet Security's default 'Idle Time Out' value of 10 minutes is overly conservative due to the advertised minimum System Requirements to run NIS. Please change this setting to 2 minutes:
This test is dependent on the arrival of a 'Norton Virus Definitions' update via LiveUpdate as it is this update that triggers the Idle Quick Scan that results in the issue described. Please be prepared to leave your system idle for 15 to 30 minutes during this test (if your average Quick Scan only takes a couple of minutes to run, then 15 minutes is fine; otherwise leave it for 30 minutes). Time your testing for the period after you first turn on your computer for the day; the chances of a virus definitions set arriving via LiveUpdate is quite high then.
To reproduce:
Thanks in advance to those Norton Community members who are prepared to test for this issue and report their results.
Hi elsewhere,
I have a fresh installation of NIS 21, (3 days), and it doesn't occur.
I left my pc idle, W7 x64, for an hour and only some windows idle tasks.
Of course the issue you described exists, but it starts to happen after a few days or weeks after installation of NIS.
As mentionned earlier in a post, I stopped to interrupt the prolonged idle activity and it led me to a NIS.exe memory crash at shutdown.
Hopefully, some users will add their input here, because this issue needs to be fixed asap.
Regards,
Hi Apostolos
Things may be a little quiet in this thread, at least until Christmas Day has passed. I think we all know how hectic the lead up to Christmas can be! The last time I asked users to assist with testing an issue, I received a pretty good response from Norton Community members:
In terms of a Symantec response for this issue; the Christmas holiday period naturally applies to Symantec employees as well. By way of background, I'm one of a small group of Norton Community members who always tests Norton Internet Security/Norton 360 PC-based products whenever these products are offered for public beta testing. Symantec knows that when they release these products, that members from this regular beta testing group will then be actively looking for new problems/unresolved issues within these newly released products. Given that, the Norton Product Developers have the ability to make use of the Norton Community Trackers in order to monitor what each member from this beta testing group is posting. These Trackers are RSS Feed Subscriptions, for example:
These RSS Feeds allow the Norton Product Developers to skim read the content of every post made by each of these beta testing group members; if they notice the words 'defect', 'bug', 'unresolved', 'steps to reproduce', etc, in those posts, then it's their cue to take a closer look at the issue raised by the thread in question and to respond to that thread accordingly. Hopefully, the Norton Product Developers are already aware of the issue and that they will acknowledge this by posting whether or not they can reproduce the issue reported in this thread.
In the meantime, however, if Norton Community Members are in a position where they are happy to test for this issue, then I'd ask them to please do so and let us know the results.
Thanks
Hello
I believe that someone mentioned that NIS needs to have the ability to turn off the Idle Quick Scans. Remember that doing so will reduce the level of sceurity of your computer. However, I believe this option already exists for those who want to risk the security of your computers . If you feel that it is important enough to temporarily turn them off, perhaps if you follow what it says here, you might be able to accomplish this task. Please consult this link for instructions on how to do it. It will require the reading of this link to see how to do it. I might be wrong and this might not be what you are looking for.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I believe that someone mentioned that NIS needs to have the ability to turn off the Idle Quick Scans. Remember that doing so will reduce the level of sceurity of your computer.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Not at all if you run a manual quick scan each day but when you want to.
You had my 666 post number. No offence!
Regards,
Did the instructions in the link which I provided accomplish the turning off of the quick scans which you desired to do? No offence taken about 666.
The link you provided gives info on how to stop or resume a manual quick scan.
I was referring to idle quick scans triggered by a new set of virus defs.
So far, this option is not available in all NIS products.
In all cases, I asked for this option as a workaround to avoid the prolonged activity of the hidden thread running under System and it's SRTSP.SYS.
This is the main subject of this topic, and if it's resolved by Symantec then I have no problem with the idle quick scans.
Hope this helps your understanding.
Here are new screenshots of my NIS Performance graph and my system specs from the AutoFix clipboard per elesewhere's instructions in message # 29. I added an extra screenshot to show what the pop-up displays (i.e., 1% ccSvcHst.exe) if the NIS GUI is open during the system idle.
A. NIS GUI Closed - Post Quick Scan Idletime CPU Activity Reported as "No Activity"
B. NIS GUI Open / Performance Window Active - Post Quick Scan Idletime CPU Activity Reported as "1% ccSvcHst.exe", Remaining Activity Not Labeled
Norton Internet Security
20.4.0.40
Windows Vista (TM) Home Premium
6002.18881.x86fre.vistasp2_gdr.130707-1535
Norton Autofix Results: 1 item(s)
Installation :: Success
------------
MS Windows Vista Home Premium 32-bit SP2 * Firefox 26.0 * IE 9.0 * NIS 2013 v. 20.4.0.40
HP Pavilion dv6835ca, Intel Core2Duo CPU T5550 @ 1.83 GHz, 3.0 GB RAM, NVIDIA GeForce 8400M GS
Just a reminder to all Norton Community members that we are still looking for some volunteers to perform the testing outlined here.
Technical Notes for the Norton Forum Gurus:
Please take a closer look at the screenshot shown below (original reference here):
At this stage, I'm simply asking for at least one of the Norton Forum Gurus to take the time to test for this issue and report their results. This isn't a big ask in the grand scheme of things, so thanks in advance to those Norton Forum Gurus who may choose to step up and help out.
elsewhere wrote:
Just a reminder to all Norton Community members that we are still looking for some volunteers to perform the testing outlined here.
[...]
At this stage, I'm simply asking for at least one of the Norton Forum Gurus to take the time to test for this issue and report their results. This isn't a big ask in the grand scheme of things, so thanks in advance to those Norton Forum Gurus who may choose to step up and help out.
It's been over a month now since my last post above. Isn't anyone from Symantec, any Norton Community member with Norton Forum Guru status, or anyone from the broader Norton Community interested in testing this issue for us?
Here is the impact of this issue on one of my PCs:
The idle-time Quick Scan ran at around the 85 minute mark below. After this idle-time Quick Scan, the Norton SRTSP.SYS thread, running under the SYSTEM process shown in blue below, then proceeds to consume over 50 percent of the available CPU during Idle time for the next hour and twenty minutes:
Interrupting idle-time will see CPU usage return to normal, however, any subsequent idle-time periods will see the Norton process consuming over 50 percent of the available CPU again. The only solution at that stage is to re-boot the PC.
The issue that we are reporting here appears to be a problem with Norton Auto-Protect (SRTSP.SYS). This issue may just be a symptom of a much broader issue with Auto-Protect that affects overall Norton product performance.
Choosing to ignore this issue has real-world consequences, as per the AV-Test Performance test results below.
AV-Test describes Performance as:
| Performance | Average influence of the product on computer speed in daily usage |
| Use cases | Visiting websites, downloading software, installing and running programs and copying data |
Test results for Norton Internet Security 2014 are as follows:
| AV-TEST Report | Platform | Performance Score |
| Sep-Oct/2013 | Windows XP (SP3, 32 bit) | 3.5/6.0 |
| Nov-Dec/2013 | Windows 8.1 (64 bit) | 3.0/6.0 |
As shown above, the Norton Product's Performance Scores are falling which will, in turn, have a detrimental impact on Norton product sales.
If you agree that this is an issue, then please take the time to test for the issue, report the results and voice any further concerns that you may have.
Thanks
Comments as follows:
1. From the descriptions of this problem provided in previous posts in this thread, it seems to me under certain circumstances SRTSP.SYS gets "stuck in a process loop" - which is a variant-form of a "deadly embrace".
2. The fact that the problem can be triggered by performing any Live-Update that has as one of its components a virusdef update indicates the problem is triggered by the start of a background quickscan. Please note it is entirely normal and correct for a background quickscan to be performed whenever any live-update installs a new virusdef set. This is NIS working as designed.
3. Whenever a background quickscan is performed - several things must "go right" for the background quickscan to proceed to completion successfully. Any one of a myriad of things can cause this background process to loop uncontrollably - but the most-probable-cause is a "tagging" error.
Explanation as follows:
4. When a background quickscan is initiated - "state files" must be created somewhere - and then modified during the scan process so the background task is capable of monitoring the progress of its own scanning procedure. When the process is complete these "state files" must be altered to indicate the scan is complete. If the "state files" are not properly maintained during the scanning process - the background quickscan will never know its scan is complete - and will continue to churn until such time as something else terminates the background quickscan process. In the case you describe - that "something else" is any user activity which brings the machine out of "idle mode".
5. However, because a background quickscan is not terminated until complete - but only suspended - the next time idle-mode is engaged the "state files" are consulted - and things start up from where they left off as far as the background quickscan is concerned. If the "state files" remain in error - the loop resumes from where it left off when suspended - and the background activity starts back up as if it had never been interrupted in the first place. This repeats ad nauseum.
6. The "state files" for SRTSP.SYS are found in different places depending upon the installed version of NIS. These files are not accessible using any usual form of search - because the SRTSP folder is a critical folder and is "not supposed to be monkeydiddled with by mere mortals". The only processes which are permitted access to the SRTSP folder structure are SYSTEM processes. This protects background scanning from being compromised by malware - which ensures that malware gets detected - rather than allowing malware to alter the SRTSP.SYS "state files" to avoid detection.
7. However, when it comes time to diagnose problems with the SRTSP.SYS procedures - the very protection needed to ensure malware does not get its grubby paws on what it should not - interferes with diagnostic procedures. This is normal and correct. NIS has extensive "safety systems" which are put in place specifically to prevent access to these folders and to automatically "self heal" any attempts to modify access parameters to these folders.
8. Apostolos has given the "keys to the kingdom" in regards to this problem - by noting that a remove/reinstall procedure for NIS solves the problem temporarily. What this means is the remove/reinstall process deletes the invalid "state files" as part of the removal process - and a coherent set of "state files" is installed as part of a fresh install process. The fact these files corrupt a few days later is indicative of a file system error which corrupts the "state files" - whereby the problem recurs.
So, things to check:
1. The most common cause of file system errors in an otherwise-healthy installation of Windows is problems with the Hard Disk Controller Drivers.
2. There have been extensive problems with the Intel Hard Disk Controller Drivers used in Core2Duo machines, the entire i3/i5/i7 series and their variants. This has gone onandonandonandonandonandon for years - all the way from the ICH5 through to the ICH12 and the latest available today.
3. The problem with this issue - is that every time Intel fixes something - the number of "weird things" goes down - which is normal and correct - that's what is supposed to occur when you fix bugs. However, both Intel and most users tend to ignore the consequences of bugs that have a low-probability of affecting things. This is the fatal flaw which causes extensive grief.
4. Please note that Intel is not alone in hiding their heads in the sand on this. Marvell, JMicron, Silicon Image and other Hard Disk Controller Chipset manufacturers have also made the same mistake repeatedly. AMD have issues as well - there are no lily-white participants.
5. Worse, the Intel Hard Disk Controller Driver problems interact with the Intel Hard Disk Controller RAID/AHCI BIOS inserts in the Motherboard BIOS. Sometimes, the only fix is not just a Hard Disk Controller Driver update - but the installation of a needed motherboard BIOS update as a companion to the Hard Disk Controller Driver update. Ditto for Marvell, JMicron, Silicon Image and others.
6. And finally, there is the matter of the Hard Disk firmware. I have had situations where an installation of Windows was unstable from the beginning - and got worse the further into the install I got. The issue was intermittent file-corruption in no predictable pattern - except that it occurred as a result of a normal shutdown where I got a wonky machine on restart. After extensive hair-pulling and lots of googling, I discovered the problem was due to bad firmware on the factory-supplied Hard Disks I was using. (Seagate, this means you.) Updating the firmware gave me back a sweet system that has responded reliably ever since. (Thank You, Dell for the firmware update.) (Western Digital, you are not alone.)
Examples of the above:
1. A popular Core2Duo board is the Asus P5Q Deluxe or P5Q3 Deluxe. This board uses a Marvell 88SE6121 Hard Disk Controller for its high-speed onboard dedicated RAID-array-pair ports - and an Intel ICH10R Hard Disk Controller for its 6-port SATA controller embedded in the P45 Motherboard Chipset.
2. What this means is there are two Hard Disk Controller chipsets on this motherboard. Each has its own dedicated BIOS insert and matching Hard Disk Controller Driver. Thus, there are four ways things can go wrong, go wrong, go wrong...
3. This board had extensive "teething problems" when first introduced. There were endless problems with the Hard Disk Controller drivers. There were endless problems with the motherboard BIOS. It went onandonandonandonandonandon. Any user who had one of these boards went through endless rounds of BIOS and driver updates as both Asus and Intel found and fixed bugs. But eventually - things got sorted to the point where simple Windows installations (where the Marvell controller was not used) started to work somewhat stably. Then, things got to where the Marvell drivers worked well but the Intel drivers gave problems. This is where things got hairy.
4. Even though Asus knew the P45 Chipset uses an ICH10R Hard Disk Controller, Asus uses a Version 8 (suitable for the ICH8R Hard Disk Controller Chipset) BIOS insert for the ICH10R Controller on that motherboard. This has lots of ramifications further down the line when it comes time to work with newer Hard Disk Controller Drivers. Asus also did not properly update the Marvell 88SE6121 BIOS insert when new revisions were released by Marvell. Today's BIOS release for the P5Q/P5Q3 still installs Version 1.2.0.L70d - even though Version 1.2.0.L75 is the current version of the Marvell RAID BIOS. This again has similar ramifications when it comes to working with newer Marvell Hard Disk Controller Drivers.
5. Now, let's talk about the Hard Disk Controller Driver debacle itself. There have been dozens of releases of the Intel Matrix and RST Hard Disk Controller drivers. Which one is right for each motherboard? God only knows. There is lots of chatter in various motherboard forums indicating "this driver works best with this motherboard" - "no, that's not true, this driver works best but you need this BIOS update as well" - "no, that info is out-of-date, use this" and so on. Some of that information may even have been correct for the time at which each post was made - but users following that advice today may get "gotcha"d instead.
Conclusions:
Why am I mentioning all of this? Because the most common way file-system-corruption occurs is during Sleep and Wakeup. This is one of the reasons why it is possible to have a machine that is running perfectly when you leave the machine to do something else (or go to bed) - and it's wonky when you hit the keyboard or move the mouse when you return (or in the morning when you get up). And the hardest thing for Hard Disk Controller Drivers to get right? Yup, you guessed it, maintaining file integrity when entering/returning from Sleep.
So, we have a set of files - the SRTSP.SYS "status files" - whose integrity is critical for stable background scanning. We also have a set of Hard Disk Controller drivers (Intel/Marvell/JMicron/Silicon Image/AMD and so on) which are known to spontaneously corrupt files when entering/returning from sleep - if the proper updated Hard Disk Controller driver is not installed in sync with its matching BIOS insert. Hmmmm. Recipe for disaster? Yup.
Another problem with unstable Hard Disk Controller Drivers is Registry Corruption. Another problem with unstable Hard Disk Controller Drivers is file-corruption if a Live-Update (or worse, a Windows Update) is interrupted by a "going to sleep" operation. Can you see a pattern here?
This is one of the reasons it is critically-important to monitor a Windows installation for evidence of instability in its sleep/wakeup operations. The best time to catch this is during the initial Windows install. Any instability here is grounds for investigation regarding BIOS updates and Hard Disk Controller Driver updates. Often, it is not possible to determine-in-advance whether or not a particular Hard Disk Controller Driver is stable-or-not - until a freshly-installed program puts demands on the Hard Disk Controller Driver that have not been made before. Any program that does extensive background-processing (which is true of all real-time anti-malware solutions) will stress the system's Hard Disk Controller Drivers more extensively than typical user operations. This is "the nature of the beast" - and cannot be avoided.
The above is why I consider an Image Backup Program to be a mandatory part of every user's arsenal. During an initial Windows installation, I perform image backups at every major stage of the installation process - so I can conveniently return to the desired point in the installation process if I get "gotcha"d somewhere further downstream. This saves endless hours of reinstallation frustration.
Later on, during normal operation, the Image Backup Program also allows me to recover seamlessly from a corrupted installation due to sleep/wakeup file-integrity problems. I can then go about the process of solving the problem without having to reinstall-from-scratch. Furthermore, use of an Image Backup Program to restore the system ensures I know that all the files on that Hard Disk have been returned to health - no matter which files happened to be open and/or were in the process of modification when "things went wonky". This is especially reassuring when there is suspicion that a Live Update or a Windows Update is implicated in the "wonkyness".
Hope this helps.
twixt wrote:
1. From the descriptions of this problem provided in previous posts in this thread, it seems to me under certain circumstances SRTSP.SYS gets "stuck in a process loop" - which is a variant-form of a "deadly embrace"...
8. Apostolos has given the "keys to the kingdom" in regards to this problem - by noting that a remove/reinstall procedure for NIS solves the problem temporarily. What this means is the remove/reinstall process deletes the invalid "state files" as part of the removal process - and a coherent set of "state files" is installed as part of a fresh install process. The fact these files corrupt a few days later is indicative of a file system error which corrupts the "state files" - whereby the problem recurs.
Hi twixt:
Thanks for your comments. It certainly seems that SRTSP.SYS (Real-time AutoProtect) is getting stuck in some sort of process loop following an idle QuickScan on some systems. The problem seems to be more prevalent on 32-bit systems, which is why elsewhere has asked users having this same issue to post a screenshot showing their high idletime CPU activity (labeled as "No Acitivity" in the Performance graph as shown in my original post) and provide additional information about their system configuration.
As noted in message # 19, I have performed two clean re-installs of NIS v. 20.4.0.40, essentially following the steps posted here by Phil_D (i.e., selecting "Please remove all user data" during the Control Panel uninstall followed by multiple re-boots and wipes with the Norton Removal Tool). Unlike Apostolos, the problem with high CPU activity by SRTSP.SYS re-occurred immediately after each re-install on my system.
I have also never experienced the error message that Apostolos described for his own system in message # 20 so until his AutoFix results (i.e., Windows and Norton specs) and Performance graph screenshot are posted in this thread per elsewhere's instructions in message # 29 I have no way of knowing if our problems are even related.
------------
MS Windows Vista Home Premium 32-bit SP2 * Firefox 27.0.1* IE 9.0 * NIS 2013 v. 20.4.0.40
HP Pavilion dv6835ca, Intel Core2Duo CPU T5550 @ 1.83 GHz, 3.0 GB RAM, NVIDIA GeForce 8400M GS
