Partager via

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

  • Article

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

  • Anonymous
    December 07, 2009
    The comment has been removed

  • Anonymous
    December 08, 2009
    It have just worked! No more strange obscure errors from com+ application!

  • Anonymous
    September 20, 2011
    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

  • Anonymous
    April 12, 2012
    Tried this and found it not to be a solution for this error in the case of SharePoint 2010 timer jobs.

  • Anonymous
    August 05, 2013
    Not able to find "Do not forcefully unload the user registry at user logoff " in User profiles

  • Anonymous
    August 06, 2013
    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

  • Anonymous
    November 28, 2013
    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?

  • Anonymous
    December 01, 2013
    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.

  • Anonymous
    January 27, 2014
    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.

  • Anonymous
    March 03, 2014
    It worked for me the solution... I got same issue starting Citrix Receiver...

  • Anonymous
    March 25, 2014
    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.

  • Anonymous
    March 25, 2014
    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.

  • Anonymous
    May 19, 2014
    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.

  • Anonymous
    May 19, 2014
    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.

  • Anonymous
    May 27, 2014
    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

  • Anonymous
    May 28, 2014
    The comment has been removed

  • Anonymous
    May 28, 2014
    The comment has been removed

  • Anonymous
    May 28, 2014
    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.

  • Anonymous
    November 16, 2014
    The comment has been removed

  • Anonymous
    October 12, 2015
    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..

  • Anonymous
    October 12, 2015
    Sandman, Note that it is an intermittent issue. You can run into the issue later.

  • Anonymous
    November 18, 2015
    The comment has been removed

  • Anonymous
    November 18, 2015
    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.

  • Anonymous
    February 17, 2016
    The comment has been removed