OfficeBugs

I thought that I had posted another update here, but perhaps I fogot to submit it. One more final, final update: While this fix does work (it definitely revolves around the CapAuthz key, not the other HKEY_CLASSES_ROOT key), the fix is not really persistent on its own. Basically, as soon as you correct the permissions of the CapAuthz key, Office seems to automatically delete the whole SecurityManager key the next time you launch it. Office then continues to work just fine without this key, and nothing I do seems to cause the key to regenerate, however at some random point a few days or a week later, the key and subkeys seem to get recreated with the same corruption on CapAuthz as before. I struggled greatly with getting a group policy to automate this part - the policy would run, but for some reason would never correct the CapAuthz key. In the end, what I ended up getting to work was a policy that updated the permissions of the SecurityManager key and replace child permissions, in addition to a startup powershell script that recursively took ownership of the SecurityManager key and all sub keys. I can't tell if both were necessary or only one due to the fact that Office then deletes the key, but it appears to have worked, so I'm leaving it as-is until someone complains again.

I thought I'd make a final update here. This workaround appears to have worked. Basically, I just closed office programs and added full access permissions to each of these registry keys to domain admins, local admins, and the particular user. Office immediately started working normally again after that, I didn't have to repair it or even reboot the computer. I might attempt to create some sort of group policy that automatically grants "Domain Users" permissions to these particular keys, which should accomplish the same thing, though I haven't looked into what's involved in that yet - if I can pull that off, then it should automatically fix it even if the problem somehow re-triggers again. I haven't bothered to work out which of these three keys was the important one to correct, and I don't think I'm even going to try because it's not worth the effort. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\SecurityManager\CapAuthz HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\SecurityManager\CapAuthz HKEY_CLASSES_ROOT\Installer\Components\F1291BD604B86 0441AN89E60BDEE0F9C

I've not yet done that, though I have used PROCMON in the past. It's difficult because once I correct the problem temporarily, I don't have any computers to test with until they call in with a problem again. I think I may have had a bit of a breakthrough, but I haven't had a chance to test yet. On the PC that the SecurityManager key did not recreate on, I discovered that it actually looked like it existed under another Wow6432Node key, i.e. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\SecurityManager\CapAuthz Notably, this particular user at some point had the 32-bit version of Office installed, which I assume is why this key was being used, and this may be similar for others having the same problem. On the one PC that I did a full comprehensive scrub that seems to have been OK since, One of the things I did was remove the entire HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office key, which would have cleared the Wow6432Node key as well if it was in use, and upon reinstall it didn't throw any errors and it seemed to properly recreate the correct CapAuthz key in the end. In addition to this, one of the links you provided referenced that the equivalent fix for Office 2013 was to update permissions on this key: HKEY_CLASSES_ROOT\Installer\Components\F1291BD604B860441AN89E60BDEE0F9C This 2013 fix peaked my interest, because we actually had longstanding issues in the past with a different client where we have this specifically as a workaround - in their case, the primary issue was that using the "Send to > Mail recipient" option in the context menu would throw an error saying that Outlook is not the default mail client, though I do think there were some other issues associated with it. It was something weird in their environment specifically causing it, but we could never figure out what it was, so we just applied this fix whenever it popped up and then it would never happen to them again. It persisted long after moving on from Office 2013 and they're using Office 365 now, so it definitely can impact other versions of Office somehow. Going forward, if this pops up again, I'm going to attempt just updating the permissions on all three of these keys to see if that allows it to repair normally. I'm making the assumption that if I don't run into the error where it crashes and OSE.exe gets stuck running in the background, then it probably means that it has been permanently fixed. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\SecurityManager\CapAuthz HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\SecurityManager\CapAuthz HKEY_CLASSES_ROOT\Installer\Components\F1291BD604B860441AN89E60BDEE0F9C

I do believe we have Office updates enforced as well, however I will say that in every case, I check for updates afterward and always find that it says it's already up to date. I've just had this happen again to few more users. The only thing that seems to have happened is some unrelated HP software was updated through Windows update - I'm not sure if that's related whatsoever. One new thing that I've discovered is that they have a policy that forcibly disabled UAC. I don't know if it matters, but I have had cases in the past where some software does not like UAC being disabled. I have attempted the fix involving taking control of and deleting the "HKLM\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\SecurityManager" key. Prior to this, I discovered that the permissions were in fact corrupt on it, and underneath it the only thing that existed was an empty CapAuthz key, also with no permission. Prior to reinstalling Office, I deleted the SecurityManager key and then ran a quick repair. The quick repair did not fix anything, and the key was not regenerated. After this, I tried an online repair. Once again, an error was thrown at the end, OSE00000.exe was stuck running in the background, and the repair ended, leaving Office uninstalled. Prior to reinstalling, I rebooted the computer. I then installed Office 2019 again - this ended with the same error once again and OSE.exe being stuck running in the background, however Office did seem to otherwise successfully install. Office is now working once again, however upon checking the registry, I found that the SecurityManager key still was not recreated (and therefore no CapAuthz underneath it), so I really do not know what to make of that. I believe that this is all related and that this is inevitably going to break again so long as this behavior is still present. One thing to note is that OSE.exe / OSE00000.exe always has the time stamp of November 1, 2024, so obviously this file has been updated in the latest version. In the one case where I mass scrubbed every single possible remnant of Office from the computer, I do not believe that the install crashed at the end with OSE.exe being stuck, and that user has not reported any more problems since, so I guess a full comprehensive scrub may be necessary?

I'm experiencing the same exact problems (as well as the symptoms posted by bgrorud below) with one of my clients, though no reports from any other clients, even ones with similar environments. It seems to be random people, not necessarily across the board, and it seems to primarily impact Windows 10 users, though it happened to one user after upgrading to Windows 11, and in all case they're using the same Office 2019 Standard build, 16.0.10416.20007. I have found that a quick repair doesn't fix the problem, but fully uninstalling and reinstalling does. In all cases, attempting an online repair results in an error being thrown at the end that I've traced to an ose00000.exe program in C:\Windows\Temp getting stuck running in the background during the uninstall - the uninstall still seems to succeed, but the error ends the repair process prematurely and the ose00000.exe process has to be killed before Office can be reinstalled properly again. I have found that for the most part, people that I've repaired this way have been OK, though in a few cases the problem has randomly returned several days later with no obvious cause. In one case of recurrence, I fully scrubbed every possible remnant of Office from all associated folders and the registry, and before reinstalling I checked for Windows updates again, and it inexplicably tried to reinstall KB5046613 (i.e. the Win10 Cumulative update that was also releasd on November 12 alongside this Office update), despite it already being installed prior to the scrub. In that case, I hid the update to prevent it from trying to install again, though I do not know if this was necessary. In another case, this update was uninstalled and hidden after correcting, but a standalone security update then installed afterward that seemed to trigger the bug again. I've also had it reoccur for a user after upgrading to Windows 11 and then rolling back to Windows 10, as well as one case where it reoccured after upgrading to Windows 11. In at least one case, Office was reinstalled, everything was fine for a few days, but then it randomly broke again with no record of any updates having been installed or any other changes being made - I have no idea what triggered the bug to reoccur for them. We have a third-party patch management software that enforces silent updates of other non-Microsoft programs, but I noticed that it also includes .NET framework and .NET redist, which I believe also had security updates around the same time, so I have an unconfirmed suspicion that it's related - I excluded .NET programs from the patch management software afterward, just in case. There definitely seems to be some sort of association between the new Office build and new security patches for Windows - my theory at the moment is that installing any of these security updates somehow breaks the new build of Office, requiring it to be reinstalled to correct it, but because they're a client that pays for time, I don't have the freedom to do too much testing to verify any of my suspicions. All is stable at the moment, but I suspect that I'm going to have more users report problems again at some point. I should also add that this particular client has Windows updates enforced across the board, so they experienced this problem pretty much immediately when the new patches released and I've been dealing with it ever since. I've been reluctant to roll them back, as the majority of users have not been reporting any issues.