DCOM error related to Machine Debug Manager

Posted on Updated on

(or what you need to know about DCOM and Machine Debug Manager)

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




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




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

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 Machine Debug Manager 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 it class ID (CLSID) and application (AppID, here mentioned as APPID). The CLSID is {B20E899D-B079-479D-A4DC-10F758D9CD9A} and the APPID is {9209B1A6-964A-11D0-9372-00A0C9034910}. 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
  • 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\{B20E899D-B079-479D-A4DC-10F758D9CD9A} on 32 bit Windows and on 64 bit Windows we find HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{B20E899D-B079-479D-A4DC-10F758D9CD9A}.

Figure 4

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
  • 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 5

Figure 6

Figure 7

Figure 8

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 “Machine Debug Manager”.

So, Machine Debug Manager is a COM object of the type (class) “MDM Utilities”. 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, Machine Debug Manager, 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 (“MDM”), as can also be read in the registry from the REG_SZ named value LocalService (see figures 5 and 7). 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\MDM. The friendly name of this service is defined by the REG_SZ named value DisplayName: Machine Debug Manager.

Figure 11

Figure 12

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 12) 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 n 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:

“C:\Program Files (x86)\Common Files\Microsoft Shared\VS7DEBUG\mdm.exe” (for 64 bit Windows) or “C:\Program Files\Common Files\Microsoft Shared\VS7DEBUG\mdm.exe” (for 32 bit Windows).

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 “Machine Debug Manager”, which runs as the Machine Debug 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 the COM object, select Properties and select the Security tab. By design many COM objects have very tight permissions, so you can’t change their settings and everything is grayed out in Component Services if you take a look at the properties (and because of that you can’t even click buttons to open new dialog boxes to show other settings). We are lucky now, because in this case nothing is grayed out (that is, if you”re an administrator). So, on the Security tab, you can see in the section “Launch and Activation Permissions” “Customize” is selected, which means the object doesn’t take over the default launch and activation permissions set at the system wide level. Click the button “Edit…” and a new dialog box pops up, named “Launch and Activation Permissions”.

Figure 13

This screenshot only show the rights for the local group Debugger Users, but I can tell you the permissions are the same for Administrators (that is, by default). The user I had an error logged for wasn’t a member of Administrators or Debugging Users, explaining why the user had no Local Activation permission.

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 what Machine Debug Manager is.

We know from figure 12 the service starts up automatically (except when you have changed the default startup type for this service of course). So the Machine Debug Manager, implemented by the service with the same name, is always up and running. In Task Manager you can indeed notice its 32 bit process, based on the image mdm.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 (“Machine Debug Manager”). The path leading to the file does tell us something: it’s a common/shared Microsoft file and VS7DEBUG refers to Visual Studio (VS). Version 7 (or more complete: 7.0) is the same as Visual Studio .NET 2002 (you can see part of this being confirmed by the “Product name” field on the Details tab, informing us the exe is or is part of “Microsoft® Visual Studio .NET”). The file version is also 7.x, similar to the VS version.

Figure 14

Figure 15

Ok, before we continue, you should know something about script debugging. Several script debuggers exist:

  • Every Office version from 2000 till 2007 has an optional tool called Microsoft Script Editor (MSE). This tool makes it possible to work with HTML and scripts for Office documents from within Office applications (like Word). It’s based on Microsoft Visual InterDev, part of older VS versions and used to create ASP web applications. In Office 2003 and 2007 this tool is actually a super-light edition of Visual Studio .NET 2002 (7.0). Before Office 2003 the file implementing the tool is called MSE.EXE, but from Office 2003 on it’s called MSE7.EXE, so it clearly refers to the new MSE version. The About dialog box of the new MSI (since Office 2003) calls the tool Microsoft Development Environment 7.0. Office 2010 doesn’t contain MSE at all. I have Office 2007 (Office 12) installed and the path to MSE7.EXE is %CommonProgramFiles(x86)%\microsoft shared\OFFICE12 (on 64 bit Windows; on 32 bit Windows this would have been %CommonProgramFiles% \microsoft shared\OFFICE12). MSE can be used for script debugging too.
  • Microsoft Script Debugger (MSD), implemented as %ProgramFiles%\Microsoft Script Debugger\msscrdbg.exe on 32 bit Windows or %ProgramFiles(x86)%\Microsoft Script Debugger\msscrdbg.exe on 64 bit Windows. This program supports Windows Script Host (WST) based scripting languages (like VBScript and JScript) and can be downloaded and installed separately from http://www.microsoft.com/en-us/download/details.aspx?id=22185. The one and only version is 1.0. It’s deprecated by now though and actually MSE is its successor (MSE is also more sophisticated).
  • Microsoft Visual InterDev contains its own script debugger.
  • Something else is Internet Explorer Developer Toolbar, supported by IE6 and IE7. Its successor, Internet Explorer Developer Tools, are built-in in IE8 and IE9. Those IE specific developer tools include a Jscript debugger. You can start Internet Explorer Developer Tools through the menu item “Developer Tools” in the Tools menu of IE or by the keyboard shortcut F12. That’s why they are also called the “F12 Developer Tools”. Hey, in some languages (like Dutch) “F12” is even included in the real name of the menu item! J
  • Last, but certainly not least, we have the script debugger from Visual Studio (VS) itself.

Some of the script debuggers (or applications that include this functionality amongst other features) need a special component to get a list of debuggable processes. This component is called Machine Debug Manager (MDM), implemented as a Windows service with the same name. With this background information it may not surprise you it resides in a folder called VS7DEBUG. Also interesting to be aware of is the folder for MDM application settings for all users: %ALLUSERSPROFILE%\Microsoft\Machine Debug Manager. MSE and Microsoft Script Debugger are 2 examples that need MDM. Heck, MDM is packaged with those tools. So if you install MSE or Microsoft Script Debugger, MDM is installed too. MDM is also installed with Visual Studio, but not anymore since version 2005…

If “Disable script debugging” isn’t checked (enabled) in Internet Explorer (see the Browsing section on the Advanced tab of the Internet Options dialog box), you can debug JavaScript and VBScript with the default script debugger, not only from IE itself, but only from other applications (like Outlook for instance). I think IE supports this starting from version 5. Starting with Windows XP SP2 “Disable script debugging” has been split into “Disable script debugging (Internet Explorer)” and “Disable script debugging (other)”. The first setting controls script debugging from IE, the second one from other applications. For end users it’s best to enable those settings and thus to disable script debugging. In IE8 on WS08R2 (SP1) it seems the first setting is enabled by default, so it, while the second is disabled (so IE script debugging is disabled and other script debugging is enabled). On another system with IE9 and Windows 7 (Ultimate) both settings were enabled by default (so script debugging was disabled completely). I don’t know if Office installations have an influence on this. On the first system I have Office 2007 (Enterprise) installed, while on the other system I have Office 2010 (Professional Plus, 64 bit) installed. A third system has WS08R2 (SP1) installed, with IE9 and Office 2007 (Enterprise); every form of script debugging is disabled by default. For the first kind of system though I miust admit I’ve seen a few systems which seems to have both debugging settings enabled (so debugging disabled); perhaps it all depends on what is installed when, if IE9 was once installed (but removed later, what is happened on some of our systems), etc. What I want to say, is I haven’t really double-checked the default settings, but it could be there are some differences depending on a few factors. If you really want to find out, it’s best to check every possible scenario from scratch. Good luck and let me know the results 🙂

Figure 16

Figure 17

At the moment you enable script debugging (for IE, other applications or both), but the MDM service isn’t running, the MDM service gets started automatically and transparently if you have the permission to do so. Also, it is checked at logon (even if IE isn ‘t started) if script debugging has already been enabled for a logged on user and if it is enabled, the user has the right permissions (for example, by default the local Administrator) and the MDM service isn’t running, the MSM service is started. In both cases this is done through a local launch (well, I think so) and of course this won’t work if the service is disabled. With other words, setting the MDM service’s startup type to Manual to avoid the service from running, only works as long as no administrator or debugger user has some form of script debugging enabled.

So what has happened? A normal end user probably experienced an error in IE or an Office application which triggered script debugging and the MDM COM object was probably not activated yet. I must say I’m not really sure on this as every kind of script debugging is disabled for end users in our environment and the MDM service was running without any problem. So I don’t know how script debugging could have been triggered for that user and why the user couldn’t call the COM object without the need for activation. So the purely precise cause of the error is unknown to me… Just for completeness: activating and launching this COM object for use as a service is only possible by the SYSTEM (and the service is running as SYSTEM), Administrators and users from the local group Debugger Users. Also, script debugging would only be possible if the user has access permissions to the COM object. If you would take a look at the access permissions of the COM object, you would notice only SYSTEM, Administrators and Debugger Users have those permissions. Perhaps the error logged is related to a non-logged failed access attempt, followed by a logged activation attempt…?

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. One “weird” thing: in figure 21 you see the AppID being mentioned under a key named “CLSID”… I guess “CLSID” can be interpreted as CLSID or AppID in these contexts, depending on the precise situation.

Figure 18

Figure 19

Figure 20

Figure 21

The best thing to do is to set the MDM service’s startup type to Manual and to disable script debugging for every user, including local users like the local Administrator. This way normal users will never be able to even attempt script debugging (which corresponds to their IE settings); and even if they would change their script debugging settings in IE, the attempt will fail because of a lack of access and activation/launch permissions (an error could be logged though). Members of Administrators and Debugger Users will start with script debugging disabled too (again corresponding with their IE settings), except when they enable at least one script debugging setting, resulting in a start of the MDM service. It’s best to enable this only at the very moment you would like to script debug, to minimize the runtime of the service (and thus to minimize resource usage). When you’re done, you should disable the script debugging again and stop the MDM service. IMO a small drawback is that the MDM service is started by the system when there is at least someone with the right permissions who has script debugging enabled; another option for MS could have been to “local launch” MDM at the moment it’s actually needed, but perhaps this could make debugging “at-the-moment-it’s-needed” a little bit slower, because the service startup causes a small delay. With the current situation though, it could be that the MDM service takes resources for a long time when not really needed. Again, I think the best way would be to local launch MDM when needed and not proactively (I’m talking about a Manual startup type).

If you really, really want to be sure other ways of starting up the MDM service would be blocked too (for instance, some special tool that tries to do so), there is only 1 possibility: disable the MDM service. When you would really, really need it however, you can still set it to Manual. Don’t forget to set it to Disabled again when finished. Personally I think the Manual startup type” solution is the best balance between making it possible script debug by admins/debugger users, while not letting the service to run otherwise to save resources and performance.

On systems where developers, administrators or other special users should do script debugging as a daily task, you could leave the situation to the default (Automatic startup type). If, however, you would like to be able to let your users (or some of them) start up the service the same way as administrators could do with a Manual MDM service, you can always give them Local Access, Local Activation and Local Launch permissions for the COM object, but I guess that would be a very rare scenario. Adding them to the Debugger Users group is the best way to achieve this.

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.

Again, I don’t know what precisely has caused the error I’ve pasted at the beginning of my article, so I can’t say it was a bug, something caused by a special piece of software or some other cause which we could categorize as “bad design”. For the things I do know, the whole concept seems local to me, except for the proactive starting up of the MDM service when its startup type is Manual and there is at least one user who has logged on with the right permissions and script debugging enabled. Choose the right situation for you:

  • Leave it as default
  • Startup type Manual and disable script debugging for every user (even the local admin)
  • Startup type Disabled and disable script debugging for every user.

Disabling script debugging in IE doesn’t really matter if a user doesn’t have script debugging rights and/or the service is Disabled, but it could be a good thing for administrative reasons (the configuration you see represents the actual situation, i.e. script debugging is not possible). When someone would enable script debugging in IE though it can be considered as a personal choice, even while at a lower level the actual script debugging is disabled.




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.


One thought on “DCOM error related to Machine Debug Manager

    JB said:
    11/06/2013 at 09:33

    Wow, that was really an in depth story. Sheds some light on this MDM thing I have ran across multiple times. Thanks for time and effort!

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