Runtime: dotnet.exe 'Access violation'

[cschuchardt88]

Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager:Information: User profile is available. Using 'C:\Users\NoShow\AppData\Local\ASP.NET\DataProtection-Keys' as key repository and Windows DPAPI to encrypt keys at rest.
Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request starting HTTP/1.1 GET https://localhost:5001/
Microsoft.AspNetCore.Routing.EndpointMiddleware:Information: Executing endpoint 'pwi.web.looms.core.Controllers.HomeController.Index (pwi.web.looms.core)'
Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker:Information: Route matched with {action = "Index", controller = "Home"}. Executing action pwi.web.looms.core.Controllers.HomeController.Index (pwi.web.looms.core)
The program '[15312] dotnet.exe' has exited with code -1073741819 (0xc0000005) 'Access violation'.

This is all i get for debug output.

[RussKeldorph]

@cschuchardt88 Could you please explain how to reproduce this? There doesn't seem to be anything actionable here.

[cschuchardt88]

Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager:Information: User profile is available. Using 'C:\Users\NoShow\AppData\Local\ASP.NET\DataProtection-Keys' as key repository and Windows DPAPI to encrypt keys at rest.
Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request starting HTTP/1.1 GET https://localhost:5001/
Microsoft.AspNetCore.Routing.EndpointMiddleware:Information: Executing endpoint 'NoNameCrashTest.Controllers.HomeController.Index (NoNameCrashTest)'
Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker:Information: Route matched with {action = "Index", controller = "Home"}. Executing action NoNameCrashTest.Controllers.HomeController.Index (NoNameCrashTest)
The program '[13240] dotnet.exe' has exited with code -1073741819 (0xc0000005) 'Access violation'.

I know this isn't the right way to do it. For some reason Visual Studio JIT doesn't want to catch it.

Check files Startup.cs and HomeController.cs

//Startup.cs 
services.AddSingleton<ICrashDotNetExecutable>(sp => sp.GetService<ICrashDotNetExecutable>());
//HomeController.cs
public HomeController(ICrashDotNetExecutable crashHere) {}
//declare
public Interface ICrashDotNetExecutable { }

NoNameCrashTest.zip

[sergiy-k]

@josalem, could you please try to repro this issue?

[josalem]

I'm able to reproduce the crash and message in VS as described. After a little digging, it looks like the AV shown in VS is most likely a stack overflow that is not being bubbled up correctly. I'm taking a deeper look at why the SO is being incorrectly reported in VS.

Debugging this repro under windbg shows a stack overflow. Similarly, if you run the application without the VS debugger, you will see the application crash and print a statement about shutting down due to stack overflow.

[0xd4d]

Could be related: https://github.com/dotnet/coreclr/issues/21579

[josalem]

@davidfowl - The SO may be considered a bug in ASP.NET Core as well. Even though it is improper use of the dependency injection APIs, there isn't an exception or error message indicating that this use is improper. The stack overflow looks to be a recursive search into the concurrent dictionary that houses registered services: services.AddSingleton<ICrashDotNetExecutable>(sp => sp.GetService<ICrashDotNetExecutable>()).

[davidfowl]

The cycle detection doesn't work when there are explicit calls to GetService<T> in the graph because it would be extremely inefficient. Maybe it's something we can enable in development only. I don't know if that's the issue everyone is running into here but @josalem can you open an issue in https://github.com/aspnet/Extensions

[tommcdon]

Tracking this issue on https://github.com/dotnet/coreclr/issues/18541