Does Avast Work With Windows XP Pro 64-bit?

I have replaced the hard drive in my laptop with a 120GB SSD and instead of installing 32-bit Windows XP Pro I have decided to go with the 64-bit version to take advantage of the higher memory support. So, I have done a fresh install of Windows XP Pro x64 (with Service Pack 1) and then applied Service Pack 2. Following that, I installed Avast 2016.11.1.2253. However, in Windows Explorer, when I go to a folder containing an executable AvastSvc.exe becomes very busy for a long time causing the computer to freeze up pretty much. If I switch off the File System Shield this doesn’t happen, so this must be the cause. However, if I press back to leave the folder and then forward to go back into it, the same thing happens so it would appear that Avast is scanning the same file repeatedly each time it sees it. In the older versions of Avast I knew where to see the shield activity but I don’t know in the new one so can’t verify my suspicion. This sort of behaviour doesn’t happen under the 32-bit version of XP Pro. Also, in Task Manager, there is a “*32” appended to the process name, which I guess means it is running a 32-bit version of Avast rather than a 64-bit version.

So, my question is: does Avast work under the 64-bit version of Windows XP Pro?

Thanks,

3g

First there isn’t a native 64bit version of avast, the installation setup file contains 64bit versions of required drivers, etc. when installed on a 64bit OS version.

The only issue that I see and I’m not entirely certain of this as I haven’t seen this in black and white. Avast later 2016 versions of avast required XP SP3. Since XP Pro 64bit is based on windows 2003 server version and only goes up to SP2.

I don’t know if because of this and no SP3 in XP Pro 64bit if avast is just looking for SP3 for XP and as such failing on the basic check on XP Pro 64bit.

found this - https://www.avast.com/en-id/faq.php?article=AVKB3

Thanks.

Yes, I have seen this in the past, but there is no mention of the 64bit version of XP Pro at all.

This question has I believe been asked before, but no clear statement if the 64bit version of XP Pro SP2 (which is the latest/last) is supported.

OK, thanks DavidR and bigwilly_312000.

As far as I’m aware, Win XP Pro x64 SP2 is basically equivalent to Win XP Pro x32 SP3 (which is clearly quite confusing), but I am open to correction on this.

Also, I have now tried replacing the install of Win XP Pro x64 SP2 with a fresh install of Win XP Pro x32 SP3, and I’m getting the same behaviour, ie the Avast scanner kicking in whenever I browse to a folder with an exe file, even if Avast has already scanned it. This is the first time I’ve used an SSD and I don’t believe I have experienced this behaviour on any of the DOZENS of installs I’ve performed on mechanical drives (including on the same laptop), so is this behaviour specific to SSDs?

Just for clarification, I have not applied any other XP updates, ie for 64-bit: base install of XP Pro x64 w/ SP1 followed by application of SP2; for 32-bit: base install of XP Pro x32 w/ SP3. Normally I would apply a couple of XP updates after installing XP Pro x32 w/ SP3 before installing Avast, but I can’t imagine their absence has caused this problem???

EDIT: In fact, the Avast appears to scan an exe file EVERY TIME I move the mouse pointer over its icon (ie without browsing away from the folder and back again). This seems VERY, VERY wrong. How can I check the activity of the File System Shield to see if this is correct?

OK, forget x64 - that seems to be a red herring. I have wiped the x64 system and performed a fresh install of Win XP Pro x32 SP3 and updated Avast to version 11.2.2261 (through the program), but I still have a problem.

The problem seems to be with a specific file: zaSetup_101_079_000.exe (Zone Alarm installer). Whenever I browse to a folder containing that file, Avast scans it completely (and it’s a sizeable file) so Explorer locks up. It does appear that Avast scans other exes, but not fully hence Explorer doesn’t lock up.

I have also found where Avast displays its activity (Tools->Statistics). However, this has thrown up a couple more issues:

(1) AvastUI.exe consumes an inordinate amount of CPU (~50% of each of the 2 cores of my CPU) with the Statistics window open.

(2) AvastUI.exe consumes increasing amounts of memory (>500MB in just a few minutes) with the Statistics window open. There doesn’t seem to be any particular reason for this, and it doesn’t happen in version 11.1.2253 (running on another XP laptop). This memory is, however, released when the Statistics window is closed.

Is there any reasons for any of these behaviours? It seems to me that these are issues that should be addressed.

Have you changed any avast settings as simply opening a folder shouldn’t have it scan all the contents, it should only scan on activity. I don’t know if you have any application that might replace or change explorer settings ?

Another though if you still have the Windows Explorer doing its indexing, as in accessing files to index, I don’t know if that might trigger this response.

(1 & 2) that is a bug which I have reported but not yet fixed. It would appear to be a memory leak as keeping the Statistics Component status open, just racks up the RAM and it will keep going as long as it is open. I think I let it get as high as 1.5GB for confirmation.

Whilst compiling this response it has got to almost 1GB and 50% CPU, though that part doesn’t seem to effect my system too much.

Yes I have made some configuration changes to Avast, but I still don’t really see why it should single out the ZA installer as it appears to do. I shall uninstall Avast and do a vanilla install to see if it recurs.

I don’t know that it is singling out this file, but you may only see this one given it is taking a long time to scan.

You might want to try resetting it to default settings first. AvastUI > Troubleshooting > Restore factory defaults - for Program settings and Shield settings.

OK, so I reset to defaults and rebooted. Now when I browse to the folder containing the ZA installer, Avast does a brief scan of the file (~5 seconds). It is not scanned again if I select it, but it is scanned again if I right-click and select Properties. However, if I select “All packers” on the Packers tab for the File System Shield settings, then a full scan of the ZA installer is performed (~60 seconds) even when I just browse to the folder containing that file. This does not happen when browsing to a folder containing, for example, the Avast installer.

(I think the reason for the scan when browsing to the folder is because Windows Explorer is retrieving the “Product Name” and “Company” attributes from the file - the folder is in the default “Tiles” view so displays these details. Similarly, a scan is performed when I mouse over the icon so that Explorer can retrieve the details to display in the tool-tip.)

Note that the “Use transient caching” and “Use persistent caching” options on the Advanced tab are selected (I never touch those settings). I would have thought these would negate the need for repeatedly scanning the ZA installer file. It seems to work for other exes, just not the ZA installer.

The problem with selecting all packers is you get inert packers also a zip file is inert until unpacked, at which time files are scanned as they are unpacked.

There are exceptions in the the archive settings for three (archive types), this is predominately for self-extracting/executable archives, which that file is. But given that is is ZA file effectively an executable self-extractor it should get scanned no matter what your Packer settings are. What I don’t get is why it is being scanned when you open the folder, I don’t believe that is a default setting.

In the File Shield Settings - Advanced I have all 4 options checked. Use Persistent caching can be very useful if said ZA file is digitally signed. I don’t think that it is otherwise it shouldn’t be constantly scanned.

On a personal note, I don’t keep installation files on my system when they have been installed, I save them to a USB stick.

An area that you don’t appear to have looked are the on-demand scan settings and I believe these can have a positive effect on on-access scans in that these are what build up the Persistent cache. Check the avastUI > Scan - Scan for viruses screen at the bottom of that window are the Scan Settings. The Performance option - ‘Speed up scanning by using the Persistent cache’ (checked) but the one I feel most important is the ‘Store data about scanned files in the Persistent cache.’

A point to note, these Scan Settings relate to individual Scans, e.g. whichever one you have displayed from the drop down list.

I don’t really know what you mean here. I change the configuration setting to “All packers” so that all potentially dangerous files will get scanned.

As I said, I believe it is being scanned because Windows Explorer is accessing its extended attributes in order to display the “Product Name” and “Company” details from the file. The big difference in the extent to which it is scanned is determined by whether or not the “All packers” option has been selected. I don’t really understand why that should happen.

Yes, I have all 4 options selected (I don’t change the settings on that screen). But the cacheing system does not seem to be working for this particular file. I’ve no idea why. Is this a bug???

For all of my machines, I create a logical partition (L: “Local Store”) where I keep, inter alia, the installation files used to install the software on the system drive, complete with full instructions (I also have a USB stick which is the master copy of all software used on all machines). That way each machine is self-sufficient, ie it can be fully re-installed from scratch without any external resources once a fresh O/S install has been completed. Because I was just testing out installing Win XP x64 on my new SSD drive, it only had a temporary folder on its Local Store partition containing a few exes (XP x64 SP2, Avast, Zone Alarm, Driver Booster) which is how I ended up discovering this issue.

I haven’t performed an on-demand scan on this installation - is this why the cache hasn’t been built up? Surely the file system shield scans should also be able to make changes to the cache??? If not, that is surely a bug!

  1. setting all packers is overkill (set back to default). archive files are by their nature inert until opened and files extracted, long before that happens avast will have scanned then. The archives of concern are checked by default. But the ZA setup file would fall into that category.

  2. As far as I see it Explorer would generally be in Read mode when you access a folder, any higher than that and it is likely to trigger the scan.

  3. Caching for this file is questionable as I doubt it is being recorded in the Persistent cache only qualifying files would be allowed in. Trusted files from a trusted source and most likely digitally signed.

  4. I only have two systems and no network, so I stay fairly low key/tech on the data I have on them, no Local Logical Storage of any kind.

  5. I would certainly consider doing some on-demand scans that cover the areas of interest and have those scans set to ‘Store data about scanned files in the Persistent cache.’ to populate the Persistent cache. Since there is no such setting in the file system shield this is as I see it the only way to populate it.

  1. So what is the point of the “All packers” setting???

  2. Sorry, I don’t really understand what you are saying here.

  3. Persistent cacheing might not work for the ZA installer, but transient cacheing should - but it isn’t. As I said before, that is surely a bug.

  4. Again, as I said, if the File System Shield cannot utilisie the transient and persistent caches, that must surely be a bug.

How do I actually go about logging a bug?

  1. as an avast user I can’t answer that.

  2. for the most part explorer only needs Read access when it opens a folder, not write access.
    What I don’t know is when you say “I believe it is being scanned because Windows Explorer is accessing its extended attributes” somehow elevates the access permission triggering the scan. The old Read Write Execute.

  3. Transient caching is by its very nature transient, when you receive a new virus definitions update (or the file changed), that cache is cleared. That is how it used to work, I don’t know if the new streaming virus definition updates (that arrive much more frequently) would have the same effect on the transient cache.

  4. The settings for the File System Shield haven’t changed for some considerable time and there has never been any mention of the transient or persistent cache usage. But thinking logically when a file is accessed (new, write/modified/executed) then it is scanned.

I can’t see the point of having a Persistent cache if it isn’t going to be used in what is an on-access/resident antivirus.

  • With a resident on-access antivirus like avast, the need for frequent on-demand scans is much depreciated. For the most part the on-demand scan is going to be scanning files that would be otherwise be dormant or inert. If they were active files then the on-access file system shield would be scanning them before being created, modified, opened or executed.
  1. OK, understood. I am guessing that Avast considers an exe being open for reading as the same as it being open for execution (does Windows differentiate?) and therefore scans it.

  2. I am not using streaming updates, so there is no reason why the ZA installer file is not going into the transient cache.

Regarding logging a bug, do you not know how to do this?

  1. I honestly don’t know if windows explorer differentiates or not, but something is triggering avast to scan that file/s in that folder. I can open my Downloads folder and avast doesn’t scan anything, so I’m at a loss as to why your system/avast acts differently.

  2. Whilst I believe the streaming updates are essential to get additional protection on new signatures as quickly as possible. The problem is, there may be other possible reasons (unknown to me) why it may not be in the transient cache, data not being populated (the need for a few on-demand scans), a restart or receipt of VPS update. You could exclude that particular file from scans, but I don’t like giving that advice as it isn’t my system and you have to be 100% sure it is clean (likely, given when avast scans it nothing is detected).

Logging a bug is generally done in a topic (and is in a couple of topics if memory serves me well) or using the support ticket function https://support.avast.com/support/tickets/new?form=3, you can refer to the URL of your post in this topic about it.

I Reported this in another topic https://forum.avast.com/index.php?topic=185871.msg1309411#msg1309411 and it has been confirmed that avast are aware of it and it has been assigned a Bug number (internal bug id AV-9844), to be addressed in the next major release.

  1. You say that no files are scannned when you open your Downloads folder: (a) does that folder contain exes, and (b) what View (Thumbnails/Icons/List/etc) are you using for that folder?

  2. I have no plan to exclude any files from scans.

  1. Yes I wouldn’t have tested it if there weren’t any there. The Downloads folder is in List format, only my image folders do I have set to display Thumbnails.

Telling if things are being scanned is now a little more difficult as the option to animate the tray icon, although enabled it only works for the web shield scanning (a bug that has been acknowledged, awaiting a fix). I monitored the Task Manager for activity on avastSvc.exe, CPU remained on 00 and no increase in RAM used when the downloads folder was opened.

  1. That is your choice, but this will still be scanned.