Most likely the virus scanner is opening the tempfile (created
by mercurial) without FILE_SHARE_DELETE flags, which causes the
later os.unlink in util.rename to abort.

If a process A opens a file without specifying FILE_SHARE_DELETE,
another processes B is denied deleting or renaming that file.
If the file is instead opened with FILE_SHARE_DELETE, delete
requests by other processes are just delayed until process A
closes the file.

It is quite common that applications create temporary files
which they delete later on.

However, a virus scanner should open files using FILE_SHARE_WRITE
and FILE_SHARE_DELETE access flags on Windows, so that
applications can continue to write and delete files without
aborting.

A patch for mercurial has been suggested on the -devel mailing
list, which ignores when os.unlink fails (instead of aborting).
Leaking a temporary file in that situation seems to be the lesser
evil, instead of trying to notify the user at the cost of leaving
more significant file inconsistencies (leaving an extra tempfile
behind does not render the repo corrupt. A subsequent clone --pull
on that repo will succeed to create a clean copy).

Nevertheless, I suggest to ask the makers of the virus scanner
why they open files without specifying the FILE_SHARE_DELETE flag
or possibly file a bug report on their product.