3

We have spent several weeks trying to fix an issue that occurs in the customer's production environment and does not occur in our test environment.

After several analyses, we have found that this error occurs only when one condition is met: processing times greater than 3600 seconds in the API.

The situation is the following:

SAP is connected to a server with Windows Server 2016 and IIS 10.0 where we have an API that is responsible for interacting with a DB use by an external system.

The process that we execute sends data from SAP to the API and this, with the data it receives from SAP and the data it obtains from the DB of the external system, performs a processing and a subsequent update in the DB.

This process finishes without problems when the processing time in the API is less than 3600 seconds.

On the other hand, when the processing time is greater than 3600 seconds, the API generates the response correctly, and the server tries to return the response to SAP, but it is not possible.

Below I show an example of a server log entry when it tries to return a response after more than 3600 seconds of API processing. As you can see, a 995 error occurs: (I have censored some parts)

Error detected in the server log

Any idea where the error could come from?

We have compared IIS configurations in Production and Test. We have also reviewed the parameters of the SAP system in Production and Test and we have not found anything either.

I remain at your disposal to provide any type of additional information that may be useful for solving the problem.

UPDATE 1 - 02/09/2022

After enabling FRT (Failed Request Tracing) on IIS for 200 response codes, looking at the event log of the request that is causing the error, we have seen this event at the end:

Error detected after enabling FRT

Any information about what could be causing this error? ErrorCode="The I/O operation has been aborted because of either a thread exit or an application request. (0x800703e3)"

UPDATE 2 - 02/09/2022 Comparing configurations from customer's environment and our test environment:

Configurations from customer's environment and our test environment

JVL
  • 69
  • 8
  • 2
    What kind of web API are you hosting on IIS? If you enable FRT on such requests (response code 200), you should be able to learn more about what happens under the hood and where the Win32 status code 995 comes from. – Lex Li Sep 01 '22 at 07:25
  • What details of the API could be interesting for understanding the problem? I'm not an expert in API's but I can ask for details. What I can tell you is that it is a REST API developed with C#. I will try to enable FRT for 200 response codes and I will do some test. After this, I will report the results. – JVL Sep 01 '22 at 07:45
  • Hi again @LexLi, I've updated the post with the relevant information I got from enabling FRT for 200 response codes. As a summary, looking at the event log of the request that is causing the error, we have seen this event at the end: 3157. | GENERAL_FLUSH_RESPONSE_END | BytesSent="0", ErrorCode="The I/O operation has been aborted because of either a thread exit or an application request. (0x800703e3)" Does this provide any clue for detecting why is this error occurring? I think it's important to remember that this only happens after more than 3600 seconds of API processing. – JVL Sep 02 '22 at 05:12

2 Answers2

2

There is a Firewall between SAP Server and IIS Server with the default idle timeout configured for TCP (3600 seconds). This is not happening in Test Environment because there is no Firewall.

Establishing a Firewall policy specifying a custom idle timeout for this service (7200 seconds) the problem will be solved.

JVL
  • 69
  • 8
0

sc-win32 status 995, the I/O operation has been aborted because of either a thread exit or an application request.

Please check the setting of minBytesPerSecond configuration parameter in IIS. The default "minBytesPerSecond" is 240.

Specifies the minimum throughput rate, in bytes, that HTTP.sys enforces when it sends a response to the client. The minBytesPerSecond attribute prevents malicious or malfunctioning software clients from using resources by holding a connection open with minimal data. If the throughput rate is lower than the minBytesPerSecond setting, the connection is terminated.

YurongDai
  • 1,362
  • 1
  • 2
  • 7
  • This parameter is configured with value 240 in both enviroments: customer's enviroment (where we are getting the error) and our test enviroment (where this error is not happening). I will update the post with this information. – JVL Sep 02 '22 at 06:15
  • By the way is there a virus protection program installed on the customer's server (where you are getting the error)? Like AVG Internet Security. – YurongDai Sep 02 '22 at 09:42
  • Those are the different security tools which are installed in customer's server: claudia microclaudia FusionInventory Agent NetWorker Client NetWorker Extended Client Snow Iventory Agent Trend Micro Deep Security Agent – JVL Sep 02 '22 at 10:55
  • 1
    Not sure if these virus protection programs have any influence.I have seen a situation where a virus protection program (AVG Internet Security) was installed on the server and the problem was solved after uninstalling it. – YurongDai Sep 05 '22 at 09:47
  • We have started communication with Security department in order to check if some of those virus protection programs are causing the problem. I will update the post with their answer once they analyze the situation. Thank you so much for the idea. – JVL Sep 05 '22 at 11:14
  • Hi again @YurongDai, we have already verified that those cibersecurity tools are not able to stop any connection, so we can discard this option. Do you have any more suggestion? – JVL Sep 12 '22 at 11:15
  • It is difficult to reproduce this problem , I suggest you open a case via: https://support.microsoft.com. – YurongDai Sep 16 '22 at 07:18