DCOM timeout error (TSTheme)

Posted on Updated on

On some systems the following error appears in the System event log:

Event ID: 10010

Description: The server {AAC1009F-AB33-48F9-9A21-7F5B88426A2E} did not register with DCOM within the required timeout.
Source: DistributedCOM

Level: Error

User: N/A



Task Category: None

Keywords: Classic

OpCode: Info

Figure 1

Figure 2

Figure 3

I first discovered the error on a Remote Desktop Session Host (RDSH), although the error can occur on other systems too, but an RDSH is the most common system role to spot this error. I have already said too much with the title, so yes, it’s TSTheme related. There are a lot of possible DCOM errors of this kind, that’s why I had to include part of the solution in the title. Anyway, let’s take a closer look at this issue.

First a little bit about (D)COM…

The event source DistributedCOM refers to Distributed COM (DCOM), the “network” (“distributed”) version” of Component Object Model (COM). COM is a model based on objects, representing software components. Some software pieces (components) are built based on this model and they are often called “COM objects”. COM makes it possible to create modular software components that can be called and loaded at runtime and on-demand across process boundaries, making interprocess communication possible. It’s similar to CORBA and Java Beans. COM was introduced by Microsoft in 1993 and was the successor of the older Object Linking and Embedding (OLE) technology, which was introduced in 1991, targeted compound documents only and built on top of an even earlier technology called Dynamic Data Exchange (DDE). DDE was born in 1987 and made it possible to send and receive message in “conversations” between applications; OLE was building on that and became the first object based framework for software componentry and interprocess communication, but still only limited to compound document scenarios… This changed with the next version, launched in 1992 and included in Windows: OLE 2. This was the first “general-purpose” object based framework for software componentry and interprocess communication. As already said, the technology has been replaced with a new, more modern COM in 1993. Besides all this Microsoft also released a similar mechanism for use in Visual Basic (VB): Visual Basic Extensions (VBX). In 1994 OLE was updated with a successor for VBX, called OLE custom controls (OCX). At the same time Microsoft stated OLE 2 was just renamed to “OLE”, wasn’t officially an acronym anymore and was a collection name for all their component technologies. So the name OLE as a specific technology name “died” and became a synonym for all the Microsoft implementions of this technology type. How confusing is that?! Anyway, in 1996 Microsoft used OCX in IE, renamed all their OLE technologies related to the Internet to ActiveX (calling ActiveX objects “ActiveX controls”) and began starting to rename other OLE pieces to ActiveX too, except for the compound document part. Later in 1996 COM got a “network version”, called DCOM, meant to compete with other network technologies like CORBA. Microsoft launched an extension to COM, called Microsoft Transaction Server (MTS), with Windows NT 4. This was included with Windows 2000 and renamed COM+. It included a lot of new features, including support for distributed transactions and event publication and subscription. These events are called COM+ Events and make use of the Microsoft Message Queuing (MSMQ) technology. Components using this system are called Queued Components. The introduction of the .NET Framework made the whole OLE/COM/… technology set legacy, although it’s still possible to make use of those mechanism from .NET applications through COM Interop. A COM object is exposed through one or more interfaces, defined with the Interface Definition Language (IDL). Different threading models exist for COM objects at the “COM server side”. Every COM object and thread is assigned to a conceptual entity called an apartment. There can be only 1 COM object related to an apartment, which can have multiple threads assigned to it though. The way threads are assigned to an apartment is called the apartment model. For example, Single-Threaded Apartment (STA) is a model that states only 1 thread can be assigned to an apartment (and thus to a COM object).

A COM object is of a certain type (class). A class is identified by a class ID (CLSID) and an object by an application ID (AppID). Both IDs are Globally Unique Identifiers (GUIDs). COM objects can be called by other software (COM clients) that tries to make use of the functionality of those COM objects. Of course the COM objects should be loaded by and made available through some kind of a (local or remote) COM server (COM provider), which actually exposes the object’s interface. For example, a weather application could be implemented as a COM object and be used by Internet Explorer (IE), so IE is the COM client communicating with a COM server that hosts that COM object. A COM object is reusable and can also be consumed in complete different scenarios and exposed by different COM servers, even on the same system and simultaneously. A COM server can be implemented by an executable and thus run as a standalone process, outside other processes and exposing COM interfaces to COM clients (local or remote). A COM server can also be implemented by a DLL (typically with the .dll or .ocx extension) and thus run inside another process, while offering COM interfaces inside that process (but not outside). The first type is logically called an out-of-process COM server, while the 2nd type is called an in-process COM server. The 2nd type can be implemented in a special way though (as a DLL Surrogate), making it possible to be loaded in a surrogate executable (by default that’s the DLL Host Manager, dllhost.exe, which can appear more than once on a Windows system), which then acts as an out-of-process COM server, so it gets the same benefits as the first type of COM server. COM server files contain already the COM objects they should take care of. In the case of IE and the weather application, the weather COM object is typically implemented in a DLL, serving as an in-process COM server, which is loaded into IE, which as a whole is the COM client. Both types of COM servers can be used as a Windows service. A lot of Windows services are actually in-process COM servers containing a COM object which represents the “real” Windows service functionality and being implemented in a DLL file; such DLLs are loaded by generic Windows service host processes (svchost.exe). As you probably know, the Service Control Manager (SCM) sets up and maintains this whole set of Windows services.

If the COM object resides on the local system, it’s all about simple, classic COM. When COM clients and servers on different systems talk to each other (so over the network), we speak of DCOM. DCOM implies the DCOM network protocol. If a COM server can serve calls from over the network, it’s a DCOM server. DCOM should be considered as more than just calling a COM object over the network: it’s used A LOT for all kinds of remote scenarios, including for remote management purposes, and you would be surprised which mechanisms build on top of it. (D)COM is a powerful, but difficult technology. It has its benefits, but also its disadvantages. It’s becoming more and more something legacy though and a lot of scenarios already have a more modern solution now (for example, WMI (Microsoft’s implementation of WBEM) will use WinRM (Microsoft’s implementation of WS-MAN) as the transport protocol, although DCOM will still be supported for compatibility). (D)COM uses Remote Procedure Call (RPC) as the underlying mechanism for the transport of so-called Remote COM messages. For local COM this kind of RPC is called Local RPC (LRPC, or Leightweight RPC), also named Local Procedure Call (LPC), for the transport of so-called Local COM messages. Oh yes, have you heard of (COM) monikers? Well, these are special COM objects which identify other COM objects you might need. So they have some kind of an intermediate and referring role. COM clients calling them are called moniker clients, while COM servers hosting them are called moniker providers.

When a COM server is started, COM objects aren’t active yet. You need activation permissions to activate (create/instantiate) a COM object: there is a Local Activate (LA) and Remote Activate (RA) permission. If an activation is attempted when an object’s COM server hasn’t been launched yet, you also need launch permissions for that object: a Local Launch (LL) and a Remote Launch (RL) permission exists. Last but not least, there are also Local Access (Local Access calls, LC) and Remote Access (Remote Access calls, RC) permissions which determine who can call the COM object. Asking activation (and so possibly a launch) occurs through the “DCOM Server Process Launcher” Windows service (with the technical name “DcomLaunch”). The activation information has been registered in the registry by the COM server at installation time. Oh, if you wonder what this launch is all about, it depends a little bit on the type of COM object. For instance, for an out-of-process COM object not related to a Windows service (type “Local Server”), the related executable is started. For a COM object related to a Windows service (whether out-of-process or in-process) (type “Local Service”) the service is started.

I’m not going deeper about (D)COM in this blog post, as it would take me way too far. You know more than enough for this article.

Side note: the event source DistributedCOM is technically registered with the name “DCOM” (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\System\DCOM). No DLL is configured here, but there is a referral to a GUID ({1B562E86-B7AA-4131-BADC-B6F3A001407E} ) for more information through the REG_EXPAND_SZ named value providerGuid. A provider with this GUID is registered in the registry at the location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{1b562e86-b7aa-4131-badc-b6f3a001407e} (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers is the place where event providers are registered), which contains the provider’s name (Microsoft-Windows-DistributedCOM) and the DLL that is used for the event logging (oleres.dll).

The error…

Ok, the error… The description tells us a certain server could not be registered. We should translate it a little bit: a (COM) server of the type with the mentioned CLSID ({AAC1009F-AB33-48F9-9A21-7F5B88426A2E}) cannot be registered within a certain time and a timeout occurs.

Let’s find out which COM class we’re dealing with. A CLSID is registered in the registry at this address:

  • 32 bit Windows or 64 bit COM classes on 64 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID
  • 32 bit COM classes on 64 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID

For our CLSID we find HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{AAC1009F-AB33-48F9-9A21-7F5B88426A2E} and on 64 bit Windows also HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{AAC1009F-AB33-48F9-9A21-7F5B88426A2E}.

Figure 4

Figure 5

We see our CLSID is registered at the 32 bit level and on 64 bit Windows also on the 64 bit level, has a related AppID {8be0366c-8522-40be-8b08-cb26557f2854} and carries the name “TSRDSettings Class”. The AppID is registered in the registry at the following locations:

  • 32 bit Windows or 64 bit COM objects on 64 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID
  • 32 bit COM objects on 64 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\AppID
    • = HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\AppID
    • = HKEY_CLASSES_ROOT\Wow6432Node\AppID

Figure 6

Figure 7

Figure 8

Figure 9

We see our AppID is registered at the 32 bit and on 64 bit Windows also on the 64 bit level and has the name “TSTheme”.

Besides the AppID,the CLSID has a sub key LocalServer32: “a local COM server”, but only for the out-of-process scenario and not related to a Windows service. It refers to the same TSTheme.exe executable (%SystemRoot%\system32\TSTheme.exe, so on 64 bit Windows this should be a 64 bit executable). This means the COM class exists in 1 form: a standalone exe. The executable is defined for use as a “normal” standalone process, but through the AppID also for use in a predefined way (read on to know which kind of use). The only real instance (COM object) defined is for the latter. For the other scenarios there is no predefined instance registered (the executable can be launched many times…).

Figure 10

Figure 11

So, TSTheme is a COM object of the type (class) “TSRDSettings Class”. A COM object can be of a certain type. Let’s start Component Services, look for the COM object and get its properties, so you can get to know the application type of this COM object. Open Component Services from Administrative Tools (or run “dcomcnfg”) and expand Component Services – Computers – My Computer – DCOM Config.

Figure 12

Then go to the COM object’s name, TSTheme, right-click it and select “Properties”. A dialog box appears:

Figure 13

On the General tab we see the field “Application Type”, with the value “Local Server”. This means it’s a COM object that actually implements a standalone executable, but not as a Windows service, and is predefined through an AppID. The field “Local Path” is empty, because no path to the executable is defined for the AppID (but it is defined under the LocalServer32 key at the CLSID level; see figures 10 & 11).

So, what is this TSTheme and TSRDSettings Class? Let’s take a look at TSTheme.exe’s file details in Windows Explorer:

Figure 14

The file is described as “TS Theme Server Module”. So it’s a server module (component) used in the context of themes with Terminal Server (TS) or Terminal Services (TS). “TSRDSettings Class” is a COM class for TS Remote Desktop (RD) settings, more precisely theme settings. I don’t see TSTheme.exe run when I take a look at my RDSHs, but perhaps it gets started at logon time and disappears some time later? So I started Process Explorer on one of my RDSHs, started monitoring and logged on with another user. And indeed, TSTheme.exe appeared, stayed for a few seconds and was gone.

Figure 15

We see TSTheme.exe’s parent process is an svchost.exe process, i.e. the one containing the Windows service “DCOM Server Process Launcher”. This isn’t weird: TSTheme is a COM object that should be started as a normal (non-service) standalone executable and the DCOM Server Process Launcher is a standard way for launching this types of COM objects, of course on request and when needed. It seems Windows wants the TSTheme to be launched when a user logs on and the DCOM Server Process Launcher takes care of that. TSTheme does what it has to do and then it terminates.

Now, what does “TS” stand for? “Terminal Server” (or the new name “Remote Desktop Session Host” (RDSH))? Or “Terminal Services” (or the new name “Remote Desktop Services” (RDS))? I’ve done the same user logon test on a WS08R2 SP1 system without the RDSH role installed and TSTheme.exe is showing up the same way, so “TS” definitely stands for “Terminal Services” and to avoid any confusion, yes, it also implies the new RDS. Note that Terminal Services (or RDS) is the Microsoft way of remotely connecting to a desktop, while Terminal Server (or RDSH) is the special “mode” to support this mechanism for “many users at the same time”. Anyway, on the Net some people think TSTheme is part of the Desktop Experience feature, but that’s not true, as in my last test this feature wasn’t installed either.

I’ve also analyzed other system and application events just before and after the DCOM error event. It seems our DCOM error appears only when a user logs on (but not every time a user logs on!) and a few seconds later (or earlier) a warning event from the User Profile Service is logged in the Application event log too (but the DCOM error isn’t always there when this application event is logged!). It seems something from the user’s cached profile is still in use, so the handle must be released, so the cached profile can be deleted and the user can get a new, clean cached profile. The old cached profile is the rest of a previous session.

Figure 16

So, with all this new information, let’s translate the error into a more understandable form: a COM server/object of the type defined by the COM class “TSRDSettings Class” cannot be registered/created/instantiated by the Windows service DCOM Server Process Launcher at user logon within a certain time interval and a timeout is triggered. This means the COM object TSTheme, or thus the TSTheme.exe process, hasn’t been started. As the user logs on, this doesn’t seem to be blocking, but of course it’s no good. It’s unknown to me what the symptoms are… Doesn’t the user get its theme? Is the UI f*cked up? I’m not aware of those symptoms, but I must admit I’m not 100% sure of this and I definitely ask myself what the hell the user is missing then… :-s I think the error only occurs when a piece of the user’s cached profile was still in use, resulting in delays that sometimes trigger a timeout for TSTheme… I guess solving the “in use” issues will also solve the DCOM timeout error. So you don’t have to do anything about this error! If the cause of this error is there is something in use, try to fix that instead.

FYI, the DCOM error could be logged for other CLSIDs too. Sometimes those other DCOM errors also occur when a user logs on and a part of his/her cached profile is still in use. It doesn’t mean though that every 10010 DCOM error occurs under those circumstances; I’m just saying it can be.

Side note: for completeness it could be interesting to know what OLE DB is. It stands for “Object Linking and Embedding, Database” and is also called OLEDB or OLE-DB. It has nothing to do with the technology that was formerly called OLE, but it’s a set of interfaces exposed through COM to access data from different kinds of sources in a uniform way. OLE-DB is a successor of ODBC and extends the functionality with non-relational databases too (so it’s broader than just SQL). ODBC, by the way, stands for Open Database Connectivity, is similar to JDBC and offers applications access to DBMS systems in a uniform way, with ODBC drivers as intermediates for the translation, while the ODBC Driver Manager (DM) takes care of the loading of those drivers. ODBC drivers exist for many, many DBMS systems, like MySQL, Oracle, SQL Server,… An OLE DB-ODBC bridge exists to make it possible for applications to use OLE DB, while under the hood the requests are forwarded to ODBC. ODBC was first released as version 1.0 in 1992 and the latest version is 3.8 (included in Windows 7). OLE DB also has some kind of translation engine between applications and data sources and it’s called an OLE DB provider, while the applications using OLE DB are called OLE DB consumers. The future of OLE DB is unclear and it seems it will become something legacy soon. Even the older ODBC is called better for performance… Another data source interface is Jet Data Access Objects (DAO), which was launched with version 1.0 in 1992 under the name of VT Objects, but is deprecated now, leaving version 3.6 as the latest one. Also old and forgotten is Remote Data Objects (RDO), which could connect with ODBC. Anyway, the latest is ActiveX Data Objects (ADO), a set of interfaces exposed through COM and using OLE DB “behind the scene”. The .NET variant of ADO, ActiveX Data Objects for .NET (ADO.NET), is quite different though, but builds on OLE DB too. Don’t be confused with ADO.NET Entity Framework (EF), which is the object-relational mapping (ORM) framework of ADO.NET.




13 thoughts on “DCOM timeout error (TSTheme)

    Brian said:
    04/06/2012 at 18:59

    Excellent write-up. Was searching all over to figure out why this DCOM error was popping up on our Citrix farm.

      Brian said:
      04/06/2012 at 19:07

      This is possibly a fix for the Tstheme.exe issue http://support.microsoft.com/kb/2661001

        Padre Pedro said:
        04/06/2012 at 20:54

        Hi Brian! Thanks a lot for your reply! I’ve seen the KB article too, but I have no proof the article is related to what I’ve seen in the event log. The article deals with symptoms I haven’t seen (although they could be present in my environment of course, perhaps I’m just not aware of them) and at the same time nothing from my article is described in the article (except for the string “TSTheme.exe”). But… there is indeed a chance those things are related (and then it could be the cause is not something that was already in use from a previous session, but something that got in use during a “bad” logon), so I’ve checked my rpcss.dll and win32k.sys file versions. I have a newer Win32k.sys file version than the one from the article, but the article’s rpcss.dll is newer than mine. I’m going to test it out tomorrow. It’s definitely worth a shot. Thanks again!

        Padre Pedro said:
        05/07/2012 at 14:25

        It seems the event is still being logged, so the update didn’t “fix” the issue. Again, the cause of stuff being left in use should be fixed and as a result the TSTheme DCOM error probably won’t appear anymore. So I don’t think there is a problem with TSTheme itself and the actual cause lies somewhere else, i.e. in something being left in use (from the user’s cached profile).

    Martin said:
    28/11/2012 at 16:21

    Hi my name is martin (calderonmontiveros@hotmail.com) did you check if these works? It solved my issue with desktop not being showed, the error started after a permission change.


    Net localgroup Users Interactive /add
    Net localgroup Users “Authenticated Users” /add

      dach said:
      25/11/2013 at 23:58

      Martin, could you please develop on your solution.

      I have a XenApp 6.5 (Windows Server 2008 R2) server that stops showing the App in the end-user desktop (in seamless mode), and the only thing the user see is his desktop is the blue background from Windows Server. Like the App running on the TS server freezed.

        Gartes said:
        05/09/2014 at 08:12

        We’ve exactly the same issue. From time to time when a published application is started, the logon takes very long and in the end the published application isn’t shown.
        When you doublecheck it on the server itself, the user is logged on (session state = active) and the process of the application (e.g. winword.exe) is running.
        Just the app isn’t displayed on the users screen.

        have you any solution found?

    Daniel Wolf said:
    17/12/2013 at 22:42

    You are amazing. Man, sometimes I feel good about what I figure out fixing Windows, but you are a whole other level. Thank you so much.

    James D. Smith said:
    07/11/2014 at 14:17

    I have to concur with those above who are singing your praises Pedro; this is an amazingly thorough and lucid explanation of a single issue. I wish you would write several books…

    Udi said:
    07/01/2015 at 13:56

    Besides the perfect description of the problem – Has anyone found a solution yet?

    Craig A. Silvis said:
    13/07/2015 at 16:36

    That was an awesome post, thanks!

    Lennart said:
    16/07/2015 at 10:17

    I also am very interested in a solution. We have the same problem. The hotfix didn’t solve it 😦

    wcs1236 said:
    02/02/2017 at 17:47

    Amazing write up, very well explained. Thank you for such a thorough explanation of the issue.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s