COM Registration Fixing tool doesn't work

[tspivey]

Steps to reproduce:

1. Install MathPlayer.
2. Uninstall MathPlayer.
3. Read the task bar and notice it says unknown.
4. Run the COM Registration Fixing tool.
5. Read the task bar again and it still says unknown.

Actual behavior:

The tool doesn't fix NVDA's accessibility support.

Expected behavior:

The tool fixes NVDA's accessibility support.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

Version: alpha-16405,19bb21c2

Windows version:

Version 1809 (OS Build 17763.134)

Name and version of other software in use when reproducing the issue:

Other information about your system:

Other questions

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA?

No

[LeonarddeR]

What happens if you execute all the tweaks in #2807 (comment) by hand?

[Adriani90]

cc: @jcsteh, @michaelDCurran

[tspivey]

There are a lot of them. I haven't tried all of them, but here's a summary of some things I did try.

Testing with a win7 VM, this fixes it, note that this doesn't work on my real win10 machine, and requires an NVDA restart:
c:\windows\syswow64\regsvr32 c:\windows\syswow64\oleacc.dll

On my win10 machine, this python console command fixes it if NVDA is run as administrator, but I forgot exactly what it does. It seems to return an error, but I'm not sure how to turn the int back into a HRESULT. However, it doesn't work on the win7 VM:
import comtypes,ctypes;p=comtypes.typeinfo.LoadTypeLibEx(r"c:\windows\syswow64\oleacc.dll");ctypes.windll.oleaut32.RegisterTypeLib(p, ur"c:\windows\syswow64\oleacc.dll", None)

On the win10 machine, Registering c:\windows\syswow64\oleacc.dll and c:\windows\syswow64\oleaut32.dll didn't fix it.
I also tried the ones in system32, along with actxprxy.dll. No luck.

[LeonarddeR]

Just to make sure, did you try OneCoreCommonProxyStub.dll on Windows 10 as well?

[tspivey]

@LeonarddeR Tried that. I didn't realize you linked to a comment, let's try these.

0. Install/uninstall MathPlayer.
1. First reg file - now my start button doesn't say unknown, but that might've been because of the reboot since I didn't test beforehand.
2. Second reg file - no luck.
3. Started an admin cmd. Hey, my Firefox with the instructions still reads, maybe I'm in different bug territory now.
4. Entered both commands, restarted NVDA. No task bar yet.
5. Did that, no taskbar yet.
6. I'm on win10, and this module isn't there.
7. Same as 6.
8. The module "c:\windows\system32\OneCoreCommonProxyStub.dll" was loaded but the entry-point DllRegisterServer was not found.
9. The module "c:\windows\syswow64\OneCoreCommonProxyStub.dll" was loaded but the entry-point DllRegisterServer was not found.

Next steps:

1. Run COM registration fixing tool, nothing, I figured it would at least get it back to saying unknown.
2. Magic python console incantation - got my system back.
3. Don't bother with MathPlayer because I'd have to reboot again and just run the first reg file, my start button doesn't say unknown anymore. I guess that breaks it rather than fixes it.
4. Python console again - back to a working system.

[LeonarddeR]

Hmm, so oleaut32.RegisterTypeLib does work why registering it with resvr32 does not, is that correct?

[tspivey]

Yes, at least on win10.

[jcsteh]

That RegisterTypeLib call registers the oleacc typelib. The thing is that on Windows 10, oleacc is not supposed to use the typelib marshaler; it should marshal using oleacc.dll. That's one of the tasks the tool performs: it sets the correct marshaler. I could understand why things would be broken if you run the COM reg tool and don't reboot, since Explorer will still be using the wrong marshaler. However, I would have thought that running the tool and then rebooting would fix things, since now, everything is using oleacc.dll as the marshaler. (It's worth noting that we don't ask the user to reboot, so if that is indeed required, we should fix that.) Technically, you could prove this by just restarting Explorer rather than rebooting.

I guess it's possible that something somewhere still uses the typelib even when oleacc.dll is registered as the marshaler (instead of the typelib marshaler). It certainly wouldn't hurt to add this RegisterTypeLib call; a broken typelib entry is a bad thing regardless.

[jcsteh]

Actually, you'd have to restart both Explorer and NVDA if you didn't want to reboot, since NVDA will probably be using the wrong marshaler too at that point.

[jcsteh]

I wonder whether IDispatch still needs the typelib registered correctly, even if oleacc.dll is used as the marshaler. I guess that would make some sense. NVDA shouldn't be using IDispatch directly, but it could still feasibly be causing weirdness.

[michaelDCurran]

@jcsteh do you know if there are separate typelib registrations required for 64 and 32 bit? Or is running it from within NVDA (32 bit) enough?

[jcsteh]

I'm not certain. This StackOverflow thread suggests they can be different. On the flip side, that same thread also gives me the impression that you can register a 64 bit typelib even in a 32 bit process.

[michaelDCurran]

@tspivey: I want to get this into the COM registration fixing tool for 2019.1, however, with my copy of mathplayer that I have, on my system uninstalling it does not cause any of the problems you mention, though I do admit I have seen the problem a few years back. I thought that Design Science had addressed the issue in their installer.
If you could share your specific copy of the mathplayer installer with me, so that I can reproduce the issue, that would be helpful.

[tspivey]

https://www.dropbox.com/s/mxq3nwo6th4ln15/MathPlayerSetup.exe?dl=1

[lukaszgo1]

@michaelDCurran Have you made any progress here?

[Adriani90]

@tspivey does this occur only in case of mathplayer? Or did you see this behavior with installing and uninstalling other programs as well?
Just for the reference: which programs do you have installed on your PC? Is there something like skype for business for example?
Skype for business is also causing some issues related to unregistered COM DLLs.

[tspivey]

No, I haven't personally seen it with anything other than mathplayer. But since I've had to help people fix it, it's still a problem.

[josephsl]

Hi,

Update: we had a user report that things in web browsers were not read, and the workaround noted by Tyler did work. I think, for 2020.1, the workaround line should be attempted unless we can fine a more refined solution for 2020.2.

Thanks.

[cary-rowen]

This is still confusing, and I can still reproduce this issue using 2020.4.
Is there any news about this?
@michaelDCurran
@josephsl

[jcsteh]

Aside from the typelib issue here, it seems the COM registration tool isn't applying the registry patch correctly, but I don't know why.

STR (on a 64 bit system):

1. Press Windows+r, type regedit, press enter.
2. In the address bar, enter:
   Computer\HKEY_CLASSES_ROOT\Interface\{618736E0-3C3D-11CF-810C-00AA00389B71}\ProxyStubClsid32
3. Change the (Default) value to:
   {00020424-0000-0000-C000-000000000046}
4. NVDA menu -> Tools -> Run COM Registration Fixing tool. Accept the warning, allow administrator access, press OK.
5. Refresh registry editor by pressing f5.
   • Expected: The (Default) value should be {03022430-ABC4-11D0-BDE2-00AA001A1953} as specified in the NVDA oleaccProxy.reg patch.
   • Actual: The (Default) value is {00020424-0000-0000-C000-000000000046}

What's odd is that if I rename the .reg file, an error gets logged, so the function is definitely running. And if I manually run:
c:\windows\regedit.exe /s "C:\Program Files (x86)\NVDA\COMRegistrationFixes\oleaccProxy.reg"
it updates the registry as expected.

[jcsteh]

Oh! I think I understand what's going wrong here. In 32 bit apps, Windows WOW64 redirects certain file system paths. So, when you run c:\windows\regedit.exe, this gets redirected transparently to c:\windows\syswow64\regedit.exe. The same happens for regsvr32. This means this tool has never worked for the 64 bit registry, only the 32 bit registry.

WOW64 recognises c:\windows\sysnative as a special path which redirects to the native (64 bit) system directory. However, regedit.exe isn't in system, so this may not work for that. If not, we'll have to disable WOW64 file system redirection before our subprocess calls and re-enable it again afterward.

[jcsteh]

This thread confirms that indeed you can't do sysnative\regedit.exe. However, you can apparently do sysnative\regedt32.exe, which apparently redirects to the 64 bit regedit. What a mess.

[jooyoungseo]

NVDA keeps saying "unknown" in my Firefox, and the "Run COM Registration Fixing tool" does not take any effect. I use Windows 10 64-bit. I know this issue was mentioned in another thread and the solutions were suggested; however, would you mind sharing step-by-step instructions here for Windows 10 64-bit users? I tried to fix the issue on my end following the suggested comments in other threads, but none of them worked.

[jcsteh]

Is this recent; i.e. only with the Firefox 89 update? If so, this is due to a bug in Firefox. Please update to Firefox 89.0.1, which should fix this. If this isn't recent (i.e. it happens with older versions of Firefox too), this is due to COM registration issues.

[jooyoungseo]

@jcsteh, mine was 89, so have just updated to 89.0.1 following your suggestion. Still, I have the same issue. I also tried with the COM fixing tool and did reboot. No success.

[jcsteh]

Please try the following: 1. Press Windows+r to open the run dialog. 2. Paste the following: %ProgramFiles(x86)%\nvda\COMRegistrationFixes\oleaccProxy.reg 3. Allow admin access, then allow registry editor to make the changes. 4. Reboot.

[jooyoungseo]

Unfortunately, no success. Still, "unknown".

[XLTechie]

@jooyoungseo Please try this try-build.

You said in your other comment, that you "executed the installer with admin privilege".
I'm not sure exactly what you meant there, but please run the installer as a normal NVDA process would be run. It will ask for admin privilege if you install it (though you don't have to install it, you can run it as a temporary copy), and it will ask for admin privilege when you try to run the COM Registration Fixing Tool. But other than that it should run with normal privileges.

[XLTechie]

@tspivey, @cary-rowen.
Can you two replicate any of the problems that you had, and can you test the most recent try-build of #12560, to see if it can rectify them?
If you do, please post here your results, along with the bitness of your system, and Windows version (7, 10).
I need to know if more needs to be done there.
Note: don't try the MathPlayer test unless you don't rely on Firefox. See my results of that below on a W10 64-bit system.

[cary-rowen]

Hello, this is the log I executed on Win1021H1. It has a dll registration error.
Nvda-log.txt
@XLTechie

[XLTechie]

@LeonarddeR @jcsteh
I decided to try @tspivey's mathPlayer test from the start of this thread.
I installed his buggy MathPlayer, and then uninstalled it.
The result, is that my Firefox, upon restart, was left saying "unknown" for anything that was actually part of a page, though the Firefox elements themselves work fine (menues, address bar).
I switched over to Narrator, and ran the try-build from #12560 as a temporary copy, and the CRFT it contains.
No errors reported from the CRFT run, but no fix of the "unknown", either. I did seem to get my taskbar back at that step, I believe.

Next, I switched back to latest Alpha, and tried running @tspivey's typeLib code (modified to work in py3, and also modified to let the system choose the dll it wanted (I used system32 as the path not syswow64)).
The end result was the following return code:
-2147319780
And no apparent fix.
I tried again with his original paths, but still no joy. Lastly i tried with Sysnative (the 64-bit versions), and got nothing but the same int returned.
I am now limited to Chromium browsers (Brave) on this machine.

I have to say I am at a bit of a loss at this point. @michaelDCurran I don't think this is the fault of the PR, I think it still does a better job than the old tool. I tested the old tool in alpha, and it did no better. So I don't think this should hold up #12560, but there's obviously more to do.

---

While in Firefox, here is the dev info for an "unknown":

Developer info for navigator object:
name: None
role: ROLE_UNKNOWN
roleText: None
states: 
isFocusable: False
hasFocus: False
Python object: <NVDAObjects.IAccessible.IAccessible object at 0x08B21BD0>
Python class mro: (<class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'documentBase.TextContainerObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <class 'garbageHandler.TrackedObject'>, <class 'object'>)
description: None
location: None
value: None
appModule: <'appModuleHandler' (appName 'firefox', process ID 9460) at address 6fa80d0>
appModule.productName: 'Firefox'
appModule.productVersion: '89.0.1'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 852830
windowClassName: 'MozillaWindowClass'
windowControlID: 0
windowStyle: 399441920
extendedWindowStyle: 256
windowThreadID: 3468
windowText: 'Refactored the COM Registration Fixing Tool code to remove bugs and for better UX by XLTechie · Pull Request #12355 · nvaccess/nvda — Mozilla Firefox'
displayText: exception: cannot unpack non-iterable NoneType object
IAccessibleObject: <POINTER(IAccessible) ptr=0xa6fd8a0 at 8af46c0>
IAccessibleChildID: -117441110
IAccessible event parameters: windowHandle=852830, objectID=-4, childID=-117441110
IAccessible accName: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accRole: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accState: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accDescription: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
IAccessible accValue: exception: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))

---

Lastly, I have a desktop shortcut key setup to taskkill Firefox.
While in Firefox, if I press it, a COM NULL pointer is accessed:

IO - speech.speech.speak (05:40:37.369) - MainThread (12456):
Speaking ['Taskbar', CancellableSpeech (still valid)]
IO - speech.speech.speak (05:40:37.529) - MainThread (12456):
Speaking ['Firefox killer', 'window', CancellableSpeech (still valid)]
DEBUGWARNING - NVDAObjects.__call__ (05:40:37.578) - Dummy-1 (11528):
Invalid NVDAObject: no windowHandle
Traceback (most recent call last):
  File "NVDAObjects\__init__.pyc", line 83, in __call__
  File "NVDAObjects\UIA\__init__.pyc", line 1122, in __init__
NVDAObjects.InvalidNVDAObject: no windowHandle
DEBUGWARNING - NVDAObjects.__call__ (05:40:37.580) - Dummy-1 (11528):
Invalid NVDAObject: no windowHandle
Traceback (most recent call last):
  File "NVDAObjects\__init__.pyc", line 83, in __call__
  File "NVDAObjects\UIA\__init__.pyc", line 1122, in __init__
NVDAObjects.InvalidNVDAObject: no windowHandle
DEBUGWARNING - NVDAObjects.__call__ (05:40:37.583) - Dummy-1 (11528):
Invalid NVDAObject: no windowHandle
Traceback (most recent call last):
  File "NVDAObjects\__init__.pyc", line 83, in __call__
  File "NVDAObjects\UIA\__init__.pyc", line 1122, in __init__
NVDAObjects.InvalidNVDAObject: no windowHandle
DEBUGWARNING - NVDAObjects.__call__ (05:40:37.585) - Dummy-1 (11528):
Invalid NVDAObject: no windowHandle
Traceback (most recent call last):
  File "NVDAObjects\__init__.pyc", line 83, in __call__
  File "NVDAObjects\UIA\__init__.pyc", line 1122, in __init__
NVDAObjects.InvalidNVDAObject: no windowHandle
DEBUGWARNING - NVDAObjects.__call__ (05:40:37.588) - Dummy-1 (11528):
Invalid NVDAObject: no windowHandle
Traceback (most recent call last):
  File "NVDAObjects\__init__.pyc", line 83, in __call__
  File "NVDAObjects\UIA\__init__.pyc", line 1122, in __init__
NVDAObjects.InvalidNVDAObject: no windowHandle
DEBUGWARNING - NVDAObjects.__call__ (05:40:37.590) - Dummy-1 (11528):
Invalid NVDAObject: no windowHandle
Traceback (most recent call last):
  File "NVDAObjects\__init__.pyc", line 83, in __call__
  File "NVDAObjects\UIA\__init__.pyc", line 1122, in __init__
NVDAObjects.InvalidNVDAObject: no windowHandle
DEBUGWARNING - NVDAObjects.__call__ (05:40:37.593) - Dummy-1 (11528):
Invalid NVDAObject: no windowHandle
Traceback (most recent call last):
  File "NVDAObjects\__init__.pyc", line 83, in __call__
  File "NVDAObjects\UIA\__init__.pyc", line 1122, in __init__
NVDAObjects.InvalidNVDAObject: no windowHandle
DEBUGWARNING - NVDAObjects.__call__ (05:40:37.594) - Dummy-1 (11528):
Invalid NVDAObject: no windowHandle
Traceback (most recent call last):
  File "NVDAObjects\__init__.pyc", line 83, in __call__
  File "NVDAObjects\UIA\__init__.pyc", line 1122, in __init__
NVDAObjects.InvalidNVDAObject: no windowHandle
DEBUGWARNING - NVDAObjects.__call__ (05:40:37.596) - Dummy-1 (11528):
Invalid NVDAObject: no windowHandle
Traceback (most recent call last):
  File "NVDAObjects\__init__.pyc", line 83, in __call__
  File "NVDAObjects\UIA\__init__.pyc", line 1122, in __init__
NVDAObjects.InvalidNVDAObject: no windowHandle
DEBUGWARNING - NVDAObjects.__call__ (05:40:37.597) - Dummy-1 (11528):
Invalid NVDAObject: no windowHandle
Traceback (most recent call last):
  File "NVDAObjects\__init__.pyc", line 83, in __call__
  File "NVDAObjects\UIA\__init__.pyc", line 1122, in __init__
NVDAObjects.InvalidNVDAObject: no windowHandle
ERROR - UIAUtils._isImprovedConhostTextRangeAvailable (05:40:37.607) - MainThread (12456):
Traceback (most recent call last):
  File "UIAUtils.pyc", line 329, in _isImprovedConhostTextRangeAvailable
  File "comtypesMonkeyPatches.pyc", line 27, in __call__
ValueError: NULL COM pointer access
DEBUGWARNING - NVDAObjects.UIA.UIA._prefetchUIACacheForPropertyIDs (05:40:37.617) - MainThread (12456):
IUIAutomationElement.buildUpdatedCache failed given IDs of {30019, 30086, 30022, 30025, 30155, 30036, 30070, 30103, 30008, 30009, 30010, 30046, 30079}
DEBUGWARNING - eventHandler.executeEvent (05:40:37.623) - MainThread (12456):
error executing event: gainFocus on <NVDAObjects.Dynamic_WinConsoleUIAEditableTextWithAutoSelectDetectionUIA object at 0x08AFF270> with extra args of {}
Traceback (most recent call last):
  File "eventHandler.pyc", line 246, in executeEvent
  File "eventHandler.pyc", line 96, in __init__
  File "eventHandler.pyc", line 105, in next
  File "NVDAObjects\behaviors.pyc", line 354, in event_gainFocus
  File "NVDAObjects\behaviors.pyc", line 187, in event_gainFocus
  File "NVDAObjects\UIA\__init__.pyc", line 1141, in event_gainFocus
  File "NVDAObjects\__init__.pyc", line 1137, in event_gainFocus
  File "NVDAObjects\__init__.pyc", line 1005, in reportFocus
  File "speech\speech.pyc", line 538, in speakObject
  File "speech\speech.pyc", line 568, in getObjectSpeech
  File "baseObject.pyc", line 42, in __get__
  File "baseObject.pyc", line 146, in _getPropertyViaCache
  File "NVDAObjects\__init__.pyc", line 1368, in _get__hasNavigableText
  File "baseObject.pyc", line 42, in __get__
  File "baseObject.pyc", line 146, in _getPropertyViaCache
  File "NVDAObjects\UIA\__init__.pyc", line 1421, in _get_states
  File "NVDAObjects\UIA\__init__.pyc", line 838, in _getUIACacheablePropertyValue
  File "comtypesMonkeyPatches.pyc", line 27, in __call__
_ctypes.COMError: (-2147220991, 'An event was unable to invoke any of the subscribers', (None, None, None, 0, None))
DEBUG - appModuleHandler.cleanup (05:40:37.649) - MainThread (12456):
application firefox closed
DEBUG - appModuleHandler.cleanup (05:40:37.649) - MainThread (12456):
application taskkill closed
DEBUG - appModuleHandler.cleanup (05:40:37.649) - MainThread (12456):
application conhost closed
IO - speech.speech.speak (05:40:37.657) - MainThread (12456):
Speaking ['Taskbar', CancellableSpeech (still valid)]
IO - inputCore.InputManager.executeGesture (05:40:40.135) - winInputHook (5204):

[XLTechie]

@cary-rowen It looks like you downloaded an earlier build. Try this link.

[jooyoungseo]

@XLTechie, no luck -- still having "unknown" controls in Firefox instead of actual content although the new test build has been successfully installed. The "COM Registration Fixing tool" still does not work.

Microsoft Windows Version

Version 20H2 (OS Build 19042.1052) 64 bit

[jooyoungseo]

Also tried with JAWS 2021 "/type repair" tool, but no success.

[michaelDCurran]

@XLTechie On Windows 10 64 bit build 21390 I installed and then uninstalled the Mapthplayer linked in this issue. As expected my Firefox started saying unknown everywhere. I then ran the COM registration fixing tool from the latest try build of your branch, and restarted NvDA, and Firefox started working perfectly again.
Are you using Firefox 32 bit or 64 bit? Did you restart NVDA and or your system after running the COM registration fixing tool?

[michaelDCurran]

No sorry I spoke too soon. It fixed the Library (download history) Window, and any existing open tabs still work, but all new tabs and windows are broken. However, Chrome is not broken, thus I think it may have something to do with Firefox's inter-process proxying code. There may be another interface from the MSAA typelibrary we need to correct its COM marshaller for.

[jooyoungseo]

FYI, of course, I restarted my system after the NVDA snapshot installation. Plus, rebooted after applying the "COM Registration Fixing tool." I am using 64 bit Firefox (v89.0.1). No success.

[Mary5958]

Does it work in troubleshoot mode (previously safe mode)? If so then try changing the theme in Firefox to something else than the default one. I did to Firefox Alpenglow and got it working still in version 89.0 this way, but in 89.01 it already works fine here with default settings. Maybe completely uninstalling Firefox along with related data and installing again would also help.

[ABuffEr]

It fixed the Library (download history) Window, and any existing open tabs still work, but all new tabs and windows are broken. However, Chrome is not broken, thus I think it may have something to do with Firefox's inter-process proxying code.

I saw exactly the same situation over a PC of a (not advanced) user I assisted remotely, after running various fixes manually. I'm following discussion with great interest.

[XLTechie]

@michaelDCurran @jcsteh @LeonarddeR
I have installed mathPlayer again, which of course fixes the Firefox problem.
Here is a registry diff between non-working (before install) and working (after install) states.
registry diff.txt

I am not sure what I'm looking for here. I have tried variations of this on a couple systems, including a diff between a working system, then an install and remove of MathPlayer. Unfortunately, Firefox updated and Windows Security updated, while I was doing it, even though I had WIFI off until near the end to test Firefox.
As a result, the diff there had over a hundred thousand lines listed, between added, removed, and changed keys.
I didn't think that was useful, so went back to this original system, and got the diff above.

[XLTechie]

@Mary5958 Unfortunately, there are other apps which are effected by this. For example, regshot, the program I used to make that registry diff, has menus which stop working after MathPlayer is uninstalled. At least on one system, Notepad wouldn't read properly.

[jooyoungseo]

Very interestingly, my Firefox works again after installing MathPlayer.

[XLTechie]

Very interestingly, my Firefox works again after installing MathPlayer.

Yes. MathPlayer is very aggressive in its uninstallation, and takes something with it that it shouldn't. When it is installed, it doesn't assume that something to be there, so it installs it, thus resolving the problem. Trying to figure out what that something is (presumably a registry key that registers a particular interface) is what is underway now.

[michaelDCurran]

Here is another try build for people to test: https://ci.appveyor.com/api/buildjobs/04lnhv7snv1fe12l/artifacts/output%2Fnvda_snapshot_try-oleaccProxyFix-23189%2C2ac08400.exe
Please install the broken MathPlayer. Then uninstall it. Confirm that Mozilla Firefox now only says unknown in its documents.
then run the COM registration fixing tool in this try build and restart NVDa / firefox, or better, reboot.
Then confirm that Firefox again works.

This is based on pr #12560 but adds an extra change to the oleaccProxy.reg file, namely that it deletes the TypeLib subkey from the IAccessible interface key. This was never initially done as that file changed the proxyClsid32 value to point directly to oleacc.dll rather than the automation typelib marshaller, thus Windows would never have a reason to look at the TypeLib subkey (whether it was correct or not). But it seems that Firefox specifically looks at this subkey or at very least tries to get the IAccessible type library and fails, as it points to the removed Mathplayer type library.

I'm mostly interested in this being tested on windows 7. I have confirmed this works okay on Windows 10.

[XLTechie]

@michaelDCurran a couple things.

1. It didn't happen the first time, but after I removed MathPlayer the second time from Win 10 20H2, it took out accessibility for Brave as well as Firefox.
   With that in mind, I checked on the 1909 system I have, and Chrome was also giving me "unknowns", after only one removal of MathPlayer.

2. The tool works with this change in Windows 10 as you said, but only after a reboot. I think I should add a "please reboot now" emphatic warning to the exit dialog.

3. Should we verify the value of this key is bad before just blowing it away?

4. Edit: Disregard what was here before; it was an error caused by trying to use a try (unsigned) build to access an administrative console, which can't be done. The console access happens when we run reg.exe as an administrator.

[michaelDCurran]

That TypeLib key does not exist at all on default installs of Windows 10, and I'm assuming Windows 7 either, and is only put there by MathPlayer, as the IAccessible interface is incorrectly included in their type library, and therefore registered like that when mathPlayer is installed. So, I don't believe there really is a valid value for that key anyway.