We are excited to announce that the IIS.NET Forums are moving to the new Microsoft Q&A experience. Learn more >

Deadlock using ServerManager (Administration 7.0.0.0)RSS

1 reply

Last post Nov 18, 2014 06:29 AM by JMS-1

  • Deadlock using ServerManager (Administration 7.0.0.0)

    Nov 18, 2014 03:51 AM|JMS-1|LINK

    From time to time we observe a deadlock using the ServerManager in read-only mode from inside a virtual directory. This is what happens: a ServerManager instance is created on demand and some configuration data is read. Then the instance is disposed (in this special code path by a using wrapper) where in Dispose(true) Release() on the ConfigurationManager is called which is forwarded to a Release() on the Configuration instances used. There the underlying COM objects are detached by FinalReleaseComObject(). There it comes to nativerd!CONFIG_CHANGE_NOTIFIER::SetChangeHandler which blocks on nativerd!CHANGE_LISTENER::WaitForNotificationThreads.

    On a second thread for some reason there seems to be a configuration change notification OnConfigCacheInvalidated active on the very same ConfigurationManager. I suspect this is the NotificationThread the Dispose() is waiting on. But OnConfigCacheInvalidated tries to aquire the same .NET lock which is hold in the Dispose() itself so the application deadlocks.

    Is there any direct way to overcome this very annoying scenario?

    Jochen

  • Re: Deadlock using ServerManager (Administration 7.0.0.0)

    Nov 18, 2014 06:29 AM|JMS-1|LINK

    So even if the ServerManager is cached somewhen this problem may arise - in worst case on the Finalizer Thread. So our first try will be replacing calls to ServerManager.GetApplicationHostConfiguration() with this code:

    public static Configuration GetDetachedConfiguration( this ServerManager serverManager )
    {
    	// Attach to the configuration file
    	var iisConfiguration = serverManager.GetApplicationHostConfiguration();
    
    	// Detach from notifications
    	iisConfiguration.SetMetadata( "changeHandler", null );
    
    	// Report result
    	return iisConfiguration;
    }
    

    Although I would be happy to hear of any better solution. In my personal opinion the COM wrapping as implemented is no relyable considering the described issue.

    Jochen