A COM+ application may stop working on Windows Server 2008 when the identity user logs off


Problem Description
You have a COM+ server application. The application is set to run as a particular user. After working for sometime on Windows Server 2008 the application may stop working and keep failing. Unless you restart the COM+ application, it won’t come back. In the meantime you may see an error like this in the application event log on the CLIENT machine:

Event Type:        Error
Event Source:    DCOM
Event Category:                None
Event ID:              10006
Date:                     10/17/2009
Time:                    1:36:39 PM
User:                     Domain\user
Computer:          *****
Description:
DCOM got error "Unspecified error " from the computer ‘servername’ when attempting to activate the server: {EF047BF9-F91A-4D5B-A18F-BED49553703B}

In this case the event message tells you that the error (E_FAIL or 80004005 or Unspecified error ) is returned from the server during activation vs. a method call. The component CLSID is {EF047BF9-F91A-4D5B-A18F-BED49553703B}

Cause 
The identity user initially logged on to the server when the application launched. The issue happens when the identity user logs off and the COM+ application can no longer read registry keys in the profile of the identity user because of a new User Profile Service functionality of forcing the unload of the user profile on Windows 2008 when the user logs off. Note this new User Profile Service functionality is built into the OS by default.This is a situation where the functionality of forcing the unload of the user profile may break an application if registry handles are not closed in the process.

If you enable COM tracing, you’ll see the error ERROR_KEY_DELETED in the ole32 trace log:

[2] 0BA8.15D0::10/17/2009-13:07:54.390 [OLECOM](:CComRegCatalog::GetClassInfoW) CLSID:ecabafae-7f19-11d2-978e-0000f8757e2a 1018(ERROR_KEY_DELETED)
[2] 0BA8.15D0::10/17/2009-13:07:54.390 [OLECOM](:CComCatalog::GetClassInfoInternal) CLSID:ecabafae-7f19-11d2-978e-0000f8757e2a Flags:0 IID:00000000-0000-0000-c000-000000000046 0x800703fa(ERROR_KEY_DELETED)

You’ll see events like this in the application event log:

Log Name:      Application
Source:        Microsoft-Windows-User Profiles Service
Date:          10/26/2009 8:22:13 AM
Event ID:      1530
Task Category: None
Level:         Warning
Keywords:      Classic
User:          SYSTEM
Computer:      
Description:
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. 

DETAIL –
1 user registry handles leaked from \Registry\User\S-1-5-21-1049297961-3057247634-349289542-1004_Classes:
Process 2428 (\Device\HarddiskVolume1\Windows\System32\dllhost.exe) has opened key \REGISTRY\USER\S-1-5-21-1049297961-3057247634-349289542-1004_CLASSES

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.

‘DisableForceUnload’ is the value added to the registry

Note the same issue can happens on Vista, Windows 7 and Windows 2008 R2.

Comments (24)

  1. xor2 says:

    Hi,

     I think I have come across the same problem.

    as I could find an entry in the system event viewer like this:

    Server Application ID: {B6431F5D-496A-4201-9B05-7BAD83963763}

    Server Application Instance ID:

    {BC5A3756-F914-4009-AC15-CE8CFD3F0A82}

    Server Application Name: XRC

    Error Code = 0x800703fa : Illegal operation attempted on a registry key that has been marked for deletion.

    COM+ Services Internals Information:

    File: d:rtmcomcomplussrccomsvcseventsevregistrar.cpp, Line: 403

    Comsvcs.dll file version: ENU 2001.12.6931.18000 shp

    I have just wanted to ask if this option mentioned as a workaround

    should be _enabled_ or _disabled_?

    I have had this option set: "Not configured"

    Thanks for help in advance!

  2. xor2 says:

    It have just worked! No more strange obscure errors from com+ application!

  3. Swapnil says:

    We are using Win 2008 R2 64 Bit server for an automation project using MS Excel and MS Powerpoint Interop DLL.

    I tried the solution given above, have given full authority to DCOM as wel as folder, also tried OGAVA's solution to add Desktop Folder (social.msdn.microsoft.com/…/b81a3c4e-62db-488b-af06-44421818ef91)

    However our Web ASP.net application runs fine ONLY WHEN a user is logged on to the server,

    As soon as the user logs off (via Remote desktop or physically), the application starts failing on Interop Operations.

    Please Suggest

  4. Steve says:

    Tried this and found it not to be a solution for this error in the case of SharePoint 2010 timer jobs.

  5. Robin says:

    Not able to find "Do not forcefully unload the user registry at user logoff " in User profiles

  6. davidqiu says:

    xor2,

    you should enable the policy "Do not forcefully unload the user registry at user logoff".

    Swapnil,

    Your issue is different. We do not recommend or support Automation to a Microsoft Office application from an unattended user account. However COM+ can work with a non-interactive identity that has the "logon as batch job" right.

    Robin,

    Please take a look at this article. You can try setting the value of 'DisableForceUnload' to 1 in the registry.

    pacsharepoint.com/…/sharepoint-search-illegal-operation.html

  7. Cristian says:

    This solution solved my problem, but just for a short period of time. If the application is not used for some time it will close, and then the registry is unavailable again and the application fails.

    Is there a way to allow it to keep runing?

  8. davidqiu says:

    Cristian, if the policy reverts back, your global policies override local policies. You need to check with your system admin. Alternatively, you can use other workarounds such as never share the identity of this COM+ app or this app pool with any others and do not use it to logon.

  9. Kevin Scott says:

    This issue appeared in our SharePoint Farm's Search Service. While I did not see the 10006 Event in the Event Log, there were entries in the ULS log indicating the registry key was marked for deletion (Illegal operation attempted on a registry key that has been marked for deletion).

    After enabling the policy, I restarted the application pool for the Search Service and so far no more errors.

  10. Manuel Besoain says:

    It worked for me the solution… I got same issue starting Citrix Receiver…

  11. Mike Ruhlin says:

    What counts as a "user logoff" event for these purposes?  My web site runs in IIS, with a dedicated user account.  There are a variety of things I could see being considered login/logoff events, but this bug has apparently been intermittent.

    – Our deployment server uses the Task Scheduler Managed Wrapper (taskscheduler.codeplex.com/documentation) to remotely connect to our server and set up some schedueld tasks that perform various routine maintenance operations.

    – Those scheduled tasks run as the same user as the IIS app pool

    – our support team sometimes logs in to the machines to run maintenance scripts by hand.  Their process for this is to connect to the server via Remote Desktop, logging in with their own personal account.  They then use the RUNAS command to open cmd.exe running as the IIS user.  They run their scripts, then close the command window.

    Do either of those things count as the kind of logoff event that would cause this to happen?  I would expect to see this problem more often if that was the case.  Trying to figure out if something I don't know about is happening infrequently to cause this.

  12. davidqiu says:

    Mike,

    Indeed there are many logon/logoff scenarios. Besides interactive logon and remote desktop, starting/stopping a Windows service and an IIS app pool also causes the identity user logon/logoff along with the user profile load/unload. The key is to not to share the user identity of a COM+ application with any Windows services or IIS app pools and not to use the same identity to logon to the machine interactively or remotely. The issue is not limited to COM+ applications. It can happen for non-COM+ inproc COM dlls in IIS if loading user profile is not enabled for the app pool.

  13. haritha says:

    Hi,

    We are facing the same error in our Production environment. Will chnaging the group policy cause any harm?

    Will it cause any performance issues? Please let me know if there is any alternate solution other than Group Policy edit.

  14. davidqiu says:

    I haven't seen any issues from customers with changing the group policy. There are other workarounds. If your issue is with a COM+ server app (dllhost.exe), make sure you use an unique identity for it (don't not share the identity with any other app or use it to logon). If the issue is with an IIS app, ensure "load user profile" is enabled for the app pool or use an unique identity.

  15. Eli says:

    Hi,

    We are facing similar intermittent problem with our application when configuring the IIS application pools and the suggested workaround (policy update) did not help.

    Our application uses custom application pools. During our application’s lifecycle the user/pwd for those application pools is configured using the DirectoryEntry API (this happen every time the user is changed, usually for security reasons).

    Every now and again (and it is unclear how to reproduce this) this configuration will fail when doing commit.

    Now, we do use the same user for several application pools as well as dcom objects. However, the suggestion to use unique ID for each of them is not an option for us.

    Can you think of a possibly workaround/solution?

    I read here (stackoverflow.com/…/using-application-pool-identity-results-in-exceptions-and-event-logs) that enabling the LoadUserProfile attribute of the app. Pool to true should help. Do you know about that?

    Note that our application have been using the same IIS configuration for years but only recently (i.e. last year) we started to see this problem happen.

    Thanks

  16. davidqiu says:

    The workaround should work if you run into the same issue. Failing to set the application pool identity is not a symptom of the issue. When the issue happens, you cannot activate COM components. In the application event log the process that has open key is dllhost.exe or w3wp.exe. Note that the workaround is to change the setting from “Not Configured” to “Enabled”. Other than changing the policy, for IIS applications, you can enable "load user profile" on app pools, which is the default setting. For COM+ apps, the only other option is to run a server app as a Windows service.

  17. Eli says:

    Thanks David.

    So, you are saying that my problem is not the same as the one you described?

    Since I am unable to reproduce the problem on will, I cannot search the event viewer for messages.

    I do not know if the error originated from a COM component. If it is related, it is definitely not my COM component as the error is generated by the MS API call to change the user of the VirDir.

    So far, nothing I have tried solved the problem (I did not try yet to change the "load user profile" of the app pool). The only workaround that worked is restarting IIS and even with this workaround, we usually need to restart IIS twice in order to fix this problem.

    Do you know why this happens (intermittently)? why would the  "load user profile" should fix the problem?

    Thanks.

  18. davidqiu says:

    COM doesn't load the process identity user profile. It will access the user registry if the user profile is loaded by another process. The new User Profile Service functionality unloads the registry file when the user logs off, which breaks COM. Enabling "load user profile" in IIS app pool help load user profile for COM running in the app pool, which should eliminate the issue.

  19. Martin_0 says:

    In case you were sent here and have trouble with SharePoint 2010 and a Search Query with the following error:

    The following error occured: Exception calling "Execute" with "0" argument(s): "Illegal operation attempted on a registry key that has been marked for deletion. (Exception from HRESULT: 0x800703FA)"

    Look at this post and reset SecurityTokenService App Pool on all servers + Restart Search Query Service via Central Admin.

    social.technet.microsoft.com/…/home

  20. Sandman says:

    Sometimes the group policy is not neccessarily the case…I just unplugged the COM application and reinstalled it again and it worked fine. I suppose the reason maybe the COM app is corrupted..

  21. davidqiu says:

    Sandman,

    Note that it is an intermittent issue. You can run into the issue later.

  22. Jim says:

    davidqiu, sorry to direct this at you but it looks to me like you know what you are talking about in terms of the gubbins of this situation!…

    I have also just started getting this problem on 1 of our 4 application servers (in geographically different locations), the other 3 are still operating properly with the same version of the COM+ application. – which is a COM dll and does not run through IIS.  

    dllhost is using around 100Mb of memory and the server has 16Gb with 6Gb free.

    As far as I am aware the Group/User Policy has not been changed.

    The COM+ application has always used a dedicated account and is never used to log on.

    I have rebooted twice.  The application performs fine for a good while and then users start seeing the above error and eventually the application collapses in a heap and requires a restart.

    I did the install on Monday evening at about 8pm, the first time the error was seen was around 9am and then at around 11am every use connected to it was "kicked out" and if they tried to connect their client again they got a Type Mismatch error.  After a server reboot it all started working fine and we though it had been solved.  About the same time today the error started and again at 11am everyone was kicked out.

    Is there any way this issue could have come about due to a problem with the deregistration of the dll when I did the rollout?, I can't remember if I removed the components from COM+ first or not.

    Would you still recommend changing the policy, or do you think a reinstall of the application be a better choice?

  23. davidqiu says:

    Hi Jim,

    If you see the event described in the article for …WindowsSystem32dllhost.exe, I recommend you change the policy.

    Source:        Microsoft-Windows-User Profiles Service

    Event ID:      1530

    Note that it is not your policy change that causes the problem.

    Besides an interactive logon, other uses of the account can also cause the problem including using it as an identity for a Windows service or an IIS app pool identity.

  24. Daniel Latikaynen says:

    IMO this is a serious bug. It renders the whole idea of COM+ as server-side, unattended services and libraries useless. It is still current on recent Windows Server versions. Will this ever be addressed so it works again by default and not only after policy and registry hacks?