Some of the hardware interrupts seem to stem from the VRDB generation. I thought it would only update once in three weeks, but I have proof now that is does something constantly. All shields were paused, but the interrupts came in periodically together with the VRDB icon rotating in the tray.
The bulk of the interrupts stem from the combination bitComet and the Shields. When I terminate the shields the high CPU overhead goes away. The internet traffic should not generate that amount of interrupt handling.
The attachment shows the interrupts and BitComet twice. The top half of the picture shows the graphs for the interrupts and BitComet when the shields are terminated. The bottom half when the shields are up. The red graphs are the interrupts.
If the VRDB icon is spinning, then yes, it would be understandable (VRDB is being regenerated).
Try simply to disable VRDB generation and see if it helps.
One of the disk drives was running in PIO mode in stead of in DMA mode. This may happen over time when there have been errors on the disk. Resetting the values in the registry and rebooting cured this problem.
So, disks running in PIO mode will typically show high occurrence of hardware interrupts. Avast makes it even worse, probably also because of some disk activity while scanning.
Well, yes, there may be a lot of disk activity when scanning - certinly on the scanned drive ;D, and also e.g. on the drive with TEMP folder. There shouldn’t be much disk activity, however, when avast! is “idle” (appart from the writing to MDB database, which is caused by the Jet drivers and seems to be hard to get rid of).
Anyway, thanks for letting us know that you solved the problem!
Agreed, so I decided after a fresh reboot on one system to see what happens, the entire boot phase is 5x longer than normal. For the record a normal boot on this machine is a little over 2 minutes, today it was closer to 10.
Upon looking at task manager, I can see ashserv.exe is hogging all cpu. Attempts to reduce it’s priority resulted in an ‘access denied’. Pausing or terminating the various sheilds with the Avast GUI did nothing to reduce the load.
I watched it scan 1000 files during the boot phase (according to the counter in the GUI), simply doing what I have deemed normal behaviour. Still nothing to determine why the load is so high.
I did find something worth mentioning. At this time TeaTimer was very active and may very well be interferring or conflicting.
I went into services and stopped ashserv.exe, TeaTimer went to full load for about 10 seconds then load resumed normal idle.
Restarting ashserv.exe from services resumed protections but without the heavy load.
So, OBVIOUSLY some update has changed vast characteristics about how this process starts and the interference level of said startup.
I would like to hear a concrete answer to this issue, and verification of the changes to the program.
Hmm, I have merged my icons, so I don’t know if one or the other is happening, but I’m positive my settings are not to generate databases during activity.
This would make sense, but why all of a sudden is this happening, especially after the flurry of updates last week?
Upon looking at task manager, I can see ashserv.exe is hogging all cpu. Attempts to reduce it's priority resulted in an 'access denied'. Pausing or terminating the various sheilds with the Avast GUI did nothing to reduce the load.
This looks a lot like my problem. Have you checked that the IDE ATA/ATAPI controllers are set to some DMA mode and not to PIO mode.
You can find this if you go to Control Panel - System - Hardware - Device Manager - Expand IDE ATA/ATAPI controller - Right click each IDE channel - Properties - Advanced Settings - Look at Current Transfer. If one of these are set to PIO mode, you are in this kind of shit.
Of course, Tiny PF 2005 Pro. Don’t even think of blaming this on my firewall. I personally configure this product and have a expert knowledge of it.
[quote="Jeruvy post:27, topic:603449"]
Upon looking at task manager, I can see ashserv.exe is hogging all cpu. Attempts to reduce it's priority resulted in an 'access denied'. Pausing or terminating the various sheilds with the Avast GUI did nothing to reduce the load.
[/quote]
So, are you saying the even if you choose "Stop on-access protection" from the avast! tray icon context menu, ashServ.exe keeps using 100% CPU?
That is exactly what I’m saying.
[quote="Jeruvy post:27, topic:603449"]
So, OBVIOUSLY some update has changed vast characteristics about how this process starts and the interference level of said startup.
I would like to hear a concrete answer to this issue, and verification of the changes to the program.
[/quote]
I’m afraid I’m not aware of any such changes.
What were the changes in the last program updates?
[quote="Jeruvy post:28, topic:603449"]
Hmm, I have merged my icons, so I don't know if one or the other is happening, but I'm positive my settings are not to generate databases during activity.
[/quote]
When VRDB is being regenerated, you can see the VRDB icon - even if they are merged in the normal state.
Not for me, I'm using SATA drives in a raid array on this particular PC.
Ok then, install Process Explorer [url]http://www.sysinternals.com/Utilities/ProcessExplorer.html[/url] and have a look at the graph of the Interrupts process. If that is constantly high, you have a hardware problem similar to mine.
Well, you might have expert knowledge of it, but the fact is that some firewalls perform a “scan of applications” when they start, probably extracting icons from every executable they have a rule for, maybe even more of them. This scan, however, also triggers avast! scanning of the corresponding executables - as they are accessed. Such a thing really increases the boot time significantly, even by minutes.
There must be some scan causing the CPU consumption… if you stop Standard Shield and let the changes be persisted (and restart the computer) - does the high initial CPU usage still remain there?
2+ years I’ve been using Avast, and Tiny Together, NEVER had an issue of ‘scanning’
Yes, TPF does scan files in REAL TIME, just as AVAST does, so this is not the problem. ONLY AVAST has had any recent changes, so again I attribute this cpu issue to avast.
Since no one wants to explain this behaviour, other than assuming it’s something I’m doing, which is not the case, I will have no choice but to dump Avast in favor of a better more effective solution.
Done, unfortunately this simply back up what I’ve already said. Truthfully Tiny firewall has a full process inspection tool since it does provide excellent stateful inspection, and true host integrity functions unlike many other inferior firewalls.