Runtime: UWP 6.2.2: Connection Error : System.Net.WebSockets.WebSocketException

[KalpeshChheda]

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)

[arminrasoulian]

I have exact the same issue
VS: 15.9.2
Min and Target SDK version: 1809

[karelz]

Looks similar to dotnet/runtime#25730 - can you check if there are 0-byte receives?

[karelz]

@KalpeshChheda @arminrasoulian are you from the same team/company? Or did you hit it independently on the same day?
(I have another person soon to chime here who discovered it independently today)

[karelz]

@MattWhilden @tommcdon how can I reverse engineer the UWP versions from VS updates here?
There seems to be some regression introduced between VS 15.8 and 15.9.2.

Also, how can I tell if the class is part of shared framework. It does not seem to be standalone nuget package.
cc @caesar1995

[jermarti]

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.

[MattWhilden]

@karelz To determine which set of framework and tools you're building with you'd need to know the Target Windows SDK minimum version AND the version of the Microsoft.NETCore.UniversalWindowsPlatform nuget packages. The version of VS is helpful for some tooling related issues (debugger etc) but most of the guts are decoupled from actual VS versions.

Shared Framework for .NET Native means something completely different than for Core so I'd like to understand your goal before going too deep.

[jermarti]

For me the Target Version is 1809 and the Min Version is 1803. This is unchanged from when the UWP app worked before installing MSVC 15.9.2.
The Microsoft.NETCore.UniversalWindowsPlatform appears to have been upgraded from "6.2.0-Preview1-26502-02" to "6.2.2" on the project however.

[jermarti]

Also, nuget does not show "6.2.0-Preview1-26502-02" as a version available for download, which makes me think it was coupled to the previous 15.8.x MSVC in some way (though it's not clear how).
I just tested downgrading from 6.2.2 to the next nearest version in nuget, 6.1.9. It downgraded associated packages but the same behavior persists in the UWP app with WebSockets.

[MattWhilden]

Appreciate the info @jermarti. We're investigating.

[arminrasoulian]

@karelz No, We don't know each other.
I've used SignalR in my Xamarin.Forms app. It's working properly on Android and iOS projects. But when I run it on UWP, I see this error.

[MattWhilden]

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.

[corykroll]

I'm having this exact same issue (The specified buffer index is not within the buffer capacity) with Microsoft.AspNet.SignalR.Client in my UWP app. I downgrade to 2.3.0 and this error no longer comes up.

[DerPate2010]

I can confirm the same issue using SignalR 2.4.0 on VS 15.9.2 in an UWP app.

[Strypper]

Yes following microsoft docs and got this error on UWP

[corradocavalli]

I have the same problem after moving SignalR code inside a netstandard 2.0 lib (thus forced to use SignalR client v 2.4)
This is a showstopper for us, any new or workaround?

[jermarti]

Until this is fixed I'm using long polling instead of websockets as a workaround for UWP clients only

[karelz]

@MattWhilden do you have any update?
I admit I lost all context - there is not repro here, or clear clarification if it was regression between some specific versions, so we would need to start investigation from scratch, unless it was caused by the known UWP branch problems we talked about in December ...

[tommcdon]

@karelz @MattWhilden I am able to repro the System.ArgumentException with the following:

System.ArgumentException: The specified buffer index is not within the buffer capacity.   

System.Runtime.WindowsRuntime.dll!System.Runtime.InteropServices.WindowsRuntime.WindowsRuntimeBufferExtensions.CopyTo(Windows.Storage.Streams.IBuffer source, uint sourceIndex, byte[] destination, int destinationIndex, int count)
System.Net.WebSockets.Client.dll!System.Net.WebSockets.WinRTWebSocket.OnMessageReceived(Windows.Networking.Sockets.MessageWebSocket sender, Windows.Networking.Sockets.MessageWebSocketMessageReceivedEventArgs args)

With the following locals:

Name            Value       Type
sourceIndex     0       uint
destination     {byte[0]}   byte[]
destinationIndex    0       int
count           0       int

Based off of that above, this looks like dotnet/runtime#25730 and the fix is to port dotnet/corefx#29810 to the release/uwp6.2 branch in CoreFX (https://github.com/dotnet/corefx/tree/release/uwp6.2).

[karelz]

Thanks @tommcdon! Do you know which version it works on correctly? (UWP6.1?)
It seems that the original bug was a regression from something ... I'd like to find out what caused the regression. @davidsh you did the fix, do you have more insights?

[tommcdon]

I tested this on 6.1.9 which is based off of CoreFX 2.0 and it still reproduced the issue.

[davidsh]

It seems that the original bug was a regression from something ... I'd like to find out what caused the regression. @davidsh you did the fix, do you have more insights?

The original bug was a regression. It was a regression introduced by dotnet/corefx#21755 and related changes for a feature/behavior change:

With these changes, the UWP implementation of ClientWebSocket.ReceiveAsync hands partial WebSocket message data back to the app as soon as it arrives. This eliminates the behavioral difference between .NET Core and UWP tracked by issue dotnet/runtime#22311.

That PR introduced this regression regarding 0-byte receives. So, my PR dotnet/corefx#29810 was able to fix that regression.

So, yes, the fix for this issue is to port the appropriate fixes contained in dotnet/corefx#29810 from the master branch into the latest UWP servicing branch.

[karelz]

Thanks @davidsh!
Looks like UWP releases did not have tags, so I don't know which UWP version the original regression dotnet/corefx#21755 (commit 09d029cbe1734ffb4f2ee5f259acfd69ea172158) was introduced first.

That said, it seems we need to port the fix David identified, smoke test it and ship it.
@tommcdon do you have advice how to do that? Which branch, when and who? Any shiprooms involved?

[tommcdon]

@karelz or @davidsh please create a PR for porting dotnet/corefx#29810 to release/uwp6.2 CoreFX (https://github.com/dotnet/corefx/tree/release/uwp6.2) and we will approve and merge it.

[tommcdon]

@zamont as FYI, we will want to consume this in the UWP metapacakge once it is fixed

[davidsh]

@karelz or @davidsh please create a PR for porting dotnet/corefx#29810 to release/uwp6.2 CoreFX (https://github.com/dotnet/corefx/tree/release/uwp6.2) and we will approve and merge it.

I have submitted PR dotnet/corefx#34558 against the release/uwp6.2 branch which fixes this.

[davidsh]

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.

[corradocavalli]

@davidsh any tentative date for the public release? 🙄

[davidsh]

@davidsh any tentative date for the public release? 🙄

@tommcdon Can you comment on when the next servicing release for release/uwp6.2 will be that will contain this fix?

[tommcdon]

@davidsh any tentative date for the public release? 🙄

@tommcdon Can you comment on when the next servicing release for release/uwp6.2 will be that will contain this fix?

We are planning a uwp6.2 release containing this fix this month