Last Updated on September 23, 2022 by rudyooms
This blog will be, again about some nasty Store Apps issues!. In the conclusion of my last blog, I was already mentioning the fact that I was looking into some Startmenu and the OneDrive/ Outlook connection issues that were occurring.
I will divide this blog into multiple parts
- The Issue
- Fixing it the old way
- Troubleshooting the Issue
- Fixing it the new way
- If you don’t want to fix it manually
- The Root Cause
- The possible first “Trigger”?
- Microsoft ProfApi.dll
1. The issue
I guess I don’t need to mention that nasty 2022-05 update again, that broke the installations from the MS Store but when looking at the first time I noticed this Store issue (15-02-2022) this issue has been around for longer than the 2022-05 May update.
Let me explain what stops working.
- Outlook can’t connect anymore
- OneDrive stops syncing as it can’t connect anymore (0x8004de44) / Hangs on Signing in
- The Start menu is not responding on left click (right-click still works)
To give you a good idea of what is breaking, I also record it to let you show exactly what was happening!
Looking at all the stuff that is breaking, I guess we could just break the device and be done with it… but I guess we need to fix it, otherwise we wouldn’t be doing our job!
Now we know and have seen what stops working and if we didn’t break our device, we need to take a look at which events we would get if all that stuff breaks! Open your Application event log and start looking at all those excellent yellow warnings!
Event ID: 20
Triggered repair because operation LocalSettings against package Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy with error -2147024891.
Event ID: 21
Repair for operation LocalSettings against package Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy with error -2147024891 returned Error Code: –2147024891.
Event ID: 23
Triggered repair of state locations because of operation SettingsInitialize against package Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy with error –2147024891.
Event ID: 24
Repair of state locations for operation SettingsInitialize against package Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy with error -2147024891 returned Error Code: 0
It’s pretty obvious we are dealing with 2147024891 | 8007005 | Access Denied errors. But I am not done yet because another error caught my eye! As shown below, it is mentioning the 0xc000027b error.
The Application event log is not the only event log we need to dig into so let’s also take a look at the System event log. This event log is showing us the Kernel-General event 16 mentioning the application history in component AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Settings\settings.dat is deleted
Damn… Almost forgot one event log! As told earlier, when you are having sign-in issues with Onedrive and Outlook it’s always best practice to check out the AAD event log. As shown below even the AAD sign-in log is giving us the same 0x80070005 Access is denied error
2. Fixing it the Old way
When this weird issue started occurring we didn’t know exactly what was going on. At first, we just deleted the corrupted profile to make sure a new nice and shiny profile would be created
To do so we rebooted the device and logged in with a local admin user. After logging in we started deleting the c:\users\%username% folder and removing the user its profile key in the registry
With the old corrupted profile gone we could start logging in with the user again so the profile will be recreated. After logging in, please open your OneDrive and Outlook to make sure your Microsoft account is connected and working again!
Please Note: With the June update released we also made sure that we installed the June 2022-06 update which has the Store fix included.
3. Troubleshooting the issue
If we don’t want to recreate the profile and go through all the hassle to resync OneDrive etc we also have another option to fix it. As always I also looked if there was something useful in the MS-Docs.
Microsoft Store Apps fail to start – Windows Client | Microsoft Docs
When looking at the above link they do mention something about how to solve possible Store Apps issues.
That’s definitely one error (0xc000027b) we noticed before, right? I guess we have some missing permissions for “ALL APPLICATION PACKAGES” | AKA S-1-15-2-1 on some registry keys…. But which ones? because we have a lot of them!
When you are wondering what is happening in the registry, there is always Procmon!. Open Procmon and configure the filter first as shown below
Looking back at the error we got earlier 2147024891 –> Access denied. I will only add the filter “Include” the value “ACCESS DENIED”
As shown above, it is mentioning “Access Denied” on the HKU\S-1-12-1-2370815533-1185198546-48193434-4181760345\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer and the User Shell Folders registry keys. I guess that are the registry keys we need!
4. Fixing it the New Way
First, make sure the device got the 2022-06 update installed! Because the May update could break it again.?
When we are 100% sure the device is up to date open the registry (If you have the permissions to do so, otherwise run Regedit as admin and search for the correct user in the HKEY_USERS key) and validate the permissions on the below registry entries.
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
As mentioned before those registry keys need to have the “All Application Packages user” configured in the permissions and it also needs to have the “Read” box checked.
If the “ALL APPLICATION PACKAGES” user doesn’t have read permissions, you need to add them manually!
Of course, you could also automate the fix by using PowerShell. When looking at the script below that needs to be executed as an admin, It will first search for the SID of the Azure Ad user. After it got the right SID it will create a new-psdrive to make sure we can connect to the HKEY_USERS key.
After the PSDrive has been created it will add Readkey permissions for the missing “ALL APPLICATION PACKAGES” to the registry key
Please change the $packages to your own language
$Packages = "All APPLICATION PACKAGES"
$key = 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-12-1-*'
$profiles = (Get-Item $key)
New-PSDrive -PSProvider Registry -Name HKU -Root HKEY_USERS
Foreach ($profile in $profiles) {
$sids = $profile
$sids = Split-path -path $sids -leaf
$user = "HKU:\$sids\"
$test = test-path $user
if ($test -eq $true){
$Folder = "HKU:\$sids\Software\Microsoft\windows\currentversion\explorer\"
$Acl = Get-ACL $folder
$AccessRule= New-Object System.Security.AccessControl.RegistryAccessRule($Packages,"Readkey","ContainerInherit","None","Allow")
$Acl.SetAccessRule($AccessRule)
Set-Acl $folder $Acl
$Folder = "HKU:\$sids\Software\Microsoft\windows\currentversion\explorer\user shell folders"
$Acl = Get-ACL $folder
$AccessRule= New-Object System.Security.AccessControl.RegistryAccessRule($Packages,"Readkey","ContainerInherit","None","Allow")
$Acl.SetAccessRule($AccessRule)
Set-Acl $folder $Acl
}
}
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
After we made sure the permissions are all good, first let’s take a look if we maybe have some luck because changing the registry permissions resolved it for 75% of the devices.
If the problem still exists make sure you log in to the device with the USER who is experiencing this issue (NOT ADMIN, the user session! )
Once logged in, open 1 Elevated PowerShell session and 1 not elevated in the user it session. First, kill the explorer.exe with the use of the task manager.
Please note: When you don’t close the Explorer you could end up with some errors mentioning the resource is currently in use!
To fix that issue, I also added the -ForceApplicationShutdown to make sure the resources that are currently in use will be forced to shutdown
In the ELEVATED (RUN AS ADMIN) PowerShell session:
Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"} 
Please wait until it’s done! and just ignore the errors if you have any
In the NORMAL PowerShell session (in the user session)
Get-AppXPackage *Microsoft.Windows.Search* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
Get-AppXPackage *MicrosoftWindows.Client.CBS* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
Get-AppXPackage *Microsoft.Windows.ShellExperienceHost* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
Get-AppXPackage *Microsoft.AAD.BrokerPlugin* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
Get-AppXPackage *Microsoft.AccountsControl* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
Get-AppXPackage *Microsoft.Windows.CloudExperienceHost* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register "$($_.InstallLocation)\AppXManifest.xml"
}
After this PowerShell script is run, please reboot the device or just start explorer.exe with the use of Taskmanager and you will notice everything is working again!
5. When you don’t want to fix it manually
I guess sometimes we are all lazy admins! When you don’t want to go through all of the hassles of fixing it manually you could always perform a “Fresh Start”
But beware it will take some more time before the user could use his device again because it needs to go through the whole Device and User ESP again to install the required apps. It’s up to you to choose the solution you are happy with
6. The Root Cause
After comparing all the devices with some people, we noticed that 1 specific App was installed on those devices.
It looks like somehow the ClickShare app broke at some point in time and at that moment it was responsible for messing up the ALL APPLICATION PACKAGES permissions on those registry keys.
Luckily Barco (ClickShare) is also confirming this issue and are fixing it with the latest update! So make sure when you deployed the Permissions fix you also make sure the ClickShare app is up to date!.
Shall I let you on to a little secret? Microsoft has its own PowerShell Script to fix it! Comparing this script with my own version, this script needs to be executed in the User session! where my script needs to be executed in the system context.
It pretty much does the same thing 🙂 … it does fixes the missing permissions.
$acl1 = Get-Acl "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\"
#$person = [System.Security.Principal.NTAccount]"all application packages" ##S-1-15-2-1
$sid = New-Object System.Security.Principal.SecurityIdentifier ("S-1-15-2-1")
$person_temp = $sid.Translate( [System.Security.Principal.NTAccount])
$person = $person_temp.Value.Split("\")[1]
$access = [System.Security.AccessControl.RegistryRights]"ReadKey"
$inheritance = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit,ObjectInherit"
$propagation = [System.Security.AccessControl.PropagationFlags]"None"
$type = [System.Security.AccessControl.AccessControlType]"Allow"
$rule = New-Object System.Security.AccessControl.RegistryAccessRule($person,$access,$inheritance,$propagation,$type)
$acl1.AddAccessRule($rule)
$acl1 | Set-Acl
if (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin7. The possible first “Trigger”?
The ClickShare app is one of the apps that could mess up our Startmenu and broke the connection of our Office365 Apps but what could have triggered it? I already had some ideas about what could have triggered it but after noticing this post on Reddit, I became pretty sure
Intune: Mobile Device Management (reddit.com)
Looking at the Reddit post, the trigger could definitely be a self-service password reset by the user itself! After asking around some more, a lot of responses were the same:
“The user performed a password reset a couple of days before starting experiencing the issue”
8. Microsoft ProfApi.dll
UPDATE 23-09-2022 Official Response from Microsoft
While this initially appeared to be an issue with the 3rd party app, it now appears to be Microsoft code (profapi.dll) which breaks the permissions thinking they need to be recovered. This may occur when an x32 third-party process (like ClickShare) uses Office APIs on a machine where Office is deployed using Office ClickToRun, because of a bug in AppvIsvSubsystem32.dll registry hooks. In this case, profapi.dll will start recovering the ACLs, but after a second failure, it won’t write the All Application Packages ACLs, causing issues (crashes & registration failures) with packaged apps.
Bug record Bug 41322218: _RecoverUserShellFolderKeys fails to restore default permissions
So, its related to a version of Office Click-to-run. And it makes sense since issues are occurring since moving to MS Apps 2202 Enterprise channel
Conclusion
All those Store Apps issues we are experiencing the last few months are awful. Luckily most of the issues can be resolved. This blog will explain how you could solve issues with the start menu, Onedrive, and Outlook.
Please Note: I am still looking for the “why”! If I have more information I will share it with all of you!
If you are interested in solving issues with the Offline Company portal app please check out this blog
Company Portal not working after performing a Wipe/Reset (call4cloud.nl)
Thanks for this, it was a life saver.
I did however run into a couple problems.
1. If there are multiple profiles on the device the $DelFind = (Get-Item $key) returns multiple items and $sid contains more than 1 SID, so how do you get the correct SID?
I bypassed this by just setting $sid = ‘paste the current user SID from Registry’
2. Even after completing both ‘Fixes’ and rebooting the Search window was not working. This was only on some PC’s. I have not figured out how to fix that yet.
Hi.. it s on my list to take a look at it to make sure that for each it will be fixed
I updated the script so it works a little bit better when there are multiple sids
After 2 months we finally figured out how to fix this issue thanks to this article, so thank you! We don’t use ClickShare app, so I have no idea what app started this issue in our environment. It even happened on laptop where we did clean installation of Windows with just bunch of office software.
For people who got into issue with Windows Search after this fix, I just put this piece in PowerShell:
Add-AppxPackage -register “C:\Windows\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\appxmanifest.xml” -DisableDevelopmentMode
Then killed explorer.exe, ran again through task manager and Windows Search started working.
Finally a solution!
For the registry permissions, I noticed the all app account was missing from HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
The inheritance was also broken (I compared it to a working laptop), so I removed the accounts already there and enabled the inheritance and applied to all child objects. A few other apps were still not working, like the search bar, but the AppXPackage PS took care of that.
“It will first search for the SID of the Azure Ad user.”
Will this also work for on-prem or hybrid setups?
Is anyone who’s experiencing this issue happen to have ClickShare MSI installed on their machines?
That’s indeed one in my list of possible issues… but indeed I am noticing that app being installed on those devices
We have ClickShare installed in our environment and are experiencing this issue.
The updated blog will show you it is probably caused by clickshare indeed
We have had this issue on hundreds of workstations so far, all of them with ClickShare. We scripted a way to delete the affected profile and reinstate all the necessities with minumum fuss, but could not figure out why it broke. Thanks for this!
We are now upgrading a few thousand workstations to ClickShare 4.22.0.13, and crossing our fingers.
Nicklas, any way you could share that script?
We don’t have ClickShare, but do have this problem.
Has the windows search been fixed? The script from microsoft fixes Outlook/Teams/One drive/start menu, but search function from the taskbar is not working.
Going to look at it when i have a broken device to test with 🙂
Same thing here Office apps are working after the fix. But startmenue / searchbar don’t.
Usual taskbar fixes also don’t help – any suggestions?
Did you tried ms their fix or the first fix I was mentioning ? as that fix, fixed the apps and the start many for a lot of devices
I guess I need some logs to check out what is happening because I don’t have a device experiencing those issues anymore.. So feel free to send me the logs (application and appmodel-runtime) so I could check it out
Hi Rudy,
Thanks for this article, could it possible that may update also broke addins. In my case mimecast for outlook stopped working. Manuall upgrade/install would fail with error 1603.
I had to repaire O365 apps online to get it working.
The may update did indeed also break some stuff… not all but some of them did indeed break
Thanks! Real help!
Message from the ClickShare team:
As quality and security are always top of mind for ClickShare, we are aware of the reports on an unresponsive Windows taskbar for end-users. Our team has been working hard to analyze these. Up-to-now there is no evidence that the issue is related to the ClickShare App. Of course, we keep on investigating and monitoring.
To help users of the ClickShare App get back to work asap, we recommend to uninstall the ClickShare App, run the Microsoft updates, reboot the laptop and re-install the latest update of the ClickShare App.
Hi.. just received confirmation… last friday we also noticed the ksql query that the clickshare app (calandarreader32.exe) is fighting for those permissions (Microsoft API).. I guess barco now shares the same conclusion…
I can confirm we have the exact same behaviour but do not use clIckshare at all but do have a few other applications likely accessing the same API mentioned by Barco
Hi… I guess apps like zoom could also access that API indeed… wondering which apps you are noticing on this problem devices
We have not been able to narrow that down, does ClickShare add an add-in to Outlook or is it just an app using MAPI to read a users Outlook calendar? I am also curious does this issue only happen on devices with multiple Outlook Profiles or multiple mailboxes or calendars from what you are seeing?
We’ve found this restores most of the functionality of the devices but there are a couple of things.
Single Sign On is still broken, all the apps will ask you to sign in once the repair has been tried, and in the taskbar the volume, battery and network control functions still don’t work.
The other thing we’ve noticed is that while it is true that the reason for the start and search menu issue is because.
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Are missing the read permissions for “All Application Packages User”, it is because those two locations have lost inheritance which is why it has lost those permissions.
Hi.Looking at as example to the solution of barco… they will enable inheritance again.. So I assume the inheritance was lost in the first place.
If you have applied the fix, did you reboot the device? Because of the aadbroker plugin also got corrupted, it will break the sso at that point in time.
Yes we’ve managed to repair SSO now, they only function that is still broken, are the network, volume and battery functions in the taskbar, I assume there is another reg key for those that needs to have its inheritance enabled again.
Mmm thats weird.. as I didnt experienced that behavior myself. Did you also made sure to run the user powershell script to make sure the packages are reinstalled properly ?
Yes, tried running this across multiple devices now and those functions are still not available, the Date/Time is also not working, while they will update, such as the Battery icon sill tracking the charge level, but you can’t left click on any of them to access their features.
I believe I’ve found the problem, the command for installing the Shell Experience Host isn’t working on our devices for some reason, as I’ve checked with
Get-AppXPackage -AllUsers |Where-Object {$_.InstallLocation -like “*SystemApps*”} and it isn’t installed for the impacted user.
The command to install it,
Get-AppXPackage *Microsoft.Windows.ShellExperienceHost* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode -ForceApplicationShutdown -Register “$($_.InstallLocation)\AppXManifest.xml”
}
Runs but doesn’t install anything.
Brilliant! your PS script helped. The only possibility that has helped me in the last few weeks and months was a long-lasting Windows inplace update. According to your script, the start button works and after a reboot also the search field. Thanks a lot. Small note: we do not use clickshare. We had a problem with HTML mails in combination with Kerio Connector with the last Outlook365 v2205. (This has since been fixed by Kerio/GFI). That only as a tip in the direction of the MAPI interface.
Thanx! at first we thought it was because of the clickshare app.. as 99% of all device with the issue had that app installed 😛 … but as I was also showing it was more about the outlook API which was called upon by the app 🙂
Great Blog!
Unfortunately the search bar is still not working after applying your fixed so I had to recreate the users profile.
Hi..To be sure, you first made sure you executed the first part as an admin… and afterwards you registered all those apps in the user session?
Get-AppXPackage *Microsoft.Windows.Search* |
ForEach-Object {
Add-AppxPackage -DisableDevelopmentMode-ForceApplicationShutdown -Register “$($_.InstallLocation)\AppXManifest.xml”
}
And if its done reboot the device
I am wondering for those with the issues, what update channel you are on for M365 Apps?
In trying to narrow this down, I believe it is an Outlook update and specifically looking through release notes and trying to build a timeline, it seems to correspond with this “Fix” in release notes:
“We fixed an issue that prevented Outlook Event-Based Add-Ins from functioning properly.”
Current Channel started getting this Fix in April (Specifically on the 20th)
Monthly Channel started getting this fix in May (Specifically on the 10th)
Semi-Annual started getting this fix this month in June (Specifically on the 14th)
We are starting to roll back to a version prior to the Semi-Annual release to test as we do not run ClickShare or Kerio Connect which is another app triggering the same issue but have several different apps hitting Outlook and the issue is so sporadic we have not been able to pinpoint it exactly yet but leaning towards Mimecast at the moment.
Hi.. True, this information was also shared with Barco when we were looking into it, as there could be indeed a possibility its because of this update/change in the ms apps.. But because its almost holiday everywhere :).. SO I am not sure until Microsoft tells us something…. when I know for sure I will get back to you
Great Article! And thank you so much for having published it! We have the same issue and already open Microsoft tickets without any solutions.
Here is my quick fix (run with user privilege) to resolve it:
Rename-Item -Path “HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders” -NewName “User Shell Folders_old”
Rename-Item -Path “HKCU:\SOFTWARE\Microsoft\Office\16.0\Common\Identity”-NewName “Identity_old”
if (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register “$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml” -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin
logoff
We are still investigating where this issue is coming from!
Hi… it looks like the issue is caused by the Microsoft outlook API which other third part tools like zoom, barco are using
Hi, yes and we have the proof that for our case is coming from:
C:\ClickShareApp\ClickShare\app-4.22.0-b13\calendarreader64.exe
We found that by turning on permissions auditing on the registry key:
“HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders” to monitor what permission are modified and boom we got the executable that is causing the issue.
Here is the event log collected :
———————————-
Permissions on an object were changed.
Subject:
Security ID: ITEOS\username
Account Name: username
Account Domain: ITEOS
Logon ID: 0x194C60ED
Object:
Object Server: Security
Object Type: Key
Object Name: \REGISTRY\USER\S-1-5-21-130038992-1272150033-662139138-xxxxx\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Handle ID: 0x15f4
Process:
Process ID: 0x1ea0
Process Name: C:\ClickShareApp\ClickShare\app-4.22.0-b13\calendarreader64.exe
1. First Change
Original Security Descriptor:
D:P(A;OICI;KA;;;S-1-5-21-130038992-1272150033-662139138-xxxxx)(A;OICI;KA;;;SY)(A;OICI;KA;;;BA)(A;OICI;KR;;;RC)(A;OICI;KR;;;AC)(A;OICI;KR;;;S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681)
NT AUTHORITY\RESTRICTED: AccessAllowed (ExecuteKey, ListDirectory, ReadExtendedAttributes, ReadPermissions, WriteExtendedAttributes),
NT AUTHORITY\SYSTEM: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
BUILTIN\Administrators: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
ITEOS\username: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey)…}
New Security Descriptor:
D:AI(A;ID;KR;;;BU)(A;CIIOID;GR;;;BU)(A;ID;KA;;;BA)(A;CIIOID;GA;;;BA)(A;ID;KA;;;SY)(A;CIIOID;GA;;;SY)(A;CIIOID;GA;;;CO)(A;ID;KR;;;AC)(A;CIIOID;GR;;;AC)(A;ID;KR;;;S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681)(A;CIIOID;GR;;;S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681)
BUILTIN\Users: AccessAllowed Inherited (ExecuteKey, ListDirectory, ReadExtendedAttributes, ReadPermissions, WriteExtendedAttributes),
BUILTIN\Administrators: AccessAllowed Inherited (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
NT AUTHORITY\SYSTEM: AccessAllowed Inherited (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES: AccessAllowed Inherited (ExecuteKey, ListDirectory, ReadExtendedAttributes, ReadPermissions, WriteExtendedAttributes)…}
2. Second change
Original Security Descriptor:
D:(A;ID;KR;;;BU)(A;CIIOID;GR;;;BU)(A;ID;KA;;;BA)(A;CIIOID;GA;;;BA)(A;ID;KA;;;SY)(A;CIIOID;GA;;;SY)(A;CIIOID;GA;;;CO)(A;ID;KR;;;AC)(A;CIIOID;GR;;;AC)(A;ID;KR;;;S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681)(A;CIIOID;GR;;;S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681)
Same as above…
New Security Descriptor:
D:PAI(A;OICI;KA;;;S-1-5-21-130038992-1272150033-662139138-xxxxx)(A;OICI;KA;;;SY)(A;OICI;KA;;;BA)(A;OICI;KR;;;RC)
NT AUTHORITY\RESTRICTED: AccessAllowed (ExecuteKey, ListDirectory, ReadExtendedAttributes, ReadPermissions, WriteExtendedAttributes), NT AUTHORITY\SYSTEM: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
BUILTIN\Administrators: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey),
ITEOS\username: AccessAllowed (ChangePermissions, CreateDirectories, Delete, ExecuteKey, FullControl, GenericExecute, GenericWrite, ListDirectory, ReadExtendedAttributes, ReadPermissions, TakeOwnership, Traverse, WriteData, WriteExtendedAttributes, WriteKey)}
————————————–
After decoding those changes with PowerShell and the command line ConvertFrom-SddlString, we can clearly see that :
In the Second change the process calendarreader64.exe remove the permissions for NT AUTHORITY\SYSTEM & ALL APPLICATION PACKAGES
Can you help us to have contact with Barco to resolved ASAP this issue ?
Thank you
Thanks,
We have the problem, on computers each week at least one or two, we have 100 computers .
The root cause is due to installing the clickshare_app , but why the bug don’t appears on the next reboot ?
there are Windows update too ? and when you shut the computer it didnot shut really . . .
on june 22nd of 2022 Barco had made a new barco app
but not sure it correct the root cause
Hello again,
Here is a small script that we push through Intune to disable the function: Calendar Integration in ClickShare to resolve the issue without uninstall ClickShare!
https://www.barco.com/fr/support/knowledge-base/2087-enable-or-disable-the-clickshare-desktop-apps-calendar-integration
Script:
$key = Get-ItemProperty -Path “HKCU:\SOFTWARE\Barco\ClickShare Client”
If ($key.CalendarIntegration -ne “false”)
{
Stop-process -name clickshare_native
Set-ItemProperty -Path “HKCU:\SOFTWARE\Barco\ClickShare Client” -name “CalendarIntegration” -Value “false”
Start-Process C:\ClickShareApp\ClickShare\clickshare_native.exe
}
Thanx… added it to the blog so people who don’t want to uninstall the clickshare app or want to be sure it wont happen again (even after updating)
Thanks for the detailed solution. One concern is the screenshots are not in English, if in English then I guess it will be easier for more people around the globe 🙂
Hello,
we’ve updated the clickshare app to the newest version but we are still encountering the issue although the clickshare app is up 2 date. It seems that there is something else which is causing the issue. 🙁
At least the script fixed the issue within a few minutes now…
Hi… ClickShare is one of the apps that could be causing this… did you also disable the calender connection as I mentioned in the blog?
Hey,
we have this problems occuring randomly on some computers for a few weeks now.
In the beginning we fixed it like you describe it (old way) by simply deleting old profiles and setting up new ones.
Now we had a few cases where even that didn’t work, Startmenu was fixed till next restart and then broken over again.
I’ve looked into the explained new fix, but that didn’t help us at all. The permissions were always set rightfully on the computers. Also we don’t use ClickShare at all.
It seems like this is breaking something with credential management too, as our Users with this problem have trouble with auto-login in Teams. After setting up a new profile, I couldn’t add their MS365 Account (login window closes instantly after typing in e-mail) – Reinstalling all MS365 Apps (Click2Run) doesn’t help either, so the only fix for this cases was to reinstall Windows. So the Outlook API as a second trigger makes sense to me.
Anyone experiencing similar problems? This blog was one of the rare, relevant information I could find to this behaviour.
Yep, I noticed the same on a couple of devices…. it looks like the broken “Microsoft.AccountsControl” is causing it… i spend 2 hours troubleshooting 2, but at that point the customer needed his device so I send a remote wipe… hopefully we will have a problem device in the future
Hi there,
we also have this problem on dozens of workstations.
We can get the taskbar etc. fixed by working on HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
BUT: what is the solution for the O365 programs: for us neither Outlook, nor OneDrive work. For Teams you can sort of log out and in, which does the trick, but the other 2 applications remain dead.
Hi.Did you try the other powershell scripts fixes that need to be executed in the admin and user context to re-register the plugins? as the aadbroker plugin isn’t working anymore after the permissions were removed from the reg key you mentioned
Hello,
Here is answer received from MS support :
While this initially appeared to be an issue with the 3rd party app, it now appears to be Microsoft code (profapi.dll) which breaks the permissions thinking they need to be recovered. This may occur when an x32 third party process (like ClickShare) uses Office APIs on a machine where Office is deployed using Office ClickToRun, because of a bug in AppvIsvSubsystem32.dll registry hooks. In this case profapi.dll will start recovering the ACLs, but after a second failure it won’t write the All Application Packages ACLs, causing issues (crashes & registration failures) with packaged apps.
Bug record Bug 41322218: _RecoverUserShellFolderKeys fails to restore default permissions
So, i’ts related to a version of Office Click-to-run. And it makes sense since issues are occurring since moving to MS Apps 2202 Enterprise channel
Thanx for reply, will add this wonderfull news to the blog
Hi, do you have a link to this Microsoft article? I haven’t been able to find it by searching for “Bug 41322218”.
i have been actively working with Microsoft on this issue as we have 300+ machines a day breaking. and only have a hand full of users. with clickshare installed. It has been a painfull few months. I was just told today about the bug report finally being opened. i am concerned about how it might be deployed since this is a Click-to-run issue.
Hi,
We’ve reached out to Microsoft and they can’t locate a bug code like this. Can you tell me where I can locate this info?
How do you find this bug record?? Can we get a source please?
Came here from Google – left your website with another happy customer!
Awesome, just wanted to thank you 🙂
Thanks for sharing this! This cost our company a lot of money, hours & frustrations by our users.
I have had this issue now three times on my work computer: AAD joined, Office Click-and-run installed, NO ClickShare.
Sadly I was not able to fix the issue by re-assigning the registry permissions as the respected permissions were already there. The only thing for me that fixes it is re-create the local profile, but this is always a big pain because I need to re-configure every single app there is. Also the last time the issue repeated itself in a matter of hours!
Does anyone know if the issue will be fixed from Microsofts site?
Its odd that the issue is back within a couple of hours and the permissions are still correct… Are you 100% sure you are noticing those errors in the event log I was mentioning?
Great work thank you! We struggle with this problem a few Month already and the only workarround we had was Wipe or re-profiling! We normaly not using clickshare so the API used by some wierd app looks like the plausiblest way to mess with the key for us.
Hello, thank you so much for this post and all the details. Everything match here with our issue and the script works well to resolve. The only difference is that people don’t change there password to triggered the issue. We have different people everyday from different office which are concerned by this problem but we can’t find a same triggered to the problem. Do you know if microsoft published a fix for office or if there is a click to run version of office which fixed this issue? Thanks a lot for your work and to share everything with us , have a nice day