This blog will be, again about some nasty Store Apps issues!. In the conclusion of my last blog, I mentioned the fact that I was looking into some Start menu and the OneDrive/ Outlook connection issues that were occurring.
https://call4cloud.nl/2022/06/the-company-portal-and-the-city-of-a-thousand-missing-frameworks
1. The issue
I guess I don’t need to mention that nasty 2022-05 update again, which broke the installations from the MS Store, but when I looked at the first time I noticed this Store issue (15-02-2022), I saw that 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 that 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 broke! 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 to recreate the profile. 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 includes the Store fix.
3. Troubleshooting the issue
If we don’t want to recreate the profile and go through all the hassle of resyncing OneDrive, etc., we also have another option to fix it. As always, I also looked for 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? We have a lot of them!
When you wonder 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 with PowerShell
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 permission 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” permissions configured and 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
$objSID = New-Object System.Security.Principal.SecurityIdentifier ("S-1-15-2-1")
$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])
$user = $objUser.Value
$Packages = $user.Split("\")
$packages = $packages[1]
#$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"}
Please note: When running this script on a local device, you could run into some errors as I have noticed that sometimes all permissions are gone. If this is the case, please run it in the System context (Psexec) or deploy the script in Intune so it will run as system!
After we ensure the permissions are all good, let’s see if we have any luck. 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 its 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!
Another Possibility
Another possibility would be to use deploy it all in one PowerShell script. It misses some of the fixes but apparently, people were using it and it seemed to work pretty fast.
$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.BrokerPlugin5. Fixing it with an Intune Wipe
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 can 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.
UPDATE 17-01-2023
ClickShare released an update… which should improve the One-Click-Join experience to ensure the ClickShare Calendar Reader is reading the default account. Guess what happened? All devices end up with a broken Start menu and Broken Office 365 Apps
7. 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 to experience the issue”
8. Microsoft ProfApi.dll
UPDATE 23-09-2022 UnOfficial 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) that 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, it’s 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
Many people asked me where that Bug record came from and why Microsoft support doesn’t know about it. I guess that one is pretty easy, as it is an internal bug number, and Microsoft support isn’t aware of it.
That Internal bug record number could lead you to believe that Microsoft is working on a fix. Shall I spoil a secret? Yes, they do! Microsoft is working on “something” with this KB number: Windows10.0-KB900259-x64
By the looks of it, it is scheduled to be released in March. So keep checking the release notes!
9. Disable Calendar Integration
Barco is advising us to disable the Calendar Integration in the ClickShare settings to prevent the Startmenu and all the other Appx Packages from breaking apart.
If you want to automate it, you could write a PowerShell script to disable this setting in the HKCU
But why write a PowerShell script when you could just use the ADMX files to do the same? Isn’t that a nicer solution? In my humble opinion, it is! If you haven’t read my blog about how to do it yourself, feel free to read it first
Build your own ADMX templates and deploy them into Intune (call4cloud.nl)
If you are not interested in it…. also fine. Download this zip file and upload the ADMX to your tenant. After uploading the ADMX you can configure a new Imported Administrative template (Preview) and configure the calendar integration!
Conclusion
All those Store Apps issues we have been experiencing over the last few months are awful. Luckily, most of the issues can be resolved. This blog will explain how to 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.
try this
function Get-CurrentUserSID {
[CmdletBinding()]
param(
)
Add-Type -AssemblyName System.DirectoryServices.AccountManagement
return ([System.DirectoryServices.AccountManagement.UserPrincipal]::Current).SID.Value
}
Then create the $SID variable
$SID=Get-CurrentUserSID
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.
How did you manage to repair SSO?
We can’t get it working. Teams worked for a while, after Office Repair it stopped. We can’t even set up a new Outlook Profile
Did you also run that part in the user session I mention: Get-AppXPackage… to register those app packages again? So not only fixing the permissions but also registering the packages again..(user session)
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
we got exactly the same problem as you, sometime using the powershell profide by microsoft on barco site helped but not all the time. …. atm the only thing who worked most of the time is creating a new profile from scratch but it’s very painfull for proxy support ….
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
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?
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.
How do you find this bug record?? Can we get a source please?
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
So crossing our fingers.. we received a private testing fix today. We are being told it will be a windows patch, and not an office patch. The Patch displays Watermarked and can not be shared. but i am hoping to get it installed on a number of machines ASAP that seem to have the most issues.
Hi… I am going to Send you an email 🙂
Hello, do you have any news about this FIX, i have tried to work with microsoft support on this, but its just inpossible to do something with them, they don’t take the global problem but the office part on one hand and the start menu on the other hand , not the same teams… just a lost of time. They don’t accept also for security reason to go to check this webpage to see the global description of the problem… I’m really exhausted to try with them, hopefully we have the script which work so well when we have the problem. We are 2000 and we have 1 or two cases by week. Sometimes people have juste the start menu issue and sometimes both (start menu and office).. Waiting for your feedback, thanks
Just updated the blog… needed to get approval to share some more information about it. I am in contact with MS and they are aware of this issue …
Hello, any news about the KB Windows10.0-KB900259-x64 ? 🙂 Thanks
Do you know if there is already a patch out there? I have been looking for the KB/updates but can’t find much info about it. We have computers where Clickshare was trigering the issue but recently ran into computers that don’t have it installed and yet have the issue.
Hi… nope … untill know there is not an official released Microsoft fix/kb out there but looking at the internal kb number.. I assume they are working on it
Thank you for this great post.
I had the problem today with 2 machines. Clickshare Desktop is not installed on these devices but the error is the same. Machines are patched with the latest January patches. This might be a bigger problem then Clickshare. I hope Microsoft fixes this asap, but my expectations are low.
Thank you for this! Solved our problem with Start Menu/OneDrive/Outlook.
I read somewhere that the affected models are only HP, is that correct?
Cheers.
Thank you for sharing! You saved our life or at least our week! ClickShare was the problem for us. Our Start Menu and Search was not working. The folder Cortana in the profile folder was in loop (delete and create).
Renamed registry MuiCache and fixed permissions on registry User Shell Folder fixed it.. but it needs to remove ClickShare or you can use the one fixed.
Hi… so cortana was malfunctioning after the fix, you also needed to clear the Computer\HKEY_USERS\SID\Software\Classes\Local Settings\MuiCache ? What kind of weird issue did it gave?
MS knowledge it now (20.01.2023)
https://www.bleepingcomputer.com/news/microsoft/microsoft-investigates-bug-behind-unresponsive-windows-start-menu/
Hehehe those parts mentioned on bleeping computer are the ones I mentioned in this blog 🙂 …
I had this issue, a view days before Barcoo and MS start talking about it and after getting the right details, I could find your article what was very helpful. Just want to say thanks!
The root cause seems to be OneDrive Insider update on my side. This bug occur few hours after OneDrive try to update. With ClickShare App or not.
Mmm.. that should be weird as Microsoft also added the clickshare issue on their startmenu troubleshooting faq.
Where do you add the -ForceApplicationShutdown part??
I was just told part of this fix is in the new office 365 updates. versions greater than 16.0.16227.20280. Release notes do not incude this information.
The OS part of the fix is still being worked on.
i can say that i have seen an improvement with the parts related to the security of the registry keys, on machines that have been testing the office fix.
but we are still seeing issues related to the user shell folders being changed
I appreciate all the write up, but this does not solve the issue for me. This is the 4th time this has happened since March, 2023 and fortunately, I am the only one affected in my org. I am also traveling on site to several locations and really can’t reset the computer in a hotel. I read somewhere else that a network card driver update caused issues with a setting. I updated Dell drives the night prior and went to bed. The next day my computer could not log into the Office apps. My network card driver does not have the setting listed in the other article though.
My details are pretty much what was reported above but my case must be different in that I am not using ClickShare. or TrendMicro. I may be the only one in my org who updates Dell drivers though. At this point I will do a fresh start when I get home and restore data. It is not something anyone one of us replying to this thread has not done 100 times -kind of like mowing the lawn. Sucks for those that have end users affected
Thank you for the nice write-up Rudy.
It looks like the OS fix is finally here
https://support.microsoft.com/en-us/topic/june-27-2023-kb5027293-os-build-19045-3155-preview-1c50b938-6a65-4e7e-9fdd-967f391c846f
This update addresses an issue that affects HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders. You can now set and maintain the correct default permissions for this directory path. When the permissions are wrong, Start menu, search, and Azure Active Directory (Azure AD) authentication fails.