Windows 10: Administrator can change owner of registry key but not permissions...

I'm running 64-bit Windows Pro on an Asus P5Q-EM MB with an Intel E8600 processor with 8 GB of PC2-6400 Ram.

I've had a couple of unexpected shutdowns and restarts lately. I've got several different error types in my event log. The only one showing to be "critical" is the Kernal Power one that simply says it has recovered from an unexpected shutdown.

I decided to just start eliminating he errors one by one to see if I could find/resolve the cause. The one I started with was several DistributedCom 10016 "The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID xx..."

I found the CLSID in the registry and noted that the owner was TrustedInstaller. I changed it to the Admin user, checked the include child, subfolder, inheritance, etc. boxes and hit apply. It gave me an error saying that it could not save the changes but I noted that it had in fact changed the owner. After getting out of permissions and then re-entering I attempted to change the Admin user/owner's permission to Full Control.

It will not change. It gives me an error saying that it cannot save the changes. I've always been able to solve registry access issues in the past simply by taking ownership. Why not this time?

Anybody know why a registry key owner would not be able to make permission changes?


Thanks in advance,

Howard
=====================================================================================
Log Name: System
Source: Microsoft-Windows-DistributedCOM
Date: 6/26/2016 10:34:23 AM
Event ID: 10016
Task Category: None
Level: Error
Keywords: Classic
User: P5Q-EM\wooda
Computer: P5Q-EM
Description:
The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{C2F03A33-21F5-47FA-B4BB-156362A2F239}
and APPID
{316CDED5-E4AE-4B15-9113-7055D84DCC97}
to the user P5Q-EM\wooda SID (S-1-5-21-4244340960-2181271989-1333400844-1010) from address LocalHost (Using LRPC) running in the application container Microsoft.Windows.FeatureOnDemand.InsiderHub_10.0.10586.0_neutral_neutral_cw5n1h2txyewy SID (S-1-15-2-4016783169-893401051-2237370320-274899566-412088533-2398988950-2155762795). This security permission can be modified using the Component Services administrative tool.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-DistributedCOM" Guid="{1B562E86-B7AA-4131-BADC-B6F3A001407E}" EventSourceName="DCOM" />
<EventID Qualifiers="0">10016</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8080000000000000</Keywords>
<TimeCreated SystemTime="2016-06-26T17:34:23.628753000Z" />
<EventRecordID>5970</EventRecordID>
<Correlation />
<Execution ProcessID="924" ThreadID="8332" />
<Channel>System</Channel>
<Computer>P5Q-EM</Computer>

:)

 

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

Hi

a) Locate the App ID in the Registry (regedit)

b) Change the owner of the Key in Permissions > Advanced > Change Owner from TrustedInstaller to Administrators (That lets local Administrators own the key)

c) Add Administrators to be allowed to Change Values

d) You need to check after reselecting the key that the permissions are what you want for the user you are attempting to alter in Component Services - if not add or amend the user in the Registry on the key

e) Then launch Component Services

f) Then select the Item and change what you are wanting to do

g) You should now go back to the Registry Key and change the owner back to TrustedInstaller - thats NT Service\TrustedInstaller

Nigel

 

A ghost in my PC is turning my filter keys on at the settings options, while I'm not watching... I have video proof...

To make Registry Key editable again:

• Right-click on the entry and select "Permissions"→"Advanced"→"Owner".
• Change "SYSTEM" to "Administrator"

 

Microsoft did that to protect the OS from the end user. Windows 10 was built on security to make sure that the end user is protected by their own bad habits.

 

Unexpected shutdown are likely caused by hardware issues, not incorrect registry settings. But I doubt they were incorrect anyway.

 

See the part where they changed ownership from "Trusted Installer" to Admin, which caused the error.

 

Ha ha. You're probably right about that but it doesn't answer anything.

It shows up as an error. It says that the error is incorrect permissions. It then says "This security permission can be modified using the Component Services administrative tool".

It allows me to take ownership but it doesn't allow me to change permissions. I'm wondering if it has something to do with me being logged with my Microsoft account instead of the local administrator account. I'll give that a try.

 

It does answer why you are not allowed to over ride the "Trusted Installer" Permission.

Windows 10 was built on a very secure platform and coded to protect users from their bad habits.

The reason for certain folders and files cannot be changed from Trusted Installer, is once again to protect the OS from bad things and bad user habits.

 

Also the Live Account is what is called a "Roaming Profile". Thr Local Account is exactly that.

 

Nope. Logging on as the local administrator allowed me to make all the permission changes required to eliminate the error. Not sure why you think the Windows 10 folks would have wanted to disallow these changes -- especially after the ownership was changed.

Nevertheless, permissions changed and errors gone.

Thanks for your time and help.

Howard

 

Again you are not an Administrator. You are just a profile on the account with semi-elevated privileges. As for the permission changes from "Trusted Installer" to something else, it will not happen, even if all of the moons and planets align at the same moment. Microsoft made sure with Windows 10, that the user is protected from their bad habits and that it is harder for malware to try and take control of the OS.