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