DistributedCOM Error.

This is the subject of many previous TenForums threads. It is a benign error, though, and is not something you MUST fix. Rather, it is something you CAN fix if it bothers you sufficiently to expend the time and effort necessary to do so. It's all discussed in excruciating detail in this 38-page thread on the Performance&Maintenance forum (check thread #2 for the beginnings of the solution/fix): Windows 10 Event ID 10010 and 10016 Errors With DistributedCOM - Windows 10 Forums.
HTH,
--Ed--

EdTittel said:

It is a benign error, though, and is not something you MUST fix. Rather, it is something you CAN fix if it bothers you sufficiently to expend the time and effort necessary to do so.

Yes, thank you for pointing me in a direction I can possibly pursue to correct the problem. I have manually fixed 10016 errors before by granting permissions and altering the registry.

This one has me stumped though because the APPID and SID are unavailable and usually there are two sets of Guid's to work with in order to fix the problem manually.

Since only one is given:

{1B562E86-B7AA-4131-BADC-B6F3A001407E} it doesn't leave me room to grant permissions to anything; yet alone be found in the Component Services Console by another name in order to grant access to Local or any other accounts.

This one is truly going to take some time to sort out, and I'll keep looking.

I don't know (and haven't been able to find) a single case where a DCOM error has led to noticeable performance degradation or other stability or reliability issues with Windows 10. Seems like something less that critical priority, in the grand scheme of things. That said, of course, it's your system and you can choose how you want to spend your time and energy on it. Do keep us posted, if you find anything interesting, or figure something useful out. Thanks,
--Ed--

EdTittel said:

Do keep us posted, if you find anything interesting, or figure something useful out. Thanks,
--Ed--

Since I put 1803 on my system before it was even offered by Windows Update/Upgrade Assistant; I really don't have much to complain about since I did it at the risk of not knowing if it would be stable or not. So far, so good; and I'll have to wait for the Stackflow errors from other users that have the OS Build 17133.1 on their Windows Home Edition before I can even troubleshoot this one.


Pounding away at the Microsoft support links hasn't yielded anyone reporting this DCOM error yet on Version 1803, or the steps to take in order to fix it. I had zero DCOM errors on my last build, but that took a couple of hours to grant permissions and tweak the registry. Usually Patch Tuesday would get rid of some of them and others were just plain stubborn.


Like I mentioned earlier, this DCOM error is unique in the sense that the error is being generated from the lack of Guid's; not solely because the permissions are granted incorrectly to produce the error. In other words, the error is being generated because something is missing; not because permissions are granted incorrectly.


I'll definitely keep this thread going until I find something.

I figured it out:

1- Navigate to ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole’.

2- Delete these four keys if they appear:

DefaultAccessPermission

DefaultLaunchPermission

MachineAccessRestriction

MachineLaunchRestriction.

3. Reboot your computer.

The DCOM error was not generated on a cold boot or restart.

I forgot that when you upgrade your version, the old permissions are granted to the new OS.


No wait...……….. the error is back without a restart or shutdown - I'm going to have to look at this closer I guess.

@EyeInTheSky

Here's the Wikipedia description of DistributedCOM (DCOM):

Distributed Component Object Model (DCOM) is a proprietary Microsoft technology for communication between software components on networked computers. DCOM, which originally was called "Network OLE", extends Microsoft's COM, and provides the communication substrate under Microsoft's COM+ application server infrastructure.
The addition of the "D" to COM was due to extensive use of DCE/RPC (Distributed Computing Environment/Remote Procedure Calls) – more specifically Microsoft's enhanced version, known as MSRPC.
In terms of the extensions it added to COM, DCOM had to solve the problems of

• Marshalling – serializing and deserializing the arguments and return values of method calls "over the wire".
• Distributed garbage collection – ensuring that references held by clients of interfaces are released when, for example, the client process crashed, or the network connection was lost.
• It had to combine Hundreds/Tens of Thousands of objects held in the client's browser with a single transmission in order to minimize bandwidth utilization.

One of the key factors in solving these problems is the use of DCE/RPC as the underlying RPC mechanism behind DCOM. DCE/RPC has strictly defined rules regarding marshalling and who is responsible for freeing memory.
DCOM was a major competitor to CORBA. Proponents of both of these technologies saw them as one day becoming the model for code and service-reuse over the Internet. However, the difficulties involved in getting either of these technologies to work over Internet firewalls, and on unknown and insecure machines, meant that normal HTTP requests in combination with web browsers won out over both of them. Microsoft, at one point, attempted and failed to head this off by adding an extra http transport to DCE/RPC called ncacn_http (Network Computing Architecture connection-oriented protocol). This was later resurrected to support a Microsoft Exchange 2003 connection over HTTP.
DCOM is supported natively in Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003, as well as Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016.


So, now that you have this information, you may want to look at Steve Gibson's Security site at GRC for a more complete history and further explanation of what it is and, using DCOMbobulator, how to take care of it for good.

While you're there, you might want to look around and see what else Steve has provided for the Windows Community. :)

Wynona said:

While you're there, you might want to look around and see what else Steve has provided for the Windows Community. :)

Thank you for this input. Unfortunately, I have tried running that Dcombobulator before and when I ran it this time I got this:



I seem to recall working with them in the past on another DCOM error. They were unable to help; but I haven't decided whether or not to submit this particular DCOM error because of the virginity of the OS Build.


Also, I know why the Dcombobulator can't explain the nature of the error. The error is being generated because something is missing to alert the protocols to flag the error with a valid APPID or a CLSID at all for that matter!

EyeInTheSky said:

Thank you for this input. Unfortunately, I have tried running that Dcombobulator before and when I ran it this time I got this:



I seem to recall working with them in the past on another DCOM error. They were unable to help; but I haven't decided whether or not to submit this particular DCOM error because of the virginity of the OS Build.

Also, I know why the Dcombobulator can't explain the nature of the error. The error is being generated because something is missing to alert the protocols to flag the error with a valid Guid or a Guid at all for that matter!

That's a shame, Eye. I'm assuming you've updated from prior Insider Builds:

I forgot that when you upgrade your version, the old permissions are granted to the new OS.

I think your system is very sick and you should consider a clean install and all that it entails, such as backing up all your data files, and being sure you have keys available to all your software.

It seems that the error you've pegged as causing the DCOM error is also causing DCOMbobulator to de-combobulate. Basically, two patients are telling each other they are sick. There seem to be internal OS errors with Remote Procedure Call service, which is serious. Almost all Windows services depend on the RPC service; if it's sick, the whole machine is sicker.

I know it's a bummer, but sometimes it's best to just bite the bullet, go back to the drawing board and proceed from there to a clean installation. It should take a lot less time than troubleshooting this error.