DistributedCOM Error.

TonyGts said:

What u did by deleting all entries in the registry for GUID {1B562E86-B7AA-4131-BADC-B6F3A001407E} in the eventlog is it not the same as what Vaio 7 did by setting 0 to the dword to disable the event logging of this same GUID?

I am not certain. What I do know is that if I'm going to mess with the registry, I do only one thing at a time so that it is reversible should something go wrong. I always have a backup of my ENTIRE CURRENT REGISTRY before deleting any one thing.

I haven't had a single DCOM error for a couple of months now and my computer runs flawlessly; so deleting them (GUID's) hasn't caused any problems or I wouldn't even be able to use my computer if they were vital to the OS structure when booting up or restarting.

I get that these errors are benign, but I am a little surprised at how quickly they are dismissed. The Event Viewer is being saturated with these CRITICAL errors and that seems to be "ok". Where is the outrage? I have this on 3 brand new machines each with 1803 and the latest "culmulative" updates. It seems like there should be an uprising against this error, especially since it's been around for so long and has been impacting so many scenarios.

I also cannot help but to wag my finger a bit at those who are quick to minimize this issue. This is a CRITICAL ERROR that is being logged to the event viewer. We should be asking questions and elevating this to the appropriate people in MSFT. I am also aware that this has been deemed "as designed" but sorrynotsorry that does not make this OK. When did it become "by design" (and acceptable!) to not try/catch your code and emit critical errors to the user's event log?

This is standard development procedures 101. You try-catch for the condition and handle it elegantly in your code, not throw critical errors and pollute the user's event log. If anything you emit an INFORMATIONAL or perhaps a WARNING... but not a *crititcal* error!

I almost feel that we should make a UserVoice out of this. Has this been done?

@f14tomcat I appreciate your guidance. To clarify my ask, I was asking if anyone knew here of a UserVoice site where this issue has been promoted, not to promote/use this forum as such. :)

That sounds like a "no" then.

LOL thank you for taking a most attentive and dissected appreciation to my posts, Wynona. :)

I think this boils down to me not properly restating my intent, and as a result you misunderstanding what I was saying. All of your quoted material underscore the fact that I was asking if a known uservoice (or petition) has been assembled around this issue. Additionally, I was not asking if The Forum here was being used in such a manner. I understand that it is more geared towards assistance/guidance and not a petition site, for which I am grateful for your kind feedback. My intention was to elicit any further knowledge around known petitions, which it seems like there are none.

So I will start one. :P FWIW, I have a little experience in creating these. :P

> This issue was noted mid-April 2018, and there have been several cumulative updates since then, so it's probably been solved by now.

A little more confusion here, I am afraid. I mentioned that I have installed 1803 on 3 brand new machines with the latest updates and this problem is still very clearly evident in all of them -- hence the source of my ire and why I am here! :)

All,

After sleeping on this and considering your feedback, I feel the need to share my appreciation for your efforts in steering me in the right direction here. Yesterday was not a good day for me and clearly frustration had gotten the upper hand on me by the time I got to posting on this thread.

Additionally, my tone was one of speaking to people that I know, am familiar, and comfortable with and clearly, that is not anyone here. Not yet at least.

So a quick word of thanks and appreciation for you and TenForums in general. This is a super cool place and I have found the answers many times during my travels. I will do better going forward keeping my frustrated vitriol in check and find a better place to put it... probably in a blog some place at some time, somewhere, somehow. :lol:

Anyways, I also wanted to share my solution here as a form of penance. The following PowerShell eradicated the offending events from my machine after a clean install of 1803. Perhaps it will assist others who have landed on this very dubious situation we have found ourselves in:

Code:

$paths = @(
	"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{1b562e86-b7aa-4131-badc-b6f3a001407e}",
	"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\{555908d1-a6d7-4695-8e1e-26931d2012f4}",
	"HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-User Device Registration/Admin"
)

foreach ($path in $paths)
{
	Write-Host "Disabling $path"
	Set-ItemProperty $path -Name "Enabled" -Value 0
}

If you find other channels, just add them to the $paths variable and away you go. Much appreciation to all who have likewise and shared their code and experiences here, I borrowed from you to make this script.

Also thanks again for your feedback. I always try to reflect on it and improve when I encounter it, which TBH happens a bit more than I would like. It's always an area of improvement for me, what can I say.

Microsoft support says "These events can be safely ignored because they do not adversely affect functionality and are by design. This is the recommend action for these events." Why do they not replace that statement for the " This security permission can be modified using the Component Services administrative tool." in event viewer. Does MS like giving us the runaround?