COMException Unknown error (0x80005000) - DirectoryServices

Question

I've been running into an error on one of my applications that happens a few times a month but has occurred twice this week. When this happens, it's always first thing in the morning when the first user loads the app and begins working (web application, 3-4 internal users) The error originates from this very simple method and once if fails, it will not work until I restart the application pool. Now, I'm querying AD in other ways as well but this is the first AD related method that's called when the users begin work in the morning.

public DomainUser GetDomainUser(string userLoginName)
    {
        using (PrincipalContext context = new PrincipalContext(ContextType.Domain, this.DomainName))
        {
            using (UserPrincipal user = UserPrincipal.FindByIdentity(context, userLoginName))
            {
                // If user is null, the result is not a UserPrinciple
                if (user != null)
                {
                    string firstName = user.GivenName;
                    string middleName = user.MiddleName;
                    string lastName = user.Surname;
                    int empId = Convert.ToInt32(user.EmployeeId);
                    string emailAddr = user.EmailAddress;
                    string userName = user.SamAccountName;
                    DateTime? accountExp = user.AccountExpirationDate;

                    return new DomainUser
                    {
                        FirstName = firstName,
                        MiddleName = middleName,
                        LastName = lastName,
                        EmployeeId = empId,
                        Email = emailAddr,
                        UserName = userName,
                        AccountExpiration = accountExp
                    };
                }

                return null;
            }
        }
    }

So this question is closely related but my permissions are setup correctly and the code works 99% of the time and will continue to run after an application pool restart.

Stack trace looks something like this:

System.Runtime.InteropServices.COMException (0x80005000): Unknown error (0x80005000)
   at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_AdsObject()
   at System.DirectoryServices.PropertyValueCollection.PopulateList()
   at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
   at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
   at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInitNoContainer()
   at System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit()
   at System.DirectoryServices.AccountManagement.PrincipalContext.Initialize()
   at System.DirectoryServices.AccountManagement.PrincipalContext.get_QueryCtx()
   at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithTypeHelper(PrincipalContext context, Type principalType, Nullable`1 identityType, String identityValue, DateTime refDate)
   at System.DirectoryServices.AccountManagement.Principal.FindByIdentityWithType(PrincipalContext context, Type principalType, String identityValue)
   at System.DirectoryServices.AccountManagement.UserPrincipal.FindByIdentity(PrincipalContext context, String identityValue)
   at ADWrapper.AdSearch.GetDomainUser(String userLoginName)

What could the problem be? Memory leaks? The common pattern is that this happens first thing in the morning when the first user begins using the app.

Tilth

If I were you, I would dispose the objects in a finally clause, just to be sure ^^ because errors can occur, and generate undisposed objects. Have you also try to use Thread.Sleep when catching this error ? AD may use milliseconds before responding and generate issues. – Robichaux

Shouldn't the using statement handle this even if exceptions occur within them? – Tilth

Depends on the objects: https://mcmap.net/q/182797/-c-quot-using-quot-syntax. Moreover, in your case, you should manage COMException separately than the others. My opinion ;) – Robichaux

Thanks for your comment. What do you mean by manage COMException separately? In this case, I believe disposal is guaranteed unless something like a power failure happens (at which point, I won't care). – Tilth

I agree with you, I simply avoid using and prefer try/catch/finally clauses. I mean you could use catch(COMException ex) and then a catch(Exception ex). THis way, you can manage separatly different types of exception. – Robichaux

It may be a memory leak in FindByIdentity. Have a look at this question: #1883665 – District

@JasonEades Did you ever find a solution? I have a similar issue. Can you post an answer? – Hodgkinson

@Hodgkinson No, I never found a real solution but I believe this is due to memory leaks. I can't think of anyting else that explains the timing and randomness of the errors. This issue is a pain and pops up whenever these methods are used heavily. For me, this is about twice a month. Because this is a small internal application, I just restart the application pool. I would probably avoid System.DirectoryServices.AccountManagment for heavy uses and go with the old way of manually creating the ldap search query like is suggested here: https://mcmap.net/q/586748/-strange-issue-with-system-directoryservices-accountmanagement-userprincipal-findbyidentity – Tilth

Answer 1

We had a similar issue. Here was the solution provided by Microsoft. I hope this helps someone.

The DirectoryEntry.Bind function eventually calls into ADsOpenObject (https://learn.microsoft.com/en-us/windows/win32/api/adshlp/nf-adshlp-adsopenobject) This function has a “router”. The initialization of the router enumerates providers from the registry, such as the “LdapNamespace”. This is located at HKEY_CLASSES_ROOT\CLSID{228D9A82-C302-11cf-9AA4-00AA004A5691}\ProgID. The other providers, such as WinNT namespace are also enumerated.

In the trace, an error is returned when looking up these registry keys. The error is,

ERROR_KEY_DELETED

1018 (0x3FA)

Illegal operation attempted on a registry key that has been marked for deletion.

This error can be caused by an unload of the user profile that the process is using for its identity.

The Windows User Profile Service forcefully unloads user profiles. This causes problems with the process.

I have seen this with w3wp.exe and dllhost.exe, where the registry profile is unloaded before the process is done.

Here’s a blog we did on the issue for dllhost.exe: https://blogs.msdn.microsoft.com/distributedservices/2009/11/06/a-com-application-may-stop-working-on-windows-server-2008-when-the-identity-user-logs-off/

You may see warnings in the application log with descriptions like this: Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards.

I think we should try the resolution/workaround in the blog:

Resolution

As a workaround it may be necessary to disable this feature which is the default behavior. The policy setting 'Do not forcefully unload the user registry at user logoff' counters the default behavior of Windows 2008. When enabled, Windows 2008 does not forcefully unload the registry and waits until no other processes are using the user registry before it unloads it.

The policy can be found in the group policy editor (gpedit.msc)

Computer Configuration->Administrative Templates->System-> UserProfiles

Do not forcefully unload the user registry at user logoff

Change the setting from “Not Configured” to “Enabled”, which disables the new User Profile Service feature.

There should not be any side effects from this change.

Louisalouisburg

Answer 2

I was struggling with absolutely same issue for a long time. My solution was actually install feature IIS 6 Metabase Compatiblity. After that no problems. Some articles which helped me are below

http://blogs.msdn.com/b/jpsanders/archive/2009/05/13/iis-7-adsi-error-system-runtime-interopservices-comexception-0x80005000-unknown-error-0x80005000.aspx

http://michaelwasham.com/2011/04/25/annoying-error-using-system-directoryservices-and-iis-app-pools/

Pneuma

Answer 3

I had this for one specific user. It turned out that that user was the only user in the only AD OU that had a slash in the name. Now that I figured this out I can now switch back and forth between having the slash and getting the error and not having the slash and not getting the error, so it's 100% the cause of the error at least in my situation.

Walliw