ERR_RECIEVEING_RESPONSE exception

[Migration User]

Scan engine version 5.2.8

We are calling the scan engine through an api call in c#

We are experiencing intermittent exceptions on the same file when scanning.  At the same time we are scanning 100+ files but this one file ittermittently gets the exception shown in the title.  The file size is around 120k which is larger than some files but smaller than others being scanned.

We are using streaming and here is a code snippet of what we are doing.  The error occurs on the Finish() call.  Any help is much appreciated.  I have access to the xml config values so I can answer any questions about the values in them.

 

var manager = new ScanRequestManager();

var engines = new List<ScanEngineInfo>{

new ScanEngineInfo(

Properties.Settings.Default.ScanEngineServer,

Properties.Settings.Default.ScanEnginePort) };

manager.PrepareForScan(engines, int.MaxValue, int.MaxValue);

var scan = manager.CreateStreamScanRequest(Policy.SCAN);

scan.Start(string.Empty, string.Empty);

...Bunch of business logic filling an 8k buffer

scan.Send(buffer);

...More business code

var result = scan.Finish(outputStream);

 

[SSE-JDavis]

Sounds like you need to incorporate better error handling into your code.

What do you see in the Scan Engine logs when you run a detailed report? Scan Engine should log the issue it had with the file.

I am wondering why you are scanning the same file more than once.

[Migration User]

So, you are saying that the intermittent scan errors are acceptable and should be handled and retried in code?

The reason we are scanning the same file over and over again is to troubleshoot the issue.  It is not normal practice if the scan engine is working properly.

The scan logs didnt show a thing.  We turned on verbose logging and nothing was shown that we could see.  Is there another log to look at that will show the error?  The ones we looked at in the /log directory only showed information on files that were scanned.  Nothing in there about errors.

[SSE-JDavis]

We will not be able to scan every file, that is true.

Perhaps you can perform a packet capture during the exchange so you can see exactly where the ICAP conversation breaks down.

[Migration User]

I understand the scan engine will not be able to scan every file and we handle those exceptions.  I dont understand how we scan 100+ files in a directory and only 1 file has intermittent issues.  The scan engine is running local so we should not be having any network issues and the file is just like the other files in that directory.  It is a .txt file.

We are going to upgrade to the latest version to see if that helps.

[SSE-JDavis]

What is the result if you scan this file with the ssecls?

I was not suggesting that there are any network issues, but a packet capture would allow you to see the full ICAP conversation.

[Migration User]

I ran it multiple times and could not get it to fail using ssecls

Virus scan process began : Tue May 01 09:55:40 2012
Virus scan process completed : Tue May 01 09:55:40 2012

        Defs Version = 20120430.002
 Commandline Scanner = 4.3.2.13

         Total Bytes = 122865 (Kbytes 119.9854)
             Elapsed = 0.0310
           Scan Rate =  3.78 (Mbytes/sec)

      Files Excluded = 0
       Files Scanned = 1
 Directories Scanned = 0
Directories Excluded = 0
       Files Skipped = 0
    Files Scan Error = 0
      Files Infected = 0

No error was found during the scan

[SSE-JDavis]

The ssecls is our testing tool. There may need to be some more debugging done on your code to determine what the exception was and how to handle it more gracefully.

[Migration User]

Digging a little deeper we found this exception.

System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

 

[Micah Van Der Kamp]

I know this is an old thread, but I was having the same issue described here. I ran the command line tool (ssecls.exe) on the files, that were failing via the API, and they passed the scan, though it took > 20 seconds to complete (most files normally get scanned within a second). I found that the API has a method called "PrepareForScan". The second parameter is a socket read/write timeout and the example provided, that we had followed, set this at 20000 (ms). If a scan takes more than 20 seconds than this error occurs. Increasing this value solved our problem.