• All Community
    • All Community
    • Forums
    • Ideas
    • Blogs
Advanced

Not what you are looking for? Ask the experts!

Kudos2 Stats

NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

I am using using NIS v. 20.4.0.40 (NIS 2013) with Vista 32-bit Home Premium.  After each idletime QuickScan, my CPU continues to run at approx. 20% and I can see my hard drive continuously thrashing until I take my system out of idle.  When I click inside the NIS Performance Graph the pop-up simply says "No Activity".



Sysinternal's Process Explorer shows that the process SYSTEM (PID 4) and specifically Symantec's SRTSP.SYS (i.e., Symantec Real-time AutoProtect - TID 3624) is responsible for this high CPU activity during post-QuickScan idles.  The thrashing of my hard drive corresponds to a rapid increase in disk I/O reads by ccSvcHst.exe (PID 320), and depending on the amount of time my system remains in idle, these I/O reads by ccSvcHst.exe can exceed more than 20 million reads within a matter of hours after boot-up.



I performed a clean re-install of NIS v. 20.4.0.40 but this high activity by SRTSP.SYS during idles persists.  A search of the forum led me to a post here by elsewhere and shows that this issue with NIS 20.x also occurs with Win 7, etc.

Does anyone know if Symantec is planning to fix this issue in NIS 20.x, or if the same problem has been reported in NIS 21.x?
------------
MS Windows Vista Home Premium 32-bit SP2 * Firefox 25.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

Replies

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

I am using using NIS v. 20.4.0.40 (NIS 2013) with Vista 32-bit Home Premium.  After each idletime QuickScan, my CPU continues to run at approx. 20% and I can see my hard drive continuously thrashing until I take my system out of idle.  When I click inside the NIS Performance Graph the pop-up simply says "No Activity".



Sysinternal's Process Explorer shows that the process SYSTEM (PID 4) and specifically Symantec's SRTSP.SYS (i.e., Symantec Real-time AutoProtect - TID 3624) is responsible for this high CPU activity during post-QuickScan idles.  The thrashing of my hard drive corresponds to a rapid increase in disk I/O reads by ccSvcHst.exe (PID 320), and depending on the amount of time my system remains in idle, these I/O reads by ccSvcHst.exe can exceed more than 20 million reads within a matter of hours after boot-up.



I performed a clean re-install of NIS v. 20.4.0.40 but this high activity by SRTSP.SYS during idles persists.  A search of the forum led me to a post here by elsewhere and shows that this issue with NIS 20.x also occurs with Win 7, etc.

Does anyone know if Symantec is planning to fix this issue in NIS 20.x, or if the same problem has been reported in NIS 21.x?
------------
MS Windows Vista Home Premium 32-bit SP2 * Firefox 25.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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Hi,

Isn't v21 the current version? Is there a reason why you are still using v20?

Thanks

Dick Win 10x64 current current NSBU
Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Hi Imacri,

I would suggest that you move to NIS v.21 asap...

Things are far better with NIS 21.

Regards,

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Hi Imacri, I know you must have a very good reason for staying with v 20, but I downloaded v 21 on the day of release, and it's working fine on my machines.  One laptop and one desktop, both on v 21. No thrashing, here !..... You can always revert, if you aren't happy with v 21.

Windows 10 Home X 64
Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


Does anyone know if Symantec is planning to fix this issue in NIS 20.x, or if the same problem has been reported in NIS 21.x?


Hi lmacri

The issue is still present in version 21, as reported below:

http://community.norton.com/t5/Norton-360-Norton-Internet/SRTSP-SYS-CPU-usage-labelled-as-No-Activity/m-p/1028415/highlight/true#M1580

(Transient link reproduced below)

SRTSP.SYS CPU usage labelled as 'No Activity'

‎27-09-2013 06:58 PM

After an Idle Quick Scan, a Norton 'SRTSP.SYS' thread will continue running under the 'System' process, as shown by the blue-coloured, 'No Activity' selection highlighted during an Idle Time period on the graph below. Please note the 22.73 percent CPU usage by this thread in the Process Explorer window below. Full details regarding the issue can be found in my previous post here:

http://community.norton.com/t5/Norton-Internet-Security-Norton/Norton-Performance-Monitor/m-p/880618...

Please investigate and resolve.

Thanks

Norton Internet Security 21.0.1.3 Windows 7 Home Premium 7601.18205.x86fre.win7sp1_gdr.130708-1532

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


elsewhere wrote:

The issue is still present in version 21, as reported below:

http://community.norton.com/t5/Norton-360-Norton-Internet/SRTSP-SYS-CPU-usage-labelled-as-No-Activity/m-p/1028415/highlight/true#M1580


Hi elsewhere:

Thank you for letting me know that the high CPU usage by SRTSP.SYS after QuickScans also occurs in NIS 21.x. - at least for those of us who reported this issue with NIS 20.x.  Have you tried upgrading to NIS v. 21.1.0.18 to see if this problem persists in the latest version?

I posted about this problem here back in Dec 2012 but that thread degenerated so badly that the forum administrator had to lock the thread to prevent further discussion.  I noticed that the link you provided to another thread on the same topic here suffered a similar fate before anyone from Symantec could provide input.


I'd be happy to run further diagnotics or provide memory dumps if anyone from Symantec is interested in pursuing this.
------------
MS Windows Vista Home Premium 32-bit SP2 * Firefox 25.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

Kudos2 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Imacri and elsewhere, I've passed this on to Symantec for investigation.

Windows 10 Home X 64
Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


lmacri wrote:

elsewhere wrote:

The issue is still present in version 21, as reported below:

http://community.norton.com/t5/Norton-360-Norton-Internet/SRTSP-SYS-CPU-usage-labelled-as-No-Activity/m-p/1028415/highlight/true#M1580


Hi elsewhere:

Thank you for letting me know that the high CPU usage by SRTSP.SYS after QuickScans also occurs in NIS 21.x. - at least for those of us who reported this issue with NIS 20.x.  Have you tried upgrading to NIS v. 21.1.0.18 to see if this problem persists in the latest version?

[...]


Hi lmacri

Sorry for the delay; the issue is still present in NIS v. 21.1.0.18 under Windows 7:

The important point to note here is that the 'No Activity' SRTSP.SYS CPU usage, after an Idle Quick Scan, actually ends under Windows 7, as shown by the blue inverted triangle above.

Under Vista 32-bit Home Premium however, I'm actually seeing worse results than the ones you described here:

http://community.norton.com/t5/Norton-Internet-Security-Norton/NIS-20-x-SRTSP-SYS-Real-time-AutoProtect-High-CPU-and-I-O-Reads/m-p/1047473/highlight/true#M248261

For me, the 'No Activity' process locks around 50 percent of the CPU (1 of 2 cores). After an Idle Quick Scan, the only way for me to stop Norton's idle 'No Activity' CPU usage is to reboot the PC.

Does Norton's idle 'No Activity' CPU usage actually end for you on your PC if you let it continue unabated?

Please advise.

Thanks

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Any chance this is disk optimization occurring? It may not show up as a Norton task  as it uses the Windows defrag routine.

Things happen. Export/Backup your Norton Password Manager data.
Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


elsewhere wrote:

Under Vista 32-bit Home Premium however, I'm actually seeing worse results than the ones you described here:

http://community.norton.com/t5/Norton-Internet-Security-Norton/NIS-20-x-SRTSP-SYS-Real-time-AutoProtect-High-CPU-and-I-O-Reads/m-p/1047473/highlight/true#M248261

For me, the 'No Activity' process locks around 50 percent of the CPU (1 of 2 cores). After an Idle Quick Scan, the only way for me to stop Norton's idle 'No Activity' CPU usage is to reboot the PC.



Hi elsewhere:

I haven't monitored this idletime activity by SRTSP.SYS closely enough on my 32-bit Vista machine to make a definitive statement, but the behaviour depends largely on how long my idletime lasts.  If I change my power settings to prevent my system from going into sleep mode and force a prolonged idle, this period of "No Activity" continues as long as my system remains in idle - see my screenshot in message # 1. The activity stops when I take my system out of idle and typically does not start again at the next idle.

If I use my default power setting so that my system normally goes into sleep mode after 25 min of inactivity, idletime activity by SRTSP.SYS runs every time my system goes into idle, stopping when I take my system out of idle, and starting again at each subsequent idle.  I think sleep mode is enough to halt this continuous cycling of activity by SRTSP.SYS during idles, but I'm not sure about that and it's possible that a boot-up is necessary to stop the cycling.

I've only noticed one occassion where this idletime activity by SRTSP.SYS appeared to stop of it's own accord on my 32-bit Vista system.  I ran a manual full system scan on 31-Oct-2013 and the SRTSP.SYS activity terminated by itself.  I seem to recall checking my Norton tasks and confirmed that an automatic QuickScan ran just as the full system scan was completing.  Sorry, my screenshot below from 31-Oct-2013 didn't capture the graph's pop-up but I did confirm that this was another period of high CPU usage labelled as "No Activity" and not due to some other non-Norton process like the Windows File Indexing or Windows Disk Defragmenter.

------------
MS Windows Vista Home Premium 32-bit SP2 * Firefox 25.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

Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


peterweb wrote:

Any chance this is disk optimization occurring? It may not show up as a Norton task  as it uses the Windows defrag routine.


Hi peterweb:

Norton's Idle Time Optimizer is disabled in my settings and my Norton Tasks window confirms that the Insight Optimizer task has never run on my machine.

If a Windows process like Windows Disk Defragmenter (dfrgntfs.exe for 32-bit Vista) runs during idle the process will be correctly identified in the activity graph pop-up.  The pop-up for a QuickScan or Full System Scan will correctly identify the process as ccSvcHst.exe (not NIS.exe, since I use NIS v. 20.4.0.40) and CPU activity by ccSvcHst.exe will correctly display as yellow, (not blue) peaks in the graph.

Since these periods of "No Activity" consistently occur after idletime QuickScans, all I have to do is start real-time monitoring in Process Explorer, adjust my power settings to delay sleep mode, open the Norton Performance window and wait for a QuickScan to run during idle.  The 20-25% CPU usage (and high I/O disk reads) by "No Activity" (or to be precise, 1% by Process Explorer, 19-25% unaccounted for by "No Activity") in the Norton Performance graph following the QuickScan always corresponds to 20-25% CPU usage by SRTSP.SYS in Process Explorer as shown in message # 1.

------------
MS Windows Vista Home Premium 32-bit SP2 * Firefox 25.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

Kudos2 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

... bump.

I'm still curious if Symantec has any explanation as to why some NIS 20.x (2013) and NIS 21.x (2014) users are seeing this high CPU and disk I/O activity by SRTSP.SYS (Symantec Real-time AutoProtect) during system idles that is labeled as "No Activity" in the Performance graph.

Since this high activity always seems to follow a Quick Scan, is this a case of a NIS scan not terminating correctly?  Could I have some third-party software running in the background (e.g., a network monitoring program) that "wakes up" NIS real-time protection after a Quick Scan?  Just FYI, NIS is the only AV software running in real-time protection mode on this computer.

Here's another screenshot from yesterday showing how these disk read/writes labeled as "No Activity" temporarily pause when I take my system out of idle.

------------
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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Imacri,

Be sure to have a complete System backup Image because in my case, this activity corrupted the taskbar and some other Windows essential files.

At the end, the idle Quick Scans finished after 3-4 mins and the activity continued for at least 10-15 more mins.

I suggest that you uninstall NIS each time this activity occurs before a major problem with the OS starts.

I hope that it will be fixed asap because if it is happening again on my W7 systems my comments for Symantec here  will be very ugly.

If Symantec cannot fix it then give us the ability to disable the idle Quick scans.

Have an excellent day.

Regards,

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Hi, all. Send of Jive made the point here,

http://community.norton.com/t5/Norton-Internet-Security-Norton/NIS-2013-NIS-exe-uses-all-CPU-on-winXP/m-p/1061081/highlight/true#M250086

I wonder if that's what's causing the spikes in YOUR cases ? As mentioned, the actual monitoring seems to cause spikes ?

Windows 10 Home X 64
Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Hi F4E,

I wondered the same thing - however, if the Performance window were left open the Norton activity would be shown as yellow, so I think this issue is probably something different.

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

No doubt it's a simple solution, SOJ. That's why I can't figure it !......

Windows 10 Home X 64
Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


F4E wrote:
I wonder if that's what's causing the spikes in YOUR cases ? As mentioned, the actual monitoring seems to cause spikes ?

Hi F4E:

I re-labeled the screenshot I first posted in message # 12 to show that this constant disk thrashing by SRTSP.SYS during idles is esssential the same regardless of whether the NIS GUI is open or closed.

In the idle period labeled "A" when the GUI was open and I was monitoring the Performance graph in real-time, the pop-up in that part of the graph showed that ccSvcHst.exe was responsible for 1% of the total CPU (in yellow along the baseline), but the remaining ~ 15% of the total CPU (in blue) was this "hidden" activity by SRTSP.SYS. 

In the idle period labeled "B" when the GUI was closed all ~ 15% of the total CPU was this blue "No Activity" by SRTSP.SYS.

The constant disk read/writes during idles by this "hidden" SRTSP.SYS activity that elsewhere and I are describing in this thread looks similar to what Cooloutac reported here but quite different from the yellow spikes of NIS.exe activity described by Steve_C here

------------
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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Ongoing problem for some, either way. I can't say I've ever had this problem. Maybe I've been lucky ?......

Could it have anything to do with system differences ? Vista 32 bit, or Windows 7 64 bit. Or am I grasping at straws ?

I believe Norton is optimised for either ?

Windows 10 Home X 64
Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


F4E wrote:

Could it have anything to do with system differences ? Vista 32 bit, or Windows 7 64 bit.


The problem doesn't appear to be related to the bit architecture of the OS.  I use 32-bit Vista while Cooloutac and elsewhere use 64-bit Win7.  All three of us noticed the problem after we upgraded to NIS 20.x (2013) and elsewhere reported that the problem persists in NIS 21.x (2014).  elsewhere and I used Sysinternal's Process Explorer and independently came to the same conclusion that this post-Quick Scan idletime disk thrashing displayed as "No Activity" in the NIS Performance graph is caused by SRTSP.SYS (Symantec Real-time AutoProtect).

I have wiped and re-installed NIS v. 20.4.0.40 twice, 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) and the idletime disk thrashing persists.

------------
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

Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Hi Imacri,

I had the same issue with both my W7 x64 machines but after an idle quick scan which I know from experience that it takes about 3-5 mins I used to suspend the prolonged SRTSP activity by using my keyboard.

However, I made the huge mistake to let it finished itself the past 3-4 weeks and at one moment during a shutdown I had for the first time the dimmed screen message from W7 "NIS.exe, the referenced instruction at 0xxxxxxxxx could not be read by memory etc. Click OK to terminate the program" which is basically a warning that NIS 21 died and an uninstall process with NRT is more or less required.

This is the main reason why I stated in a previous message that it is essential that you have a complete System image backup before any trouble arises.

Once again, if Symantec is too busy to look at this and resolve, it would be great news if in the upcoming version update, the ability to manually disable the idle Quick Scans is offered, because the problem starts after an idle quick Scan finishes. (Not immediately after product installation, but after an estimated period of 2-3 weeks, at least for my machines).

Kind regards,

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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 !

Windows 10 Home X 64
Kudos2 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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.

Success always occurs in private and failure in full view. Windows 10 Pro 64 bit Norton Core Security Plus 22.17.3.50 Core Firmware 282 I E 11 Chrome latest version.
Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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

Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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,

Kudos2 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


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:

  • Open NIS > Settings > General > Norton Tasks > Idle Time Out > 2 Minutes and click Apply.

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:

  1. Make sure that you have changed the Idle Time Out setting as described above.
  2. Run LiveUpdate manually and click on the 'View Summary' link in the LiveUpdate window.
  3. In the list of updates, look for a Norton Virus Definitions update. If a Virus Definitions update is present, then close LiveUpdate and proceed to step 4.
  4. Leave the computer (or better still, lock it) and let it idle for 15 to 30 minutes.
  5. After the 15 to 30 minutes has elapsed, open NIS and click the Performance link.
  6. Check for the 'No Activity' behaviour described earlier in this thread (hover over and click on any blue CPU usage shown after the Quick Scan during Idle time). 
  7. Reply to this thread and upload a screenshot of your NIS Performance window showing the 'No Activity' or otherwise behaviour.
  8. Run Norton Autofix: Open NIS > Support > Get Support.
  9. Select the 'Copy to Clipboard' link in the 'Norton Autofix' window when Autofix completes and paste this copied information below the screenshot you posted above.

Thanks in advance to those Norton Community members who are prepared to test for this issue and report their results.

Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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,

Kudos2 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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:

http://community.norton.com/t5/Norton-Internet-Security-Norton/Warning-NIS-20-3-0-36-NOT-compatible-with-Malwarebytes/m-p/937063/highlight/true#M235378

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:

elsewhere Tracker

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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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.

https://support.norton.com/sp/en/us/norton-internet-security/21.1.0.18/solutions/v6599783_NIS_Retail_2014_en_us?actstat=activated&buildname=Retail&conntype=1000000000&coreservice=Startup+Type%3Aauto+State%3ARunning&cpu=Intel64+Family+6+Model+60+Stepping+3&curdefs=20131223.024&datetime=12-24-2013+18%3A23%3A21+PM+GMT&defbrowser=Internet+Explorer&dsfree=23.94&dstotal=94.99&endpointid=%7B54318720-6F32-47B3-A2DE-08E3E3491A0C%7D&entsrc=help&env=prod&hbguid=54318720-6F32-47B3-A2DE-08E3E3491A0C&hcmode=false&heartbeatID=54318720-6F32-47B3-A2DE-08E3E3491A0C&helpid=IDH_OPTIONS_LU_HELP&ieversion=9.10.9200.16750&layout=Retail&layouttype=ESD&lic_attr=21124114&lic_type=16&memload=18&memtotal=13881&os=windows&oslang=iso%3AENG&oslocale=iso%3AUSA&osvers=6.1&osversion=6.1+7601.18247.amd64fre.win7sp1_gdr.130828-1532&partnerid=&partnername=Retail&plang=sym%3AEN&plgid=2&plid=2&psn=3XPX9BGP96MJ&q=idle+quick+scans+in+internet+security&remdays=344&serviceTicket=ST-ekg30w4Q3y3xMACpagMM-14325d8dae3-nav&skuf=21291108&skum=21292844&skup=21292844&spversion=1.0&sublength=358&subremaining=344&substatus=current&symskucurrent=21292844&symskumedia=21292844&utm_medium=product&utm_source=symc&vendorid=

Success always occurs in private and failure in full view. Windows 10 Pro 64 bit Norton Core Security Plus 22.17.3.50 Core Firmware 282 I E 11 Chrome latest version.
Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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, 

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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.

Success always occurs in private and failure in full view. Windows 10 Pro 64 bit Norton Core Security Plus 22.17.3.50 Core Firmware 282 I E 11 Chrome latest version.
Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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.

Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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

Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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 the 90 minute mark in the screenshot above, this issue was well underway.
  • Around the 75 minute mark above, I launched Process Explorer to investigate this issue.
  • At the 70 minute mark above, and with Process Explorer still active, the system went into Idle.
  • This issue's CPU usage overhead, similar to the Idle-time usage shown at the 80 minute mark in the screenshot above, then manifested itself as an increase in the overall CPU usage, as shown during the Idle time period starting at the 70 minute mark above.
  •   The same pattern repeated itself at the 60 minute mark above.

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.

Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


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:

PerformanceAverage influence of the product on computer speed in daily usage Use casesVisiting websites, downloading software, installing and running programs and copying data

Test results for Norton Internet Security 2014 are as follows:

AV-TEST ReportPlatformPerformance ScoreSep-Oct/2013 Windows XP (SP3, 32 bit)3.5/6.0Nov-Dec/2013Windows 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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

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.

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Hi,

Some extra tips:

1)  If you have NIS installed and you run the sfc /scannow or sfc /verifyonly commands, the issue begins immediately upon restart. Also the scan takes about 30% longer with NIS installed.

2) If you run a manual quick scan and it takes, let's say 3 mins, and the idle quick scan takes longer than the manual i.e. 5 mins then the issue is here.

If the manual and the idle quick scan take the same time to complete with the same pattern of HDD led blinking then the product works correctly.

I tried with a clean installation of W7 after a backup image and the issue is here.

The test was made with two W7 x64 pc's and performed the same steps for a clean installation of NIS NRT etc.

On one pc the product installed correctly, about 2 months now and both manual and idle quick scans take exactly the same time about 3:15 mins, on the other pc the issue started immediately when the first set of virus defs was downloaded and the idle quick scan was triggered.

I suspect that at this moment the product is left in the auto-pilot by Symantec, no product update for about 3 months.

Other issues are also pending, Vulnerability Protection is still 32-bit NO 64-bit, double icons Systray and others.

Is someone from Symantec reading and transfer the info here to the appropriate team or not??

Regards, 

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


Apostolos wrote:

2) If you run a manual quick scan and it takes, let's say 3 mins, and the idle quick scan takes longer than the manual i.e. 5 mins then the issue is here.  If the manual and the idle quick scan take the same time to complete with the same pattern of HDD led blinking then the product works correctly.


Hi Apostolos:

Your NIS.exe errors and observations about slight differences in the length of time required for manual vs. automatic idletime QuickScans don't sound anything like the orignal issue being discussed in this thread.  Could you please follow elsewhere's troubleshooting steps described in message # 29 and post your screenshot and AutoFix results if what you are seeing resembles the screenshot is message # 1 [i.e., continuous blue (supposedly non-Norton) high CPU activity reported as "No Activity" in the Norton Performance graph].

------------
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

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Imacri,

I had NIS.exe errors one time and the product was uninstalled/reinstalled since.

As I said, I observed this issue with one of my pc's and I'm smart enough to know when it happens to immediately uninstall the product because there are chances that it's harmful for the system.

Since Symantec and many many others do not seem to care, I will certainly not do the "hard" job.

I hope that it will be fixed at some time.

Also you mentionned about Autofix results, what do you mean?

I truly hope that you do not rely on this useless applet to "see" if your product is working correctly or not.

By the way, I always had no errors with Norton Autofix if that is what you mean....

Also, what is the purpose of posting the NIS graphic to show the blue graph, I have way more advanced tools to monitor my system activity, PE & others, NIS performance is always disabled on my systems the last 3 years.

Kind regards,

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

observations about slight differences in the length of time required for manual vs. automatic idletime QuickScans don't sound anything like the orignal issue being discussed in this thread

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Hi again Lmacri,

What I described earlier are the very first symptoms before the issue will be pemanent.

That's all... ;-)

Regards,

Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


Apostolos wrote:

Also you mentionned about Autofix results, what do you mean?  I truly hope that you do not rely on this useless applet to "see" if your product is working correctly or not.


Hi Apostolos:

Please see elsewhere's comments here on how AutoFix can be used to collect and post basic details about your system information when you're troubleshooting on the forum.  My AutoFix results are posted at the bottom of message # 36, per step # 8 and # 9 of elsewhere's instructions in message # 29.

------------
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

Kudos1 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


Apostolos wrote:

Hi,

Some extra tips:

1)  If you have NIS installed and you run the sfc /scannow or sfc /verifyonly commands, the issue begins immediately upon restart. Also the scan takes about 30% longer with NIS installed.

2) If you run a manual quick scan and it takes, let's say 3 mins, and the idle quick scan takes longer than the manual i.e. 5 mins then the issue is here.

If the manual and the idle quick scan take the same time to complete with the same pattern of HDD led blinking then the product works correctly.

I tried with a clean installation of W7 after a backup image and the issue is here.

The test was made with two W7 x64 pc's and performed the same steps for a clean installation of NIS NRT etc.

On one pc the product installed correctly, about 2 months now and both manual and idle quick scans take exactly the same time about 3:15 mins, on the other pc the issue started immediately when the first set of virus defs was downloaded and the idle quick scan was triggered.

I suspect that at this moment the product is left in the auto-pilot by Symantec, no product update for about 3 months.

Other issues are also pending, Vulnerability Protection is still 32-bit NO 64-bit, double icons Systray and others.

Is someone from Symantec reading and transfer the info here to the appropriate team or not??

Regards, 


Hi, Apostolos. You have two systems, one of which works properly and one of which does not.  This is the ideal situation for comparative analysis - where the "wonky" system gets modified to be as close to the "good" system as possible - to see if the problem goes away.  Then each item is returned to its "standard" state until the problem recurs.  At that point, it is possible to analyze just exactly what is triggering the problem.

Running sfc tells Windows to "revert to standard".  This means reverting to the Registry Entries for the system - as set up by the initial installation of Windows from either the CD or the Laptop's Factory Restore process.  It is significant that the problem does not show up until restart.  This means the issue is part of the fundamental NIS-to-Kernel interface - which cannot be modified "on the fly" - and requires a reboot to implement.

The difference between /scannow and /verifyonly instructs sfc as to whether or not to replace any "defective" files it finds - the Registry cleanup occurs regardless.  Because the system breaks no matter which option for sfc is selected - this tends to indicate the problem is related to the Registry Entries which sfc reverts when sfc is run.

Consequently, it is important to know which versions of the Hard Disk Controller Drivers are active before sfc /scannow is run - so they can be compared to the versions of the Hard Disk Controller Drivers active after sfc /scannow is run.  Finding out what changes are imposed by sfc will give useful information as to where the problem is located.

Note: The default Hard Disk Controller drivers installed by the W7 installation CD - are commonly not the drivers used in a system which has been updated to SP1 - and then to current levels by Windows Update.  There were a bunch of bugfixes in the controller driver updates for SP1 - and having sfc revert to its version of "standard" may revert the Registry Entries for those items back to something which is not optimal.  Simply knowing what gets modified may give major clues as to where to look for the problem.

Another thing to consider - the use of the NRT to remove a previous NIS installation does not remove all possible Registry Entries involved with NIS.  For example, the Product Key entries in the Registry are not normally removed - unless that Registry Branch is totally corrupted.  It is entirely possible the NRT is "unaware" of a particular Registry Entry it should remove - or modify - in order to resolve a particular problem - because this has not yet been tracked down.  Thus, the only sure way to know you are reinstalling an "absolutely and positively clean" copy of NIS is to restore a System Image from just before NIS was first installed - and then reinstall NIS.

Furthermore, the NIS installer (and NIS itself) must interact with the Windows Kernel in many different ways - in order to ensure the installer can intertwine NIS into the OS such that NIS can "catch" malware in the act.  After installation is complete, NIS must also be able to detect user activity and hard disk activity so it can pause background quickscans - which means NIS gets its tentacles into lots more different places in the OS than is obvious.  Please note this is true for every Anti-Malware application with real-time scanning capability.  Problems occur when the programmers writing Anti-Malware apps think they understand what Microsoft is doing - but actually they don't.

Microsoft's SDK for Windows does not always tell the truth about what's really going on - and the programmers relying on that information to design their programs will trip over the discrepancies.  Documented Theory and Physical Reality are not the same in many Microsoft products (these are collectively known as "errata") - thus the potential for "gotcha"s goes up enormously.

As a result, the procedures needed to solve this kind of problem commonly must be run in reverse (from effect to cause) in order to detect the flaw.

So - with the above background info in place - can you please list the hardware for each of the two systems?

This includes:

Motherboard/Laptop Make and Model

Motherboard BIOS revision number

BIOS option selection of IDE, AHCI or RAID option for Hard Disk Controller Operating Mode

Hard Disk Make, Model and Firmware version for all drives in the machine

Hard Disk Controller Driver version(s) in use  (Info from Device Manager)

Video Card Make and Model

Video Driver version in use

Version and bit-level of OS, including Service Pack and Windows Update level

From the above info, I will see if I can find anything which could trigger the process-loop "stall".

Kudos5 Stats

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


elsewhere wrote:

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?



Hi elsewhere,

I apologize for the delay -- our team has been testing this issue and are working to resolve it. I'm sorry for not letting you know about this sooner.

Tony Weiss | Norton Forums Global Community Manager | Symantec Corporation
Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Hi Twixt,

Specs here: (too lazy to write one by one). :-)

http://www.sony.co.uk/support/en/product/VGN-AW41XH_Q/specifications

http://www.sony.co.uk/support/en/product/VPCF22M1E_B/specifications

Both laps have Nvidia 314.22 driver installed, the F series has an original driver, as part of the Nvidia Verde Program, and the other has the same driver modified by myself in order to install. I know, I lose the digital signature because of the modded .inf but no problem, the driver works flawlessly.

See section "downloads" for the updates, but I must say that most of the Sony apps are uninstalled at the exception of 2 or 3 essential for the pc's to run properly and the Fn functions to work.

Best regards,

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle


Apostolos wrote:

Hi Twixt,

Specs here: (too lazy to write one by one). :-)

http://www.sony.co.uk/support/en/product/VGN-AW41XH_Q/specifications

http://www.sony.co.uk/support/en/product/VPCF22M1E_B/specifications

Both laps have Nvidia 314.22 driver installed, the F series has an original driver, as part of the Nvidia Verde Program, and the other has the same driver modified by myself in order to install. I know, I lose the digital signature because of the modded .inf but no problem, the driver works flawlessly.

See section "downloads" for the updates, but I must say that most of the Sony apps are uninstalled at the exception of 2 or 3 essential for the pc's to run properly and the Fn functions to work.

Best regards,


Hi, Apostolos.  The links are fine - I've already looked at them.  However, I can't find any info in this thread as to which of your two laptops is the one that works properly - and which is the one that's wonky.

Please advise. 

Kudos0

Re: NIS 20.x SRTSP.SYS (Real-time AutoProtect) High CPU and I/O Reads During Idle

Hi Twixt,

The AW series laptop is the one having the issue with NIS, but I must say that it's used as primary, working every day.

The sleep and hibernation functions are always disabled.

The second one, I use it 3-4 times per month and I have to download a new set of virus x64 set but it's normal, however since the use is very limited maybe this is the reason why I do not see the issue. Idle or manual quick scans are finishing after 3 minutes without a problem. No prolonged idle activity.

If this helps,on both laptops, WAT and all CEIP scheduled tasks are manually disabled because I do not want Microsoft to spy on my computers.

Same for the Diagnosis scheduled task and the famous WinSat which before set to disabled, decided sometimes to run when pc was idle while I was watching a movie and you can imagine the inconvenience.

In brief, instead of the 40+ default scheduled tasks set by Microsoft, I only permit 25 including the 2 NIS scheduled tasks Error Processing etc.

You should probably already know that even if you opt not to participate in the CEIP program via Control Panel, the scheduled tasks attached to it, continue to run when pc is idle, if the user is not manually disabling them, both triggers and tasks. (very smart from Microsoft's part...)

Also, on both laptops there are zero Critical or Error logs in Event Viewer only WLAN Warnings which is absolutely normal. 

Let me know if you need extra info.

Regards,

This thread is closed from further comment. Please visit the forum to start a new thread.