MapAssets System.ArgumentOutOfRangeException: (Parameter 'offset') Actual value was 0.

[Bartmax]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

Doing a local publish to test MapAssets it worked once and then I get this error and I wasn't able to understand why or how to solve. Deleted all output and restore/rebuild/republish but I was receiving the described exception on any request to an asset. not sure what's going on

Expected Behavior

no error

Steps To Reproduce

not sure

Exceptions (if any)

fail: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware[1]
      An unhandled exception has occurred while executing the request.
      System.ArgumentOutOfRangeException:  (Parameter 'offset')
      Actual value was 0.
         at Microsoft.AspNetCore.Http.SendFileResponseExtensions.CheckRange(Int64 offset, Nullable`1 count, Int64 fileLength)
         at Microsoft.AspNetCore.Http.SendFileResponseExtensions.SendFileAsyncCore(HttpResponse response, IFileInfo file, Int64 offset, Nullable`1 count, CancellationToken cancellationToken)
         at Microsoft.AspNetCore.StaticAssets.StaticAssetsInvoker.SendAsync(StaticAssetInvocationContext context)
         at Microsoft.AspNetCore.StaticAssets.StaticAssetsInvoker.Invoke(HttpContext context)
         at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddlewareImpl.<Invoke>g__Awaited|10_0(ExceptionHandlerMiddlewareImpl middleware, HttpContext context, Task task)

.NET Version

9.0.100-preview.5.24307.3

Anything else?

[paulomorgado]

@Bartmax,

What is your target system?

I'm getting this only when running/debugging from container SDK or when publishing to linux-64 and running from a container from "mcr.microsoft.com/dotnet/sdk:9.0-preview".

But runs fine on Windows when publishing as portable and runs fine when launched on WSL.

[Bartmax]

Win x64

[paulomorgado]

I get the same behavior, but no exceptions debugging with the "Container (.NET SDK)" profile, but no exceptions.

Fiddler Classic can load the response content, but Edge and PowerShell can't.

I tried this:

using var client = new HttpClient();
using var request = new HttpRequestMessage(HttpMethod.Get, "http://localhost:32809/favicon.ico");
using var response = await client.SendAsync(request);
var content = await response.Content.Dump().ReadAsStringAsync();

And got content when debugging, but still nothing in the browser.

As for the version I deployed to a SDK container, I can see the exception.

[javiercn]

@Bartmax does the issue involve Blazor webassembly?

[paulomorgado]

@javiercn,

@Bartmax does the issue involve Blazor webassembly?

This involves only serving static files.

[paulomorgado]

I tried to capture a memory dump using ProcDump on the container, but it failed: https://github.com/dotnet/runtime/issues/104525#issuecomment-2212512491

@Bartmax, if you can repro this on Windows, you can use ProcDump to capture a memory dump with:

procdump -ma -e 1 -f ArgumentOutOfRangeException <PID or process name>

[paulomorgado]

After the upgrade to Preview6 I started getting file not found exceptions instead.

I set ASPNETCORE_CONTENTROOT to the root of where the app is running from and it worked.

[Bartmax]

Here's a dump. It does not involve Web assembly. @paulomorgado https://drive.google.com/file/d/1vdDT6Fk4slbGJ4yNhL3RRvbf5kDNR7Na/view?usp=sharing

[paulomorgado]

@Bartmax,

Here's a dump. It does not involve Web assembly. @paulomorgado https://drive.google.com/file/d/1vdDT6Fk4slbGJ4yNhL3RRvbf5kDNR7Na/view?usp=sharing

Beware that memory dumps might disclose sensitive information.

[paulomorgado]

This is, pretty much, what I had figured out looking at the code:

Because of the optimizations, the parameter values are not available. But we can infer that offset is either less than 0 or greater than fileLength.

If we look at the previous stack frame:

We see that that's the case.

Why? I don't know yet.

I see you are still using Preview5.

Can you try with Preview6?

[Bartmax]

It works ok on preview6.

[javiercn]

@Bartmax I'm closing this issue as whatever problem happened here seems to have been addressed.