I / O operation was aborted due to thread exit or application request

Question

My application works as a client application for a banking server. The application sends a request and receives a response from the bank. This application works fine, but sometimes

I / O operation was aborted due to thread exit or application request

error with error code at approximation 995.

public void OnDataReceived(IAsyncResult asyn) { BLCommonFunctions.WriteLogger(0, "In :- OnDataReceived", ref swReceivedLogWriter, strLogPath, 0); try { SocketPacket theSockId = (SocketPacket)asyn.AsyncState; int iRx = theSockId.thisSocket.EndReceive(asyn); //Here error is coming string strHEX = BLCommonFunctions.ByteArrToHex(theSockId.dataBuffer); } } 

As soon as this error starts to appear for all transactions after the same error appears, please help me deal with this problem. If possible, with some code example

Regards, Ashish Handelval

Answer 1

995 - I / O completion port error message. The error occurs when you try to continue reading from a socket when it most likely has been closed.

Getting 0 bytes from EndRecieve means that the socket has been closed, like most exceptions that EndRecieve will EndRecieve .

You need to start dealing with these situations.

Never ignore exceptions; they are thrown for some reason.

Update

Nothing says that the server is doing something wrong. A connection can be lost for many reasons, because an idle connection is closed by a switch / router / firewall, etc. Network failures can also occur.

I want to say that you SHOULD handle disconnections. The right way to do this is to take apart the socket and try to plug in a new one at regular intervals.

As for the receive callback, the more correct way to handle it is something like this (semi pseudo code):

 public void OnDataReceived(IAsyncResult asyn) { BLCommonFunctions.WriteLogger(0, "In :- OnDataReceived", ref swReceivedLogWriter, strLogPath, 0); try { SocketPacket client = (SocketPacket)asyn.AsyncState; int bytesReceived = client.thisSocket.EndReceive(asyn); //Here error is coming if (bytesReceived == 0) { HandleDisconnect(client); return; } } catch (Exception err) { HandleDisconnect(client); } try { string strHEX = BLCommonFunctions.ByteArrToHex(theSockId.dataBuffer); //do your handling here } catch (Exception err) { // Your logic threw an exception. handle it accordinhly } try { client.thisSocket.BeginRecieve(.. all parameters ..); } catch (Exception err) { HandleDisconnect(client); } } 

the reason why I use three catch blocks is simply because the logic for the middle is different from the other two. Exceptions from BeginReceive / EndReceive usually indicate disconnected connectors, while exceptions from your logic should not stop socket reception.

Answer 2

I had the same problem with RS232 communication. The reason is that your program runs much faster than comport (or slow serial communication).

To fix this, I had to check if IAsyncResult.IsCompleted==true . If not completed, then IAsyncResult.AsyncWaitHandle.WaitOne()

Like this:

 Stream s = this.GetStream(); IAsyncResult ar = s.BeginWrite(data, 0, data.Length, SendAsync, state); if (!ar.IsCompleted) ar.AsyncWaitHandle.WaitOne(); 

In most cases, ar.IsCompleted will be true .

Answer 3

What I do when this happens is Disable COM port in Device Manager and Enable .

Stop communicating with another program or thread and become free for you.

Hope this works for you. Best wishes.

Answer 4

I had this problem. I think this is caused by the opening of the socket and the lack of data for a short time after opening. I read from the series in a box with a network called Devicemaster. I changed the Devicemaster port setting from "connect always" to "connect on data" and the problem disappeared. I really respect Hans Passan, but I do not agree that this is an error code that can be easily resolved by checking the code.