DCOM error related to WSRM

Posted on Updated on

(or what you need to know about DCOM and WSRM)

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

Event ID: 10016

Description: The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID

{E8BCFFAC-B864-4574-B2E8-F1FB21DFDC18}

and APPID

{0643C58D-5861-4F0C-AE82-FC867CCEDD7A}

to the user DOMAIN\USER SID (SID) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

Source: DistributedCOM

Level: Error

User: DOMAIN\USER

Computer: YOUR_SYSTEM

Logged: DATE_AND_TIME

Task Category: None

Keywords: Classic

OpCode: Info

The following screenshots are taken from a session which had a Dutch language configured, so it differs a bit from the description above.

Figure 1

Figure 2

Figure 3

Figure 4

I first discovered the error on a Remote Desktop Session Host (RDSH), but it’s not specific for RDSH. I have already said too much with the title, so yes, it’s WSRM 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 user (which has a certain SID), wants to activate a local COM object from the system the event is logged on (so localhost, hereby mentioned as LocalHost), so the attempted launch is a so-called Local Activation. This launch is attempted through LRPC, the underlying “transport”/”communication” mechanism for (local) COM. The COM object (and thus COM server (application), here called “COM Server application”) is identified by its class ID (CLSID) and application ID (AppID, here mentioned as APPID). The CLSID is {E8BCFFAC-B864-4574-B2E8-F1FB21DFDC18} and the APPID is {0643C58D-5861-4F0C-AE82-FC867CCEDD7A}. It seems the permission settings for this COM object don’t grant SYSTEM the Local Activation right for this application. (D)COM stuff can be configured through the MMC snap-in Component Services.

Let’s find out which COM object 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
    • = HKEY_CLASSES_ROOT\CLSID
  • 32 bit COM classes on 64 bit Windows: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID
    • = HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID
    • HKEY_CLASSES_ROOT\Wow6432Node\CLSID

For our CLSID we find HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{E8BCFFAC-B864-4574-B2E8-F1FB21DFDC18}.

Figure 5

We see our CLSID is registered at the 32 bit level, has a related AppID {9209B1A6-964A-11D0-9372-00A0C9034910} and carries the name “MDM Utilities”. An AppID is also 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
    • = HKEY_CLASSES_ROOT\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 level and on 64 bit Windows also on the 64 bit level and has the name “Windows System Resource Manager”.

Windows System Resource Manager (WSRM) is a Windows Server component that can be installed; on WS08 it’s a feature, so you can install it by adding the feature (the feature requires the Windows Internal Database feature). WSRM is typically used on Terminal Server (TS) and Remote Desktop Session Host (RDSH) to make sure a user doesn’t take all the resources, decreasing performance too much for the other actors on the system. WSRM allocates resources in an honest way, based on a few configuration settings set by the administrator. WSRM can be controlled through a Microsoft Management Console (MMC) snap-in, called Windows System Resource Manager. With WS08R2 resource allocation can also occur based on sessions instead of users. This mechanism is called Dynamic Fair Share Scheduling (DFSS). WSRM isn’t really necessary anymore for DFSS to be used, although the snap-in can still be used to control DFSS. The Windows Internal Database feature is still required though. ResourceManager Class is a type that defines how resources can be managed, i.e. by the WSRM-mechanism. A difference between the WSRM and the DFSS mechanism is that WSRM is reactive, while DFSS is proactive.

So, WSRM is a COM object of the type (class) “ResourceManager 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 10

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

Figure 11

On the General tab we see the field “Application Type”, with the value “Local Service”. This means the COM object is of the Windows service application type, which actually means it’s a COM object that actually implements a Windows service. To be complete: the file that implements the Windows service is a COM server containing the COM object, which represents the “real” Windows service. The field “Service Name” contains the technical name of the Windows service (“WSRM”), as can also be read in the registry from the REG_SZ named value LocalService (see figures 6 and 8). A Windows service is described through its own key (with the technical service name as the key name) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services, so for our service this is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WSRM. The friendly name of this service is defined by the REG_SZ named value DisplayName: Windows System Resource Manager.

Figure 12

Figure 13

As already said, some Windows services have their own executable to run, others rely on a generic Windows service hosting executable (svchost.exe). In the last case the Windows service is implemented in a DLL that gets loaded into an svchost.exe. The “path to executable” (see figure 13) tells us that’s not the case, so our service runs in its own process. With other words, our COM object/server is implemented in an exe file.. The service key also tells us which file implements the Windows service (or thus the COM server/object). For this type of Windows service this is defined by the REG_EXPAND_SZ named value ImagePath:

%SystemRoot%\system32\wsrm.exe (so on 64 bit Windows, this is a 64 bit image).

So, with all this new information, let’s translate the error into a more understandable form. A user tries to locally activate the COM object “Windows System Resource Manager”, which runs as the Windows System Resource Manager Windows service. The problem is this seems to fail, because the user doesn’t seem to have the permission to ask for a Local Activation of this COM object.

Let’s take a look at the permissions. Right-click “My Computer” in Component Services and select “Properties”. Go to the “COM Security” tab and note the “Launch and Activation Permissions” section. Click the button “Edit Default…” and a new dialog box (“Launch and Activation Permission”) pops up. On the one and only tab (“Default Security”) we can see SYSTEM has the Local Launch permission. Of course this is the permission set at a general level, but we can check if something has changed on the specific COM object level. Right-click the COM object (Windows System Resource Manager), select Properties and select the Security tab. You see everything, including the “Launch and Activation Permissions” section, is grayed out. This is by design.

Figure 14

Figure 15

Go to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{0643C58D-5861-4F0C-AE82-FC867CCEDD7A}, right-click the key and select Permissions. In the new dialog box that appears you see Administrators has only read permissions. You cannot change this as you don’t have the permission to change permissions. So you should take ownership of the key (the special built-in “user” NT SERVICE\TrustedInstaller has the default ownership, mentioned as just TrustedInstaller). Click the button Advanced, select Administrator (or Administrators) and click OK. Then give Administrators Full Control and click OK.

Figure 16

Figure 17

Figure 18

Now you should restart Component Services and try again:

Figure 19

Aha, now we can see more and even change stuff for our COM object. We see the COM object’s launch and activation permissions don’t follow the default settings and are customized (the radio button for the choice “Customize” is selected). Click the “Edit…” button and you can see in the new dialog box normal users do NOT have Local Launch or Local Activation permissions for this COM object!

If you give that user (or a group of users, perhaps even all users) the Local Activation permission for our COM object, you will see the error won’t be logged anymore! But… who says the user deserves this right? And why does the user tries to do this local activation in the first place? What was going on? We have to know this first before determining what to do. For that, let’s start with trying to understand a few more background details.

We know from figure 13 the service starts up automatically (except when you have changed the default startup type for this service of course). So the Windows System Resource Manager, implemented by the service with the same name, is always up and running. In Task Manager you can indeed notice its 32 bit or 64 bit process (depending on the architecture of the OS), based on the image wsrm.exe. If we take a look at the Details tab of the file’s properties in Windows Explorer we see the description tells us nothing more (“Windows System Resource Manager”).

Figure 20

Figure 21

Also take a look at the access permissions for the COM object:

Figure 22

So what has happened? A normal end user probably wanted to get or achieve something from or ask to WSRM. Huh? That would be a weird behavior, especially because a normal user doesn’t have access permissions! Is it? Think about it. What if a normal user would start the WSRM console and tries to connect to the local WSRM service? Indeed, the user wants to access this service (and thus actually the COM object), which fails of course, and then the local activation attempt occurs in a way to “self-repair” the situation, because the user thinks he/she should get WSRM up and running again (although it’s already up and running). This failure is logged as the error described in this article.

To finish I would just like to show a few other places where the CLSID and APPID can be found in the registry. I’m not going to discuss their meaning here (as it doesn’t really matter for the purpose of this blog post), but it can be interesting to be aware of their existence.

Figure 23

Figure 24

Figure 25

Figure 26

Note: if some settings are not default for you, this could also explain the error. For example, if the Local Activation permission is taken away from Administrators for the COM object, the error could be logged for them too of course.

Greetings,

Pedro

Side note 1: 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.

Side note 2: besides the AppID, which refers to the “Windows System Resource Manager” Windows service (that uses wsrm.exe), the CLSID has a sub key InProcServer32: “a local COM server”, but only for the in-process scenario and not related to a Windows service. It refers to the wsrmlib.dll file.

This means the COM class exists in 2 form: a standalone exe to be used as a Windows service and a non-service DLL. The only real instance (COM object) defined is for the service scenario. For the other scenario there is no predefined instance registered (the DLL can be launched in many different processes…).

Figure 27

The full path is

C:\Windows\System32\Windows System Resource Manager\bin\wsrmlib.dll. %windir%\System32\Windows System Resource Manager is a WSRM directory containing a lot of stuff, including a subfolder “bin” that includes the DLL (amongst other things). The DLL contains the WSRM functionality too, which is confirmed by the file’s description.

Figure 28

Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s