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:

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}

CauseThe 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:

ResolutionAs 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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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?

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?