Essentially meaning that the AT client could be using one version of the interface, and Acrobat the other, and the methods / data types are incompatible. the interface was changed without changing its IID. Both the client and server must always agree on the exact types, no matter if the client and server do or don't differ in their bit size.ī. This should never be done with a COM interface. The argument type was changed within an ifdef for 64 bit, meaning that compiling the interface for 64 bit would yield a different binary interface to compiling with 32 bit. There are two major problems with this:Ī. Adobe's IAccID custom interface has been changed so that specifically on 64 bit builds, the ID argument is now 64 bit wide instead of 32 bit.Thus, refusing to install IAccessible2 into processes with the 'IsAppContainer' attribute has no other known side affects.Īdobe has now communicated that they are addressing the issue on their side.īut here is further technical information which was found during investigation from me. Note that Adobe Reader itself does not require IAccessible2 to function.Īlso, the 'IsAppContainer' is only set on very heavily sandboxed sitations, and is not the same as the app container that is used for Windows Desktop Bridge apps. NVDAHelper's IAccessible2 registration code now checks if the process token has the 'IsAppContainer' attribute, and of so refuses to install IAccessible2 support. The upshot is that If Adobe Reader is started when NVDA is running, many errors are written to NVDA's log, and Adobe Reader closes straight away.ĭescription of how this pull request fixes the issue: The further call to CoRegisterPSClsid fails, and then eventually the process completely crashes randomly in places such as TSF initialization. Specifically, the call to CoGetPSClsid seems to start making things unstable. There seems to be a bug however, either in Adobe Reader, the Windows OS, or NVDA (NV access and Adobe cannot be sure) that causes the Adobe Reader process to become unstable when NVDA tires to register IAccessible2. This ensures that insecure PDFs do not have a chance to affect the rest of the Operating System.īy default Adobe Reader is configured to enter its Protected mode on start-up, and to set the 'isAppContainer' attribute on its process token. Recent versions of Adobe Reader introduced a Protected Mode, where by the Adobe Acrobat process has less privileges and is sandboxed. Which, it should, unless there is a lower-level function the framework uses internally. But this assumes that the COM framework will in deed call CoGetPSCLSID itself in order to look up proxystub CLSIDs. which then removes the need for us to specifically call CoGetPSCLSID and or CoRegisterPSCLSID ourselves. One possible work around to this might be for NVDAHelper itself to hook CoGetPSCLSID, and in our implementation, return the CLSIDs we want registered. We know that the standard Windows CoGetPSCLSID function does not cause this instability in other apps, so it may be possible that Adobe is hooking in its own implementation for security reasons, I'm not sure yet. This was found by disabling smaller and smaller parts of the nvdaHelperRemote code until getting to this line. But from investigation it is very clear to me that it is the call to CoGetPSCLSID that starts the instabilities. Rather the crash is pretty random, but sometimes in the Microsoft TSF framework, sometimes in focus handling for other UI frameworks. This however is not where the actual crash ends up happening. It seams that the instability is caused by at least the first call to CoGetPSCLSID, on line 174 of nvdaHelper/remote/COMProxyRegistration.cpp when trying to get existing IAccessible2 interface to proxyStub mappings. Yes Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu? If NVDA add-ons are disabled, is your problem still occurring? Yes Have you tried any other versions of NVDA? If so, please report their behaviors. Windows 10 21h1 Name and version of other software in use when reproducing the issue:Īdobe reader DC Other information about your system: Other questions Does the issue still occur after restarting your computer? System configuration NVDA installed/portable/running from source: Unable to register interface IAccessibleHyperlink with proxy stub IAccessible2Proxy.dll, code -2147023156 Expected behavior:Īdobe reader does not exit and NVDA reads document. Thread 8124, build\x86_64\remote\COMProxyRegistration.cpp, registerCOMProxy, 182: NVDA plays multiple error tones, and Adobe reader exits with no visible error.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |