Updated 1/20/16 : See "Consider Pagefile.sys"


This blog is intended to correct a common misunderstanding I've found to exist in the field, wherein an Administrator thinks they are protected by enabling only the Write Scan setting of the On Access Scanner (they disable the Read Scan setting). And don't feel bad, Internal folk get this wrong too!


Additionally, the purpose is to explain the intent of this Write Scan setting because it is not intended to provide security, which is what you might have been thinking... I know I used to think that, but that was so last month .


TLDR version

  • Scan When Writing to Disk does not scan while files are being written to disk; it scans files after they have been written to disk. That is also the time files can be Read from disk, meaning, a file can be Opened before the Write Scan occurs or completes. If the Scan When Reading from Disk option is disabled, you can be infected by known malware because it can be launched before the scan occurs.
  • Scan When Writing to Disk does not block access to files until a scan is complete; that is what Scan When Reading from Disk is for.


  • Scan When Writing to Disk does not guarantee a scan will occur; that is what Scan When Reading from Disk is for.

Scan Files "When writing to disk"

First of all, the label in the User Interface is terribly misleading. The implied meaning is that we are scanning the file as it is being written to disk - we do not. We scan the file _after_ it has been written to disk.

To scan a file "as it is being written" would require a very different architecture in the product than exists presently; it would mean adding unavoidable overhead to every write operation being processed by the System Cache (where files are likely to be written to prior to being written to disk), and the amount of overhead would become unbearable as the state of the file is changing with every byte of data written (or whatever size 'k' chunks you set as criteria to again inspect the file object) wherein it could go from harmless file to infected file. If that's what we did, nobody would enable the feature - nobody could enable the feature, realistically, performance would be terrible.


Scan Files "After being Written to disk"

That is what really happens. A file is considered "written to disk" when it is closed. Thus the feature is synonymous with "Scan after Close". Many applications open a file, write to it, and continue to write to it throughout the life of the application - it is never closed until the application terminates. For that application, a Scan after Close of that file would not occur until the application is stopped, closed, terminated etc, because that is when the file is finally closed.

Consider Pagefile.sys

This is a file on disk that is used by Windows' memory management. I often see companies have added this file to the Exclusion list for our real-time scanner (the On Access Scanner), but it is unnecessary to do so.  For this file to be scanned on Read, the On Access Scanner must be running at the time it is first opened - the pagefile is opened far earlier in the boot cycle, meaning it's not possible for us to scan it on Read. For this file to be scanned after being written to disk, it would have to be closed - and it is never closed, not while Windows is running; therefore there is never an opportunity for the real-time scanner to scan Pagefile.sys, and therefore an exclusion is unnecessary.

Update 1/20/16:  We learned of a scenario involving a pagefile of sorts where an exclusion is needed. See McAfee KnowledgeBase - Increased paged pool memory in MmSt tag with VirusScan Enterprise 8.x and Microsoft Volume Shadow….


Another real-life scenario is where a file may be ephemeral in nature, with such a short life expectancy it could be implausible or improbable, certainly impractical (no value) to scan the file prior to it being deleted. If the file is not being Read or Opened by any running process prior to it being removed from the system then the file poses no threat to the system.

Consider "Delete_On_Close"

Even after a file is closed, there is no guarantee that it will be scanned. Not all files can be scanned after they are written to disk. One such example is users of the Delete-On-Close flag; the file is opened and modified but the disposition of the file is for it to be deleted once the application closes it.  The delete occurs automatically, being taken care of by the file-system itself. Thus, if the On Access Scanner were to try and scan the file after it was closed, the file would no longer be there.


Scripted processes that manipulate files soon after creating them also present a challenge.

Consider Microsoft Office

When you open a Word or Excel document, the application creates a temporary copy of the file (*.tmp) in which to host your modifications. And, when you save the file or close the application (which prompts you to save the file), the application deletes your original and renames the TMP copy to become the new original. So in that scenario the File Close on the TMP file was immediately followed by a File Rename. Guess what happens to the your attempt to save/close the file?  It sometimes fails (it gets a SHARING_VIOLATION) - and you get prompted with the "Save As..." dialog box instead. The Office application was unable to complete the File Rename because VirusScan's On Access Scanner came along after the File Close to begin a scan... can't rename the file while we're scanning it! And so the error-handling within the Office application assumes that the file is not writable, therefore prompts you to provide a different File Name. Yet, if you simply save the file a second time, it'll succeed (because at that point we've already completed scanning it).

I believe this file-saving technique of Microsoft Office came about because in days of old when PCs crashed, as they sometimes did, all the data in your unsaved document would be lost, FOR-E-VER (*fading echo*). So a clever person thought to create a working .tmp file with autosave functionality, allowing your "unsaved" work to be recovered. It's a great idea, but it makes an assumption that it can simply rename the file after saving it, and then doesn't do anything further for error-handling except to prompt the user for a different file name. Great idea, less-than-fantastic implementation... [my opinion is totally biased, of course].


Many applications write heavily to log files. The data could be for potential debugging purposes, or auditing purposes, etc. The point being, the log gets updated with a string of data by OPENing the file, WRITE'ing to it, then CLOSE'ing it. The close triggers a scan request for our Write Scan feature.

Consider flat-file databases and log files

Some apps do this OPEN-WRITE-CLOSE operation hundreds of times a second (I know, crazy right?). And imagine that each time the file is closed it results in a scan (as explained above, the scan when writing to disk setting means we scan after a file is closed). The performance overhead in this scenario from enforcing a scan to occur before any further modification takes place is severe! Even if we did the scan asynchronously, which we do, if we were to initiate a scan request after each and every close on this ever-changing file, the number of scan requests being carried out would quickly become astronomical. And the performance hit, wow.


The second and third considerations shown here are two basic examples of phenomena in the field wherein if we enforced a scan after a file was closed would lead to compatibility and interoperability issues with numerous, I mean numerous, 3rd party applications that exist in the field and are used in production around the world. The last one points out a need to be smarter about how we respond to files that have been modified and closed.

It is for these reasons that the scanner only attempts to scan the files after they are closed, and even then, after a brief delay - that delay queues the scan request so that if the file is still being modified (as in the last consideration) then the scan request will be further delayed.


Abandoned Scan Requests

A somewhat corner-case scenario exists wherein files being written and closed could ultimately overwhelm the scanner's capacity, as in hundreds of unique file scan requests being generated (and remaining on disk) in a short space of time due to files being created/modified and closed. If the scanner were to enforce scanning each of the hundreds of scan requests being generated then performance would be slowed to unacceptable levels.

In this scenario when the available scan threads are consumed, subsequent write scan requests that would normally be picked up by an available scan thread will instead be ignored and that file will sit on disk without a scan occurring in response to the Write+Close operation. Such files will of course be scanned when Read, assuming the scan When Reading from Disk option is enabled.

Are you seeing how important that Read Scan setting is yet?


Write-Scan-Only Configuration is Vulnerable!?

Um, yeah, have you not been reading?

This was first commented on in my earlier blog "On Access Scanner - Improve Performance & Maintain Security" but it seems appropriate (perhaps necessary) to expound upon the meaning of that earlier statement (copied herewith for convenience).


NOTE: Intel Security recommends to always have the Read scan option enabled; you would only disable that option when accepting the security risks1 that implies, which is, any known or unknown malware has the potential to enter the environment and execute before having been scanned. Or in other words, you risk having an outbreak.

1 if used in conjunction with VSE's scanning profiles (described later) then the risk is minimal and tightly controlled.


Too many times I see corporate configurations of our product and the effectiveness of the software has been reduced to Scan When Writing to Disk as the only enabled setting PLUS there are exclusions on top of that too, usually. It is a vulnerable configuration to have, with one exception:  when used alongside other scanning profiles that do have the setting to Scan When Reading from Disk enabled. In these cases I have to accept that the configuration was made in the interest of Risk/Security vs. Performance, having accepted the risk presented when only the write scan option is being used.


The Purpose of the Feature: Scan When Writing to Disk

The purpose is _not_ to provide security by guaranteeing a file written to disk is scanned.

The purpose is to facilitate an opportunistic scan of the file (asynchronous in nature) in hopes to populate our scan cache with the result of that scan (when it's a clean/excluded file), so that when the file is later Read, the Scan When Reading from Disk performs faster because the cached result will be found.


A statement from our Product Management team has been provided on this topic also, in case you didn't believe me:  KB85136