Microsoft Graph SDK - new issue uploading files to OneDrive since 16/17 April 2021

[DavidParkerUk]

Describe the bug Since the weekend, one of our web applications is failing to upload files to OneDrive. It's a live application that has been in use for some time and which we haven't made any recent changes to. The application is performing chunked uploads using CreateUploadSession(), GetUploadChunkRequests() and GetChunkRequestResponseAsync() as the files can potentially be large. Upon the call to GetChunkRequestResponseAsync(), we're getting an AggregateException thrown with a single InnerException.

Microsoft.Graph.ServiceException: Code: generalException Message: An error occurred sending the request. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

Full exception details later on.

The application was last working on Fri 16 April 2021 and the errors started on 17 April.

I've carried out some tests, and the issue only appears to occur on business/office/sharepoint accounts. On personal Microsoft accounts it still works fine. Also, regular uploads using PutAsync() still work, it's only the chunked uploads that don't.

To Reproduce Simplified version of the code below. Must be using a business/office/sharepoint type of account for the issue to occur. // File content is in byte array "fileContent" // The ID of the parent folder is in "parentId"

using (var fileStream = new MemoryStream(fileContent)) { var uploadSessionParams = new DriveItemUploadableProperties { AdditionalData = new Dictionary<string, object>() }; uploadSessionParams.AdditionalData.Add("@microsoft.graph.conflictBehavior", "rename"); var driveId = Api.Me.Drive.Request().GetAsync().Result.Id; var uploadSessionRequest = Api.Drives[driveId].Items[parentId].ItemWithPath(fileName).CreateUploadSession(uploadSessionParams).Request(); var uploadSession = uploadSessionRequest.PostAsync().Result;

const int maxSizeChunk = 320 4 1024; var provider = new ChunkedUploadProvider(session, Api, inStream, maxSizeChunk); var chunkRequests = provider.GetUploadChunkRequests(); var exceptions = new List(); var readBuffer = new byte[maxSizeChunk]; foreach (var request in chunkRequests) { // Exception is thrown on the next line on the first pass of the loop var result = provider.GetChunkRequestResponseAsync(request, readBuffer, exceptions).Result; if (result.UploadSucceeded) { return result.ItemResponse; } } }

Expected behavior The file should be uploaded successfully.

Client version Microsoft.Graph client library 1.7.0. Microsoft.Graph.Core client library 1.7.0.

Desktop (please complete the following information): It's an ASP.NET MVC application hosted in IIS. The issue was first raised on a client's live server which is running Server 2012 R2 Datacenter 64-bit and I've replicated also it on a 64-bit Windows 10 client.

Additional context As above, the issue started happening sometime on either 16 April or 17 April. It only seems to be affecting chunked uploads, not other operations (whether we're uploading a new file or replacing an existing one doesn't make a difference) and it only appears to affect business accounts not personal ones.

Full exception details {Microsoft.Graph.ServiceException: Code: generalException Message: An error occurred sending the request. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult) at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult) --- End of inner exception stack trace --- at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult) at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar) --- End of inner exception stack trace --- at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context) at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar) --- End of inner exception stack trace --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Graph.HttpProvider.d21.MoveNext() --- End of inner exception stack trace --- at Microsoft.Graph.HttpProvider.d21.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Graph.HttpProvider.d19.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Graph.UploadChunkRequest.d17.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.Graph.UploadChunkRequest.d16.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at Microsoft.Graph.ChunkedUploadProvider.d17.MoveNext()} AB#9132

[MIchaelMainer]

@JeremyKelley @ificator Has there been any issues in OD4B since April 17th?

[ificator]

I'm not aware of any changes that would correlate to that timeline. And unfortunately that response really doesn't give us much to work with. There really are very few scenarios that would trigger that kind of failure so I'm going to take a guess and say that it's probably a lack of TLS1.2 support.

It's broadly talked about here: https://docs.microsoft.com/en-us/microsoft-365/compliance/prepare-tls-1.2-in-office-365?view=o365-worldwide

I'm trying to track down if there was a recent change to block tls1.0/tls1.1 in SharePoint, but I'm pretty sure it's been running like that for quite some time. I have, however, confirmed that Microsoft Graph still accepts TLS1.0/TLS1.1... which means if the client in question doesn't support TLS1.2 it would explain why the Microsoft Graph calls succeeded but the SharePoint calls fail.

Can we confirm the client does support TLS1.2? Discounting that will help us figure out next steps.

[ificator]

I've now confirmed that there was indeed a rollout that disabled tls1.0 and tls1.1 for a subset of SharePoint tenants that aligns with your timeline.

[MIchaelMainer]

They are using a very old version of the client. TLS 1.2 is supported by default in .NET 4.6 or greater. With .NET 4.5, it is supported, but not by default and must be opted-in. @DavidParkerUk is your application running on .NET 4.5?

[DavidParkerUk]

I've had a look and can confirm that the application is running on .NET 4.5. Thanks for the responses, it does sound like a TLS related issue.

[DavidParkerUk]

Setting the SchUseStrongCrypto=1 and SystemDefaultTlsVersions=1 registry keys on the client appears to resolve the problem.

[ificator]

Thank you for confirming @DavidParkerUk, and for letting us know your solution.