runtime: UWP 6.2.2: Connection Error : System.Net.WebSockets.WebSocketException
System : Windows 10 1803 Build 17134 UWP Min Build : 16299 UWP Target Build : 17134 Visual Studio 15.9
Connection Error :
System.Net.WebSockets.WebSocketException (203): An exception caused the WebSocket to enter the Aborted state. Please see the InnerException, if present, for more details.
---> System.ArgumentException: The specified buffer index is not within the buffer capacity.
at System.Runtime.InteropServices.WindowsRuntime.WindowsRuntimeBufferExtensions.CopyTo(IBuffer source, UInt32 sourceIndex, Byte[] destination, Int32 destinationIndex, Int32 count)
at System.Net.WebSockets.WinRTWebSocket.OnMessageReceived(MessageWebSocket sender, MessageWebSocketMessageReceivedEventArgs args)
at System.Net.WebSockets.WinRTWebSocket.ReceiveAsync(ArraySegment`1 buffer, CancellationToken cancellationToken)
at Microsoft.AspNet.SignalR.WebSockets.WebSocketMessageReader.ReadMessageAsync(WebSocket webSocket, Int32 bufferSize, Nullable`1 maxMessageSize, CancellationToken disconnectToken)
at Microsoft.AspNet.SignalR.WebSockets.WebSocketHandler.ProcessWebSocketRequestAsync(WebSocket webSocket, CancellationToken disconnectToken, Func`2 messageRetriever, Object state)
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 29 (18 by maintainers)
This bug is now fixed in the release/uwp6.2 branch.
The fix will appear in a future Microsoft.NETCore.UniversalWindowsPlatform NuGet package after version 6.2.3.
This is getting triaged and routed appropriately.
Heads up: We’re putting out a 6.2.3 update rapidly to respond to other feedback. Given the nature of the fixes we’re currently pushing, I don’t expect that package to correct this issue.
Appreciate the info @jermarti. We’re investigating.
I’m Jeremy Martin on the MRCS team at Microsoft. I did run into this today as well after upgrading MSVC to 15.9.2 from a 15.8.x (i forget the exact minor version).
My use case is inside a UWP app which is using SignalR as a client and WebSockets as the transport. This exception is thrown after the SignalR server sends it’s heartbeat message to the client, which at least on the server from tracing appears empty. I haven’t checked the actual network stream to confirm that though. Hopefully the repro is pretty easy give this, a SignalR simple project built in UWP should disconnect as soon as it receives the first heartbeat a couple seconds after connecting provided it’s using the WebSocket transport (which is default unless it’s forced into a fallback transport).
I’ve also confirmed non UWP programs connecting to the same server with the same libraries work fine with WebSockets in 15.9.2.
My current workaround is to force SignalR to use ServerSentEvents instead of WebSockets in our UWP app, which will likely introduce some weirdness but does at least work reliably.