Ashserve.exe 100% CPU Usage

[Vlk]

And is the avast icon spinning while the CPU load is high? I.e. is avast scanning something?

[HeDiBo]

I already said that: it's scanning nothing.

[Vlk]

So, again, the "Interrupts" process is showing high CPU usage, unless you kill ashServ.exe?
Is this reproducible? (I mean, does it happen all the time?)

[HeDiBo]

Yes, that is what's happening.

I must add there is a P2P process running at that time (bitTorrrent), but the hardware interrupts vanish when ashServ is killed.

[Vlk]

1. does stopping the P2P Shield in avast make any difference?
2. How much CPU is the "Interrupts" process taking, exactly?

[HeDiBo]

I am now at the office, so I cannot test now.
CPU percentages go as high as 80%.

[HeDiBo]

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.

[igor]

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.

[HeDiBo]

The graphs are made with disabled VRDB and have been made after waiting a very long time, to eliminate startup effects.

[HeDiBo]

Here is the answer to my problems:

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.

[igor]

Well, yes, there may be a lot of disk activity when scanning - certinly on the scanned drive , 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!

[Jeruvy]

WHY after killing serv, does websrv kick in to 100%?  your going to tell me that it was scanning a file on my system, and then once dead turned over to another exe to continue?  Someone should explain this behaviour to me so I can understand it better.

I have no idea. Killing ashServ.exe, however, is certainly not a correct method, so I don't really find it relevant. If you stopped Standard Shield provider from the user interface, for example (which should reduce the CPU usage, I guess) and ashWebSv.exe starts eating CPU - then it would be something worth investigating.

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.

J.

[Jeruvy]

The graphs are made with disabled VRDB and have been made after waiting a very long time, to eliminate startup effects.

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?

[igor]

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.

Do you have any firewall installed in your computer?

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.

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?

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.

I'm afraid I'm not aware of any such changes.

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.

When VRDB is being regenerated, you can see the VRDB icon - even if they are merged in the normal state.

[HeDiBo]

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.

If that's your trouble, the remedy is in http://www.michna.com/kb/WxDMA.htm.