none
Central Admin error - Could not load file or assembly SMDiagnostics

    Question

  • We have just setup a farm with 2 WFE, 2 app servers and an SQL cluster. Central admin site is located on one of the app servers. Initially everything worked fine, but after a restart of the servers we suddenly experienced the following error when accessing Central admin: 

    The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE))

    Details:
    [COMException (0x80070006): The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE))]

    [FileLoadException: Could not load file or assembly 'SMDiagnostics, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE))]
       System.ServiceModel.Activation.HttpModule.ProcessRequest(Object sender, EventArgs e) +0
       System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80
       System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +171

    Adding the FarmAccount (running the application pool for Central Admin) to the local administrators will remove the error, so it is clearly a security/account issue. But as it is really not recommended to have the FarmAccount in the local admins group, we would really need some input to, what could have caused this behaviour, and how to solve it.

    All servers run Win2008 R2 and SharePoint is installed with SP1 (using AutoSPInstaller).

    Any inputs are greatly appreciated.

    Wednesday, July 20, 2011 2:21 PM

Answers

  • We have now solved this issue.

    It had nothing to do with the .NET framework and not directly related to SMDiagnostics.dll.

    It turned out the issue was caused by the application pool accounts not being added to the list of users with the "Impersonate a client after authentication" permission (Local Security Policy > Local Policies > User Right Assignments > Impersonate a client after authentication).

    Editing this setting was being blocked by a Group Policy, so that permissions were not granted correctly during installation. After adding application pool accounts to the list everything works perfectly.

    • Marked as answer by tnsprivat Saturday, July 23, 2011 11:31 AM
    Saturday, July 23, 2011 11:31 AM

All replies

  • Hi,

     

    this assembly is part of the .NET framework. Did you perform any updates or changes to the .NET framework? The necessary assembly should reside in:

     

    C:\windows\Microsoft.NET\Framework\v<Version>\Windows Communication Foundation

     

    If it is not there, I would consider reinstalling the .NET Framework in order to fix it.

     

    Best regards,

    Martin


    Martin W. Angler, MCTS, MCC, MVP

    Blog angler.wordpress.com
    Twitter: Follow me on twitter
    Wednesday, July 20, 2011 2:26 PM
  • Did not touch the .NET framework. The file is under C:\windows\Microsoft.NET\Framework\v<Version>\Windows Communication Foundation and in the GAC as well.

    Also everything works fine when I add the FarmAccount to local admins. So no files are apperently missing - it is 'just' a matter of security. But FarmAccount should not need to be part of local admins.

    Wednesday, July 20, 2011 2:36 PM
  • For information: We also get an error on all other webapplications, if the application pool account of the specific webapplication is not member of local admins.
    Thursday, July 21, 2011 7:51 AM
  • We have now solved this issue.

    It had nothing to do with the .NET framework and not directly related to SMDiagnostics.dll.

    It turned out the issue was caused by the application pool accounts not being added to the list of users with the "Impersonate a client after authentication" permission (Local Security Policy > Local Policies > User Right Assignments > Impersonate a client after authentication).

    Editing this setting was being blocked by a Group Policy, so that permissions were not granted correctly during installation. After adding application pool accounts to the list everything works perfectly.

    • Marked as answer by tnsprivat Saturday, July 23, 2011 11:31 AM
    Saturday, July 23, 2011 11:31 AM
  • I had the same problem and tnsprivat's answer worked for me.

    I had to add the SharePoint farm account (also added the app pool accounts) to the domain group policy.

    Friday, May 25, 2012 4:41 PM