Error: The delegate target that is being invoked is no longer available. Please check if it has been prematurely GC'd.

[ThaRaven403]

Describe the bug

I am getting the above error message in the dotnet.5.0.5.js file randomly when I start my Blazor WASM application, and it also sometimes occur after refreshes. To put a bit of context, I am using a SignalR connection to exchange information from the Server to the Client project (ASP.NET Core Hosted).

I have tried to pinpoint the source of the issue but couldn't, as it is intermittent. The error disappears when I remove components out of the application (for example : the page's content, a component in the header), but it comes back when I put back everything. At one point, I even got the error message to come back by simply adding an empty component in my page.

I've activated the logging on the connection, and the error above occurs right after the "Starting transport. Transfer mode: Text. Url: ...." message.

I also noticed that the issue only seems to be present in the browser that's started in debug mode. If I run the application and go to my regular browser to the site, I don't get the error.

To Reproduce

Unfortunately, I couldn't replicate the issue in a clean repo. As per @SteveSandersonMS 's request, I'm still adding the issue here so that maybe someone also happens to have the issue and might have a clear way of identifying where it's coming from.

Exceptions (if any)

When pretty-printing the error it goes down to the following:

Uncaught Error: The delegate target that is being invoked is no longer available. Please check if it has been prematurely GC'd.
at Object.invoke_delegate (dotnet.5.0.5.js:formatted:7819)
at WebSocket. (dotnet.5.0.5.js:formatted:7393)

Further technical details

• ASP.NET Core version:
  .NET5

• Include the output of dotnet --info
  .NET SDK (reflecting any global.json):
  Version: 5.0.202
  Commit: db7cc87d51

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19042
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\5.0.202\

Host (useful for support):
Version: 5.0.5
Commit: 2f740adc14

.NET SDKs installed:
3.1.408 [C:\Program Files\dotnet\sdk]
5.0.103 [C:\Program Files\dotnet\sdk]
5.0.104 [C:\Program Files\dotnet\sdk]
5.0.200 [C:\Program Files\dotnet\sdk]
5.0.202 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.All 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.27 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.27 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.14 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.25 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.27 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.14 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version
  Visual Studio 2019 16.9.0

[javiercn]

@ThaRaven403 thanks for contacting us.

Unfortunately it is impossible for us to do something about this with the information you've provided. I would suggest you try and capture as much information as you can and add it to the issue (for example, the full call stack on the error, etc.) in the hopes we can spot anything.

We would also suggest you start from a clean project and keep adding components from your solution until you are able to reproduce the issue.

[SteveSandersonMS]

@javiercn I think that matches what @ThaRaven403 is expecting. In an email discussion with @kg and @kjpou1 we suspect this may be fixed in .NET 6 anyway but can't know for sure since there's no clear repro. @ThaRaven403 if you get a chance to try updating to a .NET 6 preview and see if it still happens, that would be great to know about.

[ThaRaven403]

Thanks for the reply @javiercn . I totally agree with you, at the moment there isn't much to do with this (unless that error line number means something for someone). I've been trying to reproduce it for a few weeks now (thus I hadn't opened an issue before) but still haven't found the "winning" combination producing the error.

@SteveSandersonMS I will try this out today and let you know

[BrennanConroy]

We've seen that GC error randomly when people were using SignalR in a component and were not closing the connection when the component was disposed.

public async ValueTask DisposeAsync()
{
    await hubConnection.DisposeAsync();
}

[kg]

Yes, if you dispose a component without ensuring that the JS-side resources (connections, etc) are properly closed down, event handlers could activate after the component is collected and those event handlers would throw an exception (since their managed delegate is gone). Pinning the delegates is one solution but in most cases it shouldn't be necessary.

If people are still experiencing issues in .NET 6 there are possible workarounds we could introduce for this, but it'd be wild swings without a repro.

[ThaRaven403]

So I just tested the application under .NET6, Visual Studio 2019 16.10.0 Preview 2.

I did the same kind of page refreshes I did in .NET5, and I haven't encountered the issue. So there does seem to be something in .NET6 solving the issue. Is there something to understand from this that could help me pinpoint and produce a repro from my app?

I did encounter something though, which I don't know if it's related to the issue or to something else: If I don't open the browser's developer console (currently on Edge), everything runs smoothly. If I do open it though, after 2-3 page refreshes Edge literally freezes, getting the Not Responding in the title bar and I have to stop the application. Note that this also occurs using .NET5, so it might not be related.

@BrennanConroy I was using a SignalR connection inside of a shared component in the beginning, which I used in pages with an @ref to be able to attach additional events to it. I moved the code directly in the page, thinking it could be the issue, but the problem still occured. In both cases, I've tried implementing IDisposable or IAsyncDisposable to correctly close the connection but the error still occured

[kg]

We made various changes to lifetime management in APIs like WebSocket since the release of .NET 5, so it's possible that you were hitting a latent bug relating to the managed object being disposed while a JS-side API call was in flight. In that case, if a GC happened at the wrong time the managed object would get collected before a JS event was fired.

The lifetime management changes would potentially fix this by ensuring the JS side objects are all torn down before a GC can happen, as long as the browser satisfies all ordering guarantees you need (for example, any 'closed' or 'error' events are fired immediately when you close the socket instead of being fired 60secs later after a GC has happened). If a particular browser doesn't provide these guarantees, we may still need to make changes.

A plausible scenario here is essentially 'an event handler fires after the object with the events has been collected'. In that case, JS is trying to fire an event on the managed object, but the managed object no longer exists. Right now we generate a runtime error for that since it normally indicates a significant lifetime management error on our end, but in this scenario it would instead indicate a browser bug. We may choose to remove or weaken the error in order to handle these sorts of browser issues (if they exist), but that comes at the cost of spotting lifetime management issues elsewhere.

I hope this provides you enough info to try and puzzle through what might be causing this problem in your app. I would expect SignalR is getting lifetime management (dispose, etc) right on their end, and the error is either a tricky issue in your app's use of SignalR or just an interop issue with WebSocket and the browser that we may have fixed since .NET 5 (more likely imo).

[mkArtakMSFT]

Thanks for the additional details. Given that we haven't received any other similar feedback we're closing this issue as per your statement it's working correctly in .NET 6.