Download cancels with .download extension and doesn't finish / succeed

[tinodin]

It can rarely happen that the downloader after using await download.StartAsync(); finishes without fully downloading the file. Whats left is an almost finished .download file that was not renamed, and when manually renamed and trying to extract it, it throws errors. It doesn't retry, continue or throw any errors that something went wrong.

[tinodin]

Sorry @bezzad, I forgot to catch the exception on DownloadProgressChanged, now i get the error. How can I prevent this / how can this be fixed because it is really annoying when some users get this error when it works fine for others.

System.Exception
Message: Downloader package failed: The decryption operation failed, see inner exception.
HResult: 0x80131500
Source: 

**InnerException:**
System.IO.IOException: The decryption operation failed, see inner exception.
 ---> System.ComponentModel.Win32Exception (0x80090330): The specified data could not be decrypted.
   --- End of inner exception stack trace ---
   at System.Net.Security.SslStream.<ReadAsyncInternal>d__172`1.MoveNext() + 0x701
--- End of stack trace from previous location ---
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16) + 0x1e
   at System.Net.Http.HttpConnection.ContentLengthReadStream.<ReadAsync>d__3.MoveNext() + 0x26a
--- End of stack trace from previous location ---
   at Downloader.ThrottledStream.<ReadAsync>d__23.MoveNext() + 0x250
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ReadStream>d__19.MoveNext() + 0x8d7
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ReadStream>d__19.MoveNext() + 0xd1b
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ReadStream>d__19.MoveNext() + 0xfb5
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<DownloadChunk>d__17.MoveNext() + 0x3f7
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<DownloadChunk>d__17.MoveNext() + 0x6cc
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<Download>d__15.MoveNext() + 0xf7
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<Download>d__15.MoveNext() + 0x4c7
--- End of stack trace from previous location ---
   at Downloader.DownloadService.<DownloadChunk>d__15.MoveNext() + 0x386

AI told me this:

"When parallel chunk downloading is enabled over HTTPS on Windows, SslStream occasionally throws a SEC_E_DECRYPT_FAILURE (0x80090330) decryption exception due to packet drops or security filters. The library should catch low-level Schannel / SslStream decryption errors gracefully inside ChunkDownloader and automatically retry using a single-connection fallback, rather than letting the entire download service fail immediately."

[tinodin]

Im also getting this sometimes, using the httpClient as a fallback works and the status code is success:

System.Exception
Message: Primary download failed for: https://msedge.sf.dl.delivery.mp.microsoft.com/filestreamingservice/files/7dedb563-79f6-48af-b588-dd8e97f4b73c/MicrosoftEdgeWebView2RuntimeInstallerX64.exe
Package: Status=Failed, SaveComplete=False, FileName=C:\Users\AutoOS\AppData\Local\Temp\MicrosoftEdgeWebView2RuntimeInstallerX64.exe
Downloader error: TaskCanceledException: The operation was canceled.
Files in path: [.ses, MicrosoftEdgeWebView2RuntimeInstallerX64.exe.download, timedateregion.ps1, UserOnce.log, wct1313.tmp, wct1FAB.tmp, wct1FAC.tmp, wct4D9F.tmp, wct4E3B.tmp, wctA4E7.tmp, wctC97B.tmp, wmsetup.log]
HTTP Status Code: 200 (OK)
Fallback download succeeded

HResult: 0x80131500
Source: 
**InnerException:**
System.Threading.Tasks.TaskCanceledException: The operation was canceled.
 ---> System.IO.IOException: Unable to read data from the transport connection: The I/O operation has been aborted because of either a thread exit or an application request..
 ---> System.Net.Sockets.SocketException (995): The I/O operation has been aborted because of either a thread exit or an application request.
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError, CancellationToken) + 0x3d
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource<System.Int32>.GetResult(Int16) + 0x58
   at System.Net.Security.SslStream.<EnsureFullTlsFrameAsync>d__170`1.MoveNext() + 0x1c2
--- End of stack trace from previous location ---
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16) + 0x23
   at System.Net.Security.SslStream.<ReadAsyncInternal>d__172`1.MoveNext() + 0x701
--- End of stack trace from previous location ---
   at System.Runtime.CompilerServices.PoolingAsyncValueTaskMethodBuilder`1.StateMachineBox`1.System.Threading.Tasks.Sources.IValueTaskSource<TResult>.GetResult(Int16) + 0x23
   at System.Net.Http.HttpConnection.ContentLengthReadStream.<ReadAsync>d__3.MoveNext() + 0x26a
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpConnection.ContentLengthReadStream.<ReadAsync>d__3.MoveNext() + 0x48b
--- End of stack trace from previous location ---
   at Downloader.ThrottledStream.<ReadAsync>d__23.MoveNext() + 0x250
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ReadStream>d__19.MoveNext() + 0x8d7
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ReadStream>d__19.MoveNext() + 0xd1b
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ReadStream>d__19.MoveNext() + 0xfb5
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<DownloadChunk>d__17.MoveNext() + 0x3f7
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<DownloadChunk>d__17.MoveNext() + 0x6cc
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<Download>d__15.MoveNext() + 0xf7
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<Download>d__15.MoveNext() + 0x4c7
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ContinueWithDelay>d__16.MoveNext() + 0x431
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<Download>d__15.MoveNext() + 0x292
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ContinueWithDelay>d__16.MoveNext() + 0x431
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<Download>d__15.MoveNext() + 0x292
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ContinueWithDelay>d__16.MoveNext() + 0x431
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<Download>d__15.MoveNext() + 0x292
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ContinueWithDelay>d__16.MoveNext() + 0x431
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<Download>d__15.MoveNext() + 0x292
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<ContinueWithDelay>d__16.MoveNext() + 0x431
--- End of stack trace from previous location ---
   at Downloader.ChunkDownloader.<Download>d__15.MoveNext() + 0x292
--- End of stack trace from previous location ---
   at Downloader.DownloadService.<DownloadChunk>d__15.MoveNext() + 0x386
--- End of stack trace from previous location ---
   at Downloader.DownloadService.<DownloadChunk>d__15.MoveNext() + 0x565
--- End of stack trace from previous location ---
   at Downloader.DownloadService.<SerialDownload>d__13.MoveNext() + 0x396
--- End of stack trace from previous location ---
   at Downloader.DownloadService.<StartDownload>d__2.MoveNext() + 0x2f1

[bezzad]

Fixed in v5.6.0 — now live on NuGet.

What was wrong: if the server ended the response stream before delivering the full size it
had advertised — but did so as otherwise-valid HTTP (a clean EOF, no transport error) — the chunk
read loop just stopped and the partial chunk was silently accepted as "complete". The result was
a download that finished with no error, no retry, and an unfinished .download file.

What changed:

• After each chunk, the library now verifies it actually received all the advertised bytes.
• If a chunk ends short, it is treated as a retryable failure: on a range-capable server it
  resumes the missing bytes (up to MaxTryAgainOnFailure).
• If it can't recover (server doesn't support range, or retries are exhausted), the download now
  fails loudly with a new IncompleteDownloadException (delivered via
  DownloadFileCompleted's e.Error) instead of silently "succeeding".

So you'll now either get the complete file, or a clear error you can react to — never a silent
half-file.

Please upgrade to 5.6.0 and retry your scenario. If it still reproduces, please reply with:

• Your full DownloadConfiguration (especially ChunkCount, ParallelDownload,
  MaxTryAgainOnFailure, EnableAutoResumeDownload)
• The download URL or its response headers (Content-Length, Accept-Ranges, Content-Range)
• What you see in DownloadFileCompleted (e.Cancelled, e.Error) and Package.Status
• Roughly how often it happens and the approximate file size