NVDA does not work with Adobe reader DC 64 bit

[enessaribas]

Steps to reproduce:

1. download and install latest Adobe reader 64 bit
2. open a document in Adobe Reader

Actual behavior:

NVDA plays multiple error tones, and Adobe reader exits with no visible error. The following appears in log
ERROR - RPC process 10084 (Acrobat.exe) (14:56:39.824) - Dummy-1229 (4232):
Thread 8124, build\x86_64\remote\COMProxyRegistration.cpp, registerCOMProxy, 182:
Unable to register interface IAccessibleHyperlink with proxy stub IAccessible2Proxy.dll, code -2147023156

Expected behavior:

Adobe reader does not exit and NVDA reads document.

System configuration

NVDA installed/portable/running from source:

installed

NVDA version:

alpha-23897,7bd9e8b1

Windows version:

windows 10 21h1

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

Adobe reader DC

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

If NVDA add-ons are disabled, is your problem still occurring?

yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

yes

[seanbudd]

Can confirm this with Adobe Reader DC 2021.007.20099. I've attached a log nvda.log with more detail on the crash.

[enessaribas]

Hi,
Please also note that the error message changes if you disable protected view and enhanced security. The same error is raised on 32 bit Adobe Reader with these enabled as well, however it does not crash.

[OzancanKaratas]

Acrobat Reader does not crash when NVDA is used in English, but crashes when NVDA language is set to Turkish. I don't know if this issue occurs in other languages.

[michaelDCurran]

Technical info:
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.
This however is not where the actual crash ends up happening. Rather the crash is pretty random, but sometimes in the Microsoft TSF framework, sometimes in focus handling for other UI frameworks. But from investigation it is very clear to me that it is the call to CoGetPSCLSID that starts the instabilities. This was found by disabling smaller and smaller parts of the nvdaHelperRemote code until getting to this line.
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.

One possible work around to this might be for NVDAHelper itself to hook CoGetPSCLSID, and in our implementation, return the CLSIDs we want registered. which then removes the need for us to specifically call CoGetPSCLSID and or CoRegisterPSCLSID ourselves. But this assumes that the COM framework will in deed call CoGetPSCLSID itself in order to look up proxystub CLSIDs. Which, it should, unless there is a lower-level function the framework uses internally.

[enessaribas]

Hi,
Is there a timeline on when this will get fixed? Adobe recently has begun upgrading 32 bit versions of reader to 64 bit automatically.

[michaelDCurran]

I investigated My idea of hooking CoGetPSClsid but it looks as though Windows does not internally call it itself to lookup the proxy stub CLSID.
The next idea is to check the process's token to see if it has its isAppContainer bit set. initial investigations seem to suggest that Adobe Reader does set this in its protected mode. I'll create a pr / try build soon.

[michaelDCurran]

The current recommendation to work around bugs in Adobe Reader is to specifically download and install Adobe Reader 32 bit from adobe.com (which today still exists). And also in Adobe Reader's preferences: disable Protected mode / app container, in the Security (enhanced) category.

[michaelDCurran]

Even when working around the app container bug, Adobe Reader 64 bit still crashes when NVDA starts to interact with pdf content.
This seems to be a bug in Adobe Reader where it is not correctly calling Addref on an IAccId interface it gives us via IServiceProvider::QueryService.
I have reported both of these bugs to Adobe and am currently working with their engineering team to get these further investigated and addressed.

[CyrilleB79]

Maybe it would be valuable to write something about it in the message announcing the release.

[michaelDCurran]

These bugs are certainly Adobe Reader's and are not caused by any changes in NVDA. I.e. NVDA 2021.2 and older would experience the same issue. We should certainly publish the work around recommendations somewhere easy to find at least though.

[enessaribas]

Hi Michael,
Please note that an ergent aspect of this bug is that Adobe has been autoupgrading versions to 64 bit. I had to do a reinstall because of this, and there is no way to stop this behavior that I know of.

[michaelDCurran]

I understand. I am doing all I can to get the bugs investigated and addressed in Adobe Reader. There is nothing we can currently do in NVDA at the moment.

[lukaszgo1]

I understand. I am doing all I can to get the bugs investigated and addressed in Adobe Reader. There is nothing we can currently do in NVDA at the moment.

Given that JAWS has (or at least had last time I checked)
no problems with accessing 64-bit versions of Adobe Reader it seems this can be worked around on the screen reader's side somehow. Obviously in the ideal situation these bugs should have been fixed by Adobe.

[lukaszgo1]

I've confirmed JAWS is not affected by these bugs in Acrobat.

[LeonarddeR]

What happens if we do not register the IAccessible2 proxy in Adobe Reader?

[LeonarddeR]

What happens if we do not register the IAccessible2 proxy in Adobe Reader?

O well, just tested it an it still crashes, though later in the process.

[bramd]

It seems timing matters with this bug. When I quit NVDA and use Narrator to open a PDF and start NVDA after that, it seems to work as expected. I wonder if other people in this thread can reproduce that?

[OzancanKaratas]

@bramd: You're right. Acrobat Reader crashed due to NVDA. I attached the log.

[puffybc]

I'm having the same issue with Adobe Acrobat DC. Getting exception code 0xc0000005. I changed the settings to read visible page, but that didn't help. (I work with lots of long pdf's so I typically make acrobat load the whole thing before reading).

[jmdaweb]

Hi,
I started experiencing this issue after upgrading to Windows 11. Acrobat opens while NVDA is running only if AppContainer security setting is disabled first using another screen reader. Otherwise, it crashes instantly.
In another computer running Windows 10 21H2, Acrobat works as expected, but NVDA displays some error messages in the log:

ERROR - RPC process 14864 (Acrobat.exe) (12:09:46.162) - Dummy-7812 (13456):
Thread 6008, build\x86_64\remote\COMProxyRegistration.cpp, registerCOMProxy, 182:
Unable to register interface ISimpleDOMNode with proxy stub ISimpleDOM.dll, code -2147023156

These messages also disappear after disabling appContainer.
In case language is important, all programs are configured in spanish. I'm using NVDA 2021.3.1 and Adobe Acrobat DC x64, automatically upgraded from 32-bit reader.
Regards.

[enessaribas]

hi,
The problem for me is it still will not open documents even if I disable the protected view and the container setting. Only thing it changes is to change the error message in log. The end result is the same.

[enessaribas]

hi,
The label on this issue states info is required. Is there any more info I need to provide about this to diagnose further?

[michaelDCurran]

Adobe has now communicated that they are addressing the issue on their side.

But here is further technical information which was found during investigation from me.

1. 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. There are two major problems with this:
   A. 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. This should never be done with a COM interface. 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.
   B. the interface was changed without changing its IID. 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. This could crash the AT, Acrobat, or even worse, the internal Windows RPC system. A COM interface should never be changed after it is published. Rather, a new one should be created, and the old one should be deprecated if necessary.
2. Now that the ID from IAccID is 64 bit, it is impossible to pass it to MSAA's accchild method on the root IAccessible for the document, in order to fetch a descendant object with the given ID. According to MSAA documentation on child IDs, accChild only can take a 32 bit (VT_I4) child ID. Thus either it is impossible now to use the ID, or in the worst case, the AT can crash Acrobat by passing it an ID truncated from 64 bit to 32 bit. As it looks as though Adobe internally treats the ID as a raw memory address, truncating to 32 bit simply yields an invalid address. Crash!

[michaelDCurran]

@enessaribas I've now removed needsInfo and replaced it with needsExternalFix. Adobe has all the information, and has communicated that they will fix it on their end. I will update the issue when I know more.

[enessaribas]

Could Adobe possibly stop automatically upgrading the version from 32 bit to 64 bit on systems with NVDA? There is no way to turn off this behavior, and I have had to manually uninstall and reinstall reader twice so far.

[XLTechie]

Not likely, but you can stop it from updating itself, apparently. From a very brief Google search on "keep adobe reader from automatically updating": 1. Simultaneously press Windows + R keys to open run command box. 2. In run command box, type: services. ... 3. Double click to open "Adobe Acrobat Update Service" properties (AdobeARMservice). 4. Set the Startup type to Disabled.

[ABuffEr]

4. Set the Startup type to Disabled.

5. Stop the service via context menu, before it's too late 🙂

[seanbudd]

I am no longer experiencing this issue with the latest Adobe reader and NVDA 2022.beta3.

Is anyone still experiencing this issue with the latest Adobe reader? Would you be able to test #13852?