DCOM error related to NAP

Posted on Updated on

(or what you need to know about DCOM, NAP and SCCM)

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

Event ID: 10016

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




to the user NT AUTHORITY\SYSTEM SID (S-1-5-18) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

Source: DistributedCOM

Level: Error




Task Category: None

Keywords: Classic

OpCode: Info

Figure 1

Figure 2

Figure 3

Figure 4

I first discovered the error on a Remote Desktop Session Host (RDSH), but it’s not RDSH related at all; at the contrary, it’s a quite generic issue. I have already said too much with the title, so yes, it’s Network Access Protection (NAP) 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 the user NT AUTHORITY\SYSTEM (= LOCAL SYSTEM), with SID S-1-5-18 (which is always the SID for LOCAL SYSTEM), wants to launch 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 Launch. 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 it class ID (CLSID) and application (AppID, here mentioned as APPID). The CLSID is {24FF4FDC-1D9F-4195-8C79-0DA39248FF48} and the APPID is {B292921D-AF50-400C-9B75-0C57A7F29BA1}. It seems the permission settings for this COM object don’t grant SYSTEM the Local Launch 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
  • 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\{24FF4FDC-1D9F-4195-8C79-0DA39248FF48} and on 64 bit Windows we also find HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{24FF4FDC-1D9F-4195-8C79-0DA39248FF48}.

Figure 5

Figure 6

We see our CLSID is registered at the 64 bit and 32 bit level (on 64 bit Windows), has a related AppID {B292921D-AF50-400C-9B75-0C57A7F29BA1} for both and carries the name “Quarantine Private SHA Binding class”. 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
  • 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 7

Figure 8

We see our AppID is registered at the 64 bit and 32 bit level (on 64 bit Windows) and has the name “NAP Agent Service”.

“NAP” stands for “Network Access Protection”, a Microsoft technology to check for the heatlth of clients accessing NAP-aware resources and even to remediate those clients. For example, NAP could check for clients’ antivirus state (for example, if the antivirus definitions are up to date) and grant access to a resource based on this result. The things NAP checks for and the things NAP wants to remediate depends on NAP policies the administrator can configure. A client that supports NAP has a Windows service called “Network Access Protection Agent”. If this service doesn’t run, the client isn’t effectively supporting NAP.

SHA (Secure Hash Algorithm) is a set of hash functions defined by the standardization organization National Institute of Standards and Technology (NIST) as a so-called Federal Information Processing Standard (FIPS). But… this SHA has nothing to do with hashing! In this case SHA stands for System Health Agent, the client part of the NAP technology (the server part is called the NAP health Policy Server (NPS), containing the System Health Validator (SHV), SHA’s counterpart). So Quarantine Private SHA Binding class is the class for SHA functionality.

So, NAP Agent Service is a COM object of the type (class) “Quarantine Private SHA Binding class”, meaning it’s an SHA. 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 9

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

Figure 10

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 (“napagent”), as can also be read in the registry from the REG_SZ named value LocalService (see figures 7 and 8). The friendly name of this service is Network Access Protection Agent:

Figure 11

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’s loaded into the svchost.exe process. The “path to executable” (see figure 11) tells us that’s the case, so our service runs in such a svchost.exe process. With other words, our COM object/server is implemented in a DLL. For completeness, 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\napagent. This key also tells us which DLL 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 ServiceDLL in the sub key Parameters: %SystemRoot%\system32\qagentRT.dll (with “q” probably referring to “Quarantine” and “RT” to “Run-Time”).

So, with all this new information, let’s translate the error into a more understandable form. At boot time the system (as the user SYSTEM) tries to locally launch the COM object “NAP Agent Service”, which runs as the Network Access Protection Agent Windows service. The problem is this seems to fail, because SYSTEM doesn’t seem to have the permission to ask for a Local Launch 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, 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 12

Figure 13

Go to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppID\{B292921D-AF50-400c-9B75-0C57A7F29BA1}, 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. Click the button Advanced, select Administrator (or Administrators) and click OK. Then give Administrators Full Control and click OK.

Figure 14

Figure 15

Figure 16

Now you should restart Component Services and try again:

Figure 17

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 SYSTEM does NOT have Local Launch permissions for this COM object!

If you give SYSTEM the Local Launch permission for our COM object and you restart the system, you will see the error isn’t logged anymore! But… take a look at figure 11 again and watch the Manual startup type for the service… It seems the service isn’t started automatically at boot time, which is the default for this service. What if we would change the startup type to Automatic? I’ve tried it out and it seems the error doesn’t appear either! So it seems “something” tries to use the “Network Access Protection Agent” Windows service and if this isn’t running, it tries to activate (and thus first launch) the COM object directly (which would result in the NAP service being started), which fails because of a lack of permissions, resulting in a System event being logged.

So what can you do about it? Well, you could automatically start the “Network Access Protection Agent” Windows service. But if you don’t use NAP you shouldn’t run it (as a best practice: only run things you need to run) and then you must choose between assigning the Local Launch permission to SYSTEM or ignoring the error. The choice should be simple: if there is indeed “something” that needs that COM objects while the NAP service shouldn’t be running, you should assign the permission to SYSTEM (except when you should use dedicated accounts for that “something”, then you should assign the permission to this dedicated account); if that’s not the case, we should remove that “something” when it’s not needed, configure it not to make use of the COM object (if that can be configured) or let everything the way it is and ignore the error messages. So it is possible the best solution is not to do anything about it; it just all depends on what is needed and what can be done.

The big question is of course: what is that “something”? What exactly is trying to “local-launch” that particular COM object if the NAP service isn’t running? It’s not easy to find this out. To be honest I was just thinking of which extra features/roles/role services/software on the servers experiencing the error could have anything to do with NAP. The first thing on my mind was the SCCM client and… BINGO! When I started the system with the SMS Agent Host Windows service not started, no error was logged to the System event log. I really need the SCCM client, so removing or disabling it is not an option. The thing is the SCCM client consists of different pieces, some of them client agents. One of those client agents is the “Network Access Protection Client Agent” agent (also called the SCCM SHA (System Health Agent), although the NAP Windows service is the actual SHA, so “SCCM SHA Client Agent” had been a better name IMO), which tries to bind to the “Network Access Protection Agent” Windows service. If this service isn’t started, it tries to launch our COM object, as the LOCAL SYSTEM, because that’s the account the SMS Agent Host is running under. Actually this client agent shouldn’t be running if the NAP service isn’t needed (or at least it shouldn’t do anything, even not trying to load our COM object), but it doesn’t seem possible to disable the client agent (and thus the binding attempt) or change some setting so it would change its behavior. It’s possible to disable NAP through SCCM, but technically the client agent and the Windows service should be running for that; disabling the NAP client agent itself doesn’t seem possible though. Anyway, the launch of the COM object fails of course. The failed binding attempt is logged in %windir%\SysWOW64\CCM\Logs\smssha.log (64 bit Windows) or %windir%\System32\CCM\Logs\smssha.log (32 bit Windows):

<![LOG[CORE: SHA Registered successfully with the NAP Agent, but could not succesfully bind]LOG]!><time=”16:47:33.249+-120″ date=”05-16-2012″ component=”smssha” context=”” type=”2″ thread=”2088″ file=”qabroker.cpp:938″>

<![LOG[CORE: NAP Agent Service might not be running]LOG]!><time=”16:47:33.249+-120″ date=”05-16-2012″ component=”smssha” context=”” type=”3″ thread=”2088″ file=”qabroker.cpp:939″>

This piece of log is from another moment than the logged event, but it doesn’t really matter to understand the real content of the logging. The log starts with “SHA Registered successfully with the NAP Agent”, meaning the COM object is indeed registered for use by the NAP service. And the log continues: “but could not succesfully bind”, so the NAP client agent couldn’t bind to the NAP service. A possible reason is the NAP service doesn’t run (which is the case in my situation): “NAP Agent Service might not be running”. The actual failed attempt to launch the COM object isn’t logged here, but as you know, it’s logged as a System event.

Figure 18

So, because I need the SCCM client, I’m stuck with the NAP client agent, the NAP service doesn’t run (because I don’t need it) and I can’t change the NAP client agent’s behavior, I’m stuck with this error, except when I would give SYSTEM Local Launch permissions for our COM object. As I really don’t need NAP, I don’t see a reason why our COM object should be launched, so the safest and cleanest way is not to assign this permission. The only drawback is the logged error (doesn’t seem clean) and the small resource usage for the failed launch attempt at boot time, so just ignore the error and live with it. In my opinion Microsoft should fix this, so the NAP client agent doesn’t try to launch the COM object except in the very exceptional situation where you don’t want the service to run, but would desire the COM object to be launched by the NAP client agent, it should be some very advanced configuration setting. So the SCCM client should check if it has the permission to launch NAP (and of course only if the service isn’t disabled!). If it doesn’t have the permission, it should not attempt the launch and shouldn’t log an error. J Oh yes, I’m talking about SCCM 2007 here; I don’t have the faintest idea what’s going on with SCCM 2012. I hope to find out it’s fixed in this new version of SCCM! If you know the answer, please let me know!

Attention: don’t forget to undo the permission changes at the registry level. Remove the Full Control permissions you’ve just assigned and make TrustedInstaller the owner again. You can do the latter by the name “NT SERVICE\TrustedInstaller” (make sure you the current system is the selected domain).




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.

UPDATE: it seems the error also appears when SMS Agent Host has started after a service crash, stop + start or restart. With other words, it doesn’t happen at boot time only, but just with every start of the SCCM client’s Windows service.


7 thoughts on “DCOM error related to NAP

    Jeremiah said:
    17/08/2012 at 03:16

    Thank you very much, you saved me a few hours of research!!!!!

    DaveWill said:
    25/10/2012 at 14:05

    Excellent write up.

    MarkieS said:
    19/12/2012 at 12:45

    Nice explanation of a subject that has always slipped through my mental fingers. This gives me a pair of goalkeeper gloves to catch it all with now..

    Antti said:
    04/01/2013 at 10:28

    You really digged into this. Thanks!

    Milosz said:
    27/06/2013 at 18:53

    great article! it saved my a*** after reinstalling SCCM 2012! It’s already in favorites as it generally helps withcom/dcom problems!

    beedee said:
    31/10/2013 at 15:42

    Dude you are awesome.. wow!! you know your stuff inside out..

    Rho said:
    27/07/2017 at 10:05

    Awesome, great job.

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