As well as running from the Clamwin system tray icon, I also run both freshclam.exe and clamscan.exe via Windows Task Scheduler (in lieu of a proper Windows service). This allows me to run filesystem virus scans without being logged in, and has been in place/working as expected since November 2015.

However, as of 12 September 2016, these clamscan.exe calls have been failing with exit code 2. When looking at the logs for those days, I can see the following entry:



I have upgraded from 0.98.7 to 0.99.1 since then, but the errors remain. In fact, they have steadily increased to date, where now I get six of these in a single run:



I'm running on a Windows Server 2012 R2 ESXi 6.0 VM, with 1 x 4-vCore CPU and 8GB RAM, and calling from a batch file which builds up the clamscan.exe parameters as needed. The original parameters were deduced by running a manual scan with the settings I needed from within ClamTray.exe and inspecting the Command line column of Task Manager, e.g.:



The batch file runs freshclam.exe before clamscan.exe, which downloaded daily-22204.cdiff and daily-22205.cdiff on the day the issue started, and is now up to daily-22248.cdiff. I have also tried completely reinstalling ClamWin and downloading the database from scratch.

I Googled the error message, which led me to the fmap.c souce file, and I tried looking there for clues. I think it means that the MapViewOfFile function returned NULL or 0, but I'm not much of a C developer, so can't follow the trail well enough to make a concrete determination as to why.

What is causing these issues?

There have been no changes to ClamWin for several months now. I suspect that the error may be due to some recent virus signature(s) from Clam AV that ClamWin is unable to process when scanning the file(s) in question. There have been lots of changes from Clam AV that have not been incorporated into ClamWin since version 0.95. One obvious change is that use of the command line in ClamWin has been limited.

I think this is something you will have to live with, and I suggest that you whitelist the file(s) involved. In addition, you should be running another antivirus--a resident real-time, on access AV, and use ClamWin as a backup on-demand scanner.

Thanks for using ClamWin!

Regards,

You could try a complete uninstall (remove any leftovers, too) and reinstall ClamWin and see if that helps.

A Google search tells me that "fmap allocation failed" is sometimes a Clam AV message on a system with not a lot of memory. You might try to see what other software is running along with the ClamWin scan. If something does take a lot of memory, disable it via taskmanager and see if that helps the ClamWin scan.

Regards,

ClamAV is also big on memory/CPU because it does not run as a service on Windows. Some time ago, I submitted to the development team a way for them to run it as a service and I was told they will look into it and they would try and get it working. Unfortunately, I was also told that the details I sent them only shows them how to make Windows detect it as a service and it didn't show them anything on how to optimize the code to do this, so they need to do some investigation. I doubt we will see this by .99.3, but I am hoping we can see this by the time 1.0 is released.

RRK: I hope Clam can do it. We would have to jump through some hoops to do it via ClamWin and the Clam AV library.

Regards,

I would, but I can't see where in the summary/log/stdout/stderr it reports the file that is causing the issue. With other warnings/errors, the file is reported, but with this error I am only getting the LibClamAV Error string. I would guess that it would either be larger files but I'd thought --max-filesize or --max-scansize would take care of that. Perhaps some in-use file, but I thought that logged a warning, rather than a LibClamAV error.


I've got an 8GB VM, which I appreciate isn't a lot by today's standards, but is more than enough for the tasks I need to run. The other software is the stuff required to do the work the VM is supposed to do, which is more important than the virus scanner and is not memory-intensive. It's a single-use, offline system, not your average desktop. The monitoring statistics (if they are to be believed) show a small fluctuation at the time the Clamscan is running, but the system trucks along at 20-30% usage overall, all day, every day.


I certainly attempted that, and cleaned up everything I could see, but it made no appreciable difference.

On my computer, there is a scan log at C:\ProgramData\.clamwin\log on my Windows 8.1 system. I am also using Clam Sentinel, so I'm not sure if this is a ClamWin log or a Clam Sentinel log. I just did a ClamWin scan and the scan is listed there, so I think it is ClamWin. Anyway, run the scan that causes the problem, and see if the log has any detail describing your problem that can identify the file involved.

Regards,

These error messages are not shown in the ClamWin.log file, they are shown in the standard output/error of the clamscan.exe command, which I also capture as part of my batch run.

For instance, the log file might contain:



...but the program output for the same run would instead read:



Now, most of those 'Permission denied' errors are understandable, as the files will either be in use, or they are secured away, or they are junctions points (NTFS reparse points), or some combination of those issues; so I am not worried about them -- in fact, I've also been trying to exclude them with --exclude-dir without much success (but that's a question for another day).

However, the program output and the ClamWin.log file are subtly different. The log file does not include the fmap errors, but the program output does not include the name of the file that triggered each fmap error. Now, that could be some combination of the --quiet and --infected switches, but I don't want to log every file that ClamWin touches, just the infected files and any warnings/errors.

If the process responsible for emitting the fmap error to stdout/stderr could also include the filename, that might be a start for dealing with it using an --exclude option.

Those error messages are probably from the Clam AV code. The ClamWin program does very little except use the Clam AV library. Also, starting with version .95, use of the command line has been deprecated in ClamWin.

Regards,