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.