netcore 1.3 WebListener + WIndows Auth: Safe handle has been closed

[blowdart]

From @sandrey80 on January 28, 2018 15:50

Windows Identity with ASP.net Core 1.3 self-hosted app with WebListener

var host = new WebHostBuilder()
                .UseWebListener(options =>
                {
                    options.ListenerSettings.Authentication.Schemes = AuthenticationSchemes.Negotiate | AuthenticationSchemes.NTLM;
                    options.ListenerSettings.Authentication.AllowAnonymous = true;
                })

Some times i'm getting error

An unhandled exception has occurred: Safe handle has been closed

at methods like 'User.IsInRole(group)' or 'User.Identity.Name' and app crashed at this dumb method

string userName;
try
{
    userName = User.Identity.Name;
}
catch
{
    userName = "undefined";
}
return userName;

The stack trace looks like that:

 Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.Invoke Error: An unhandled exception has occurred: Safe handle has been closed Safe handle has been closed    at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)
       at System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle pHandle, Boolean& success)
       at Interop.mincore.LsaLookupSids(SafeLsaPolicyHandle handle, Int32 count, IntPtr[] sids, SafeLsaMemoryHandle& referencedDomains, SafeLsaMemoryHandle& names)
       at System.Security.Principal.SecurityIdentifier.TranslateToNTAccounts(IdentityReferenceCollection sourceSids, Boolean& someFailed)
       at System.Security.Principal.SecurityIdentifier.Translate(IdentityReferenceCollection sourceSids, Type targetType, Boolean forceSuccess)
       at System.Security.Principal.SecurityIdentifier.Translate(Type targetType)
       at System.Security.Principal.WindowsIdentity.<GetName>b__42_0()
       at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Security.Principal.WindowsIdentity.RunImpersonatedInternal(SafeAccessTokenHandle token, Action action)
       at System.Security.Principal.WindowsIdentity.GetName()
       at Microsoft.AspNetCore.Authorization.DefaultAuthorizationService.GetUserNameForLogging(ClaimsPrincipal user)
       at Microsoft.AspNetCore.Authorization.DefaultAuthorizationService.<AuthorizeAsync>d__8.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.AspNetCore.Mvc.Authorization.AuthorizeFilter.<OnAuthorizationAsync>d__16.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.AspNetCore.Mvc.Internal.ControllerActionInvoker.<InvokeAsync>d__20.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.AspNetCore.Builder.RouterMiddleware.<Invoke>d__4.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.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>d__6.MoveNext() AsyncTaskMethodBuilder.Start => <Invoke>d__4.MoveNext => ExceptionHandlerMiddleware.Invokee

Can't reproduce it on debug, but at production get crashed once a week.

Any suggestions?

Copied from original issue: aspnet/Identity#1601

[Tratcher]

The stack trace resembles https://github.com/aspnet/Logging/issues/543#issuecomment-321907828. In that case the user was being accessed after disposal in app cleanup logs. https://github.com/aspnet/Common/issues/85 may also be related, but that doesn't include a stack trace.

This case appears to be happening inside the MVC authorization filter. Can you inspect the User to make sure it's an instance of WindowsPrincipal and that it has not been disposed?

[sandrey80]

Can you inspect the User to make sure it's an instance of WindowsPrincipal and that it has not been disposed?

I can't inspect. This bug is production only and can't reproduced at debug time and in testing.

[Tratcher]

Another matching stack https://github.com/dotnet/corefx/issues/15226

[muratg]

Closing as dup