AdsClient crashes on malformed read responses

[stegm]

We communicate via ADS to an EtherCAT Profibus-Master. For some reason the Master respond sometime with an malformed read response:

The response set the Length to 240, but actually no data exists in the response.

This works fined in the old V4 version of the ADS client, but the new V5 (5.0.528) reports a ADS timeout and then stops working, until a new client is reconnected.

The log of the ADS client contains the following entry:

AmsServer failed with Error: Das angegebene Argument liegt ausserhalb des gültigen Wertebereichs.
Parametername: start  (Port 'AdsClient' (0))!

For me it seems that the client tries to access the non-existing data and the crashes somehow.

---

Raw-Data of the response:

[RalfHeitmann]

Would it be possible to send a callstack of the situation when the Exception occurs (activating 'ExternalCode', including the call hierarchy of the TwinCAT.Ads.dll and base dlls)? Unfortunately the ArgumentOutOfRangeException is so common, that it could be fired from many places in the code. It is not so easy to reproduce the problem to track the issue without the hardware, so I could try to simulate the problem. But then I cannot be sure to locate the same issue.

[stegm]

The problem is that I cannot trigger on the ArgumentOutOfRangeException because it is inside the ADS-Dll. On the client side I get the following exception which is obviously not the root cause:

   at TwinCAT.Ads.AdsErrorCodeExtensions2.ThrowOnError(AdsErrorCode adsErrorCode)
   at TwinCAT.Ads.AdsClient.Read(UInt32 indexGroup, UInt32 indexOffset, Memory`1 readBuffer)
   at AdsResponseError.Program.Main(String[] args) in c:\temp\AdsResponseError\AdsResponseError\Program.cs:line 25

Unfortunately the mentioned log messages does not contain a stack trace either.

But I attached a simple program which uses the AdsServer class to produce such a malformed read response message.

Program.zip

This programm produces the following malformed response which crashes the client.

[RalfHeitmann]

Thanks for reporting this. I could detect and fix the problem. The behaviour of the 5.x will be a little bit different from the 4.x, it will throw an AdsErrorException with AdsErrorCode.ClientResponseInvalid immediatly with receiving the invalid frame. I assume the 4.x just ignores the erraneous frame and then throws an AdsErrorException with AdsErrorCode.ClientSyncTimout after timeout (what is valid, but suboptimal because the calling thread blocks until timeout). Please have a look at the upcoming release(s).