We develop an MFC application that allows users to view PDFs from within it. We do this by creating an MFC modal window in the application, then hosting an instance of one of our objects that subclasses the Microsoft CHtmlView class. To display the PDF, we get path to the file and call the inherited "CHtmlView::Navigate2()" method.
There has been no issue with this until recently, where some users are seeing the entire application crash occasionally when trying to view a PDF.
NOTE: Adobe Reader XI (11.20.17) is installed.
I had the user create a dump file using debug diagnostics, and it looks like there is an exception being thrown in an AcroPDF.dll thread, due to a call in the MakeAccessible.api plugin having a read access violation at a very low memory location:
Unhandled exception at 0x5F126E1D (MakeAccessible.api) in dump_file_name_removed.dmp: 0xC0000005: Access violation reading location 0x00000018.
If there is a handler for this exception, the program may be safely continued.
And the call stack exhibits symptoms like the heap might be corrupted, because we're seeing calls to some of our methods within the AcroPDF.dll thread. (Methods that we defined, but we ourselves never call into)
Call stack looks like this:
MakeAccessible.api!5f126e1d() Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for MakeAccessible.api]
MakeAccessible.api!5f0ff41e() Unknown
OUR METHOD WHICH IS NEVER CALLED Line 1194 C++
MakeAccessible.api!5f0ef20c() Unknown
MakeAccessible.api!5f0efabb() Unknown
MakeAccessible.api!5f0dfe84() Unknown
PDDom.api!6252cd21() Unknown
PDDom.api!6254654e() Unknown
PDDom.api!62546584() Unknown
PDDom.api!62546aa2() Unknown
PDDom.api!62546ad4() Unknown
PDDom.api!62546b62() Unknown
PDDom.api!6254645d() Unknown
AcroRd32.dll!5d0b93e2() Unknown
AcroRd32.dll!5d0fa846() Unknown
uiautomationcore.dll!HookBasedServerConnectionManager::HookCallback(void *,unsigned long,void * *,unsigned long *,void * *) Unknown
user32.dll!_NtUserKillTimer@8 () Unknown
AcroRd32.dll!5db0d38f() Unknown
AcroRd32.dll!5d0fa573() Unknown
AcroRd32.dll!5d08eddc() Unknown
user32.dll!_InternalCallWinProc@20 () Unknown
user32.dll!_UserCallWinProcCheckWow@32 () Unknown
user32.dll!_DispatchMessageWorker@8 () Unknown
user32.dll!_DispatchMessageW@4 () Unknown
AcroRd32.dll!5d0f8e14() Unknown
AcroRd32.dll!5d0f8c68() Unknown
AcroRd32.dll!5d0853fb() Unknown
AcroRd32.dll!5d0855a6() Unknown
AcroPDF.dll!0b8bad43() Unknown
OUR METHOD Line 498 C++
ntdll.dll!_ZwTestAlert@0 () Unknown
ntdll.dll!_ZwContinue@8 () Unknown
ntdll.dll!_LdrInitializeThunk@8 () Unknown
I've tried tracking down anything in the logic around displaying PDFs that might point to bad memory management and might cause heap corruption and I couldn't find anything.
Furthermore, I was later informed that this doesn't only happen when trying to view PDFs within our client, but also happens occasionally when trying view a PDF within Adobe reader independently.
Which leads me to believe there might be an issue with one of the adobe libraries.
Additionally, the user uninstalled reader and has been testing it for about a month now with a third party PDF viewer and hasn't seen a crash when trying to view PDFs yet.
Lastly, there are a couple other users who have Adober Reader DC installed (Win 7 and Win 10) who can view the first PDF successfully, but see the client crash after closing it and trying to view a 2nd one. In the dump file, they are also getting an Access violation at a very low memory location, but this time it's in the AcroPDFImpl.dll thread. (Coincidentally it works fine for them in Adobe Reader XI )
Unfortunately, I have not been able to create any of these issues locally with Adobe Reader XI installed, or on a VM where I have Adobe Reader DC installed . So I'm hoping someone here might have some more insight?