Adobe Acrobat Reader DC crashes on copying pdf content with not saved changes to another directory using PDDocCopyToFile method from Adobe plugin.

[Guest]

Currently custom adobe plugin should copy pdf content if pdf document was updated but not saved in Adobe Reader/Acrobat otherwise it continues using original file location. It was tested on different files. This works fine with almost all files except one.

From properties of this file I see that this is Adobe LiveCycle Forms 8.2 document with PDF Version 1.7 (Acrobat 8.x).

This file works fine with this plugin installed on Reader XI, Reader IX and Adobe Acrobat Pro DC. But when I use Adobe Acrobat Reader DC it crashes.

Source code:

ASInt32 docFlags = PDDocGetFlags(pdDoc);

if ((docFlags & PDDocNeedsSave) != 0) //check if document need to save

{

  IntPtr pTempFile = Marshal::StringToHGlobalAnsi(strTempFile);

  ASPathName asTempPath = ASFileSysCreatePathName(NULL, ASAtomFromString("Cstring"), pTempFile.ToPointer(), NULL);

  PDDocCopyParamsRec copyParams;

  memset(&copyParams, 0, sizeof(PDDocCopyParamsRec));

  copyParams.size = sizeof(PDDocCopyParamsRec);

  copyParams.fileSys = ASGetDefaultFileSys();

  copyParams.newPath = asTempPath;

  copyParams.saveChanges = true;

  PDDocCopyToFile(pdDoc, &copyParams); // <-- crashes here

  Marshal::FreeHGlobal(pTempFile);

  ASFileSysReleasePath(NULL, asTempPath);

}

In Adobe Acrobat Reader and Acrobat Pro DC this file is not possible to update (for Acrobat warning message appears, from Reader this file not editable) but docFlags are defined for this doc as need to save. This is not so bad if only plugin not crashes on line PDDocCopyToFile(pdDoc, &copyParams).

Also I noticed that if I change copyParams.saveChanges to false it works fine but it copies file without not saved changes. This is unacceptable.

Exception message is "External component has thrown an exception." and type of exception - System.Runtime.InteropServices.SEHException.

Previously in plugin was used SDK older than 9 version, so I updated SDK to DC version - this didn't help. Then I used other available in downloads versions of SDK X and XI - the same result.

Is it a bug or I'm doing something wrong? Are the any workarounds? Are there any ideas?

Thank you.

[lrosenth]

I don’t see any error handling here – where are you DURING/HANDLER block?

[Test Screen Name]

The exception isn't an Acrobat exception. Indeed, System.Runtime.InteropServices.SEHException is a .net exception, and I wasn't aware that Acrobat uses .net anywhere. Does your plug-in use .net/Managed Code/C# anywhere? In any case you should indeed have Acrobat exception handling installed.

[Guest]

Plugin is created in C++/CLI project and a little deeper in the plugin we are using .Net code (C#). So yes, this is .Net exception but it is thrown within Adobe SDK API method PDDocCopyToFile.

There is a callback method on button click wrapped with try/catch block. Inside this callback method this chunk of code is executed.

Also I want to add that it was found that this crash is not reproducible on adobe version 15.008.20082 but on 15.023.20053 and 17.009.20044 it crashes.

"In any case you should indeed have Acrobat exception handling installed." Could you clarify what do you mean by that?

[Test Screen Name]

You should ALWAYS (not just when there is a problem) have Acrobat exception handling around all of your plug-in code. This is done using DURING ... HANDLER ... END_HANDLER blocks.  Then you can trap and report any exception raised by Acrobat, usually with an error message. An un-handled exception may cause bad problems as well as hard to diagnose errors.

[Guest]

Thank you. This handling produced some meaningful results.

Error message: This operation is not permitted.

Error code: 40.

Is it possible to find out more detais (why it was not permitted)? Why this approach works before latest version of Adobe Reader? Is there any better way to handle this situation rather than checking error code in HANDLER block? 

So is it fine in this situation that document contains PDDocNeedsSave flag?

[lrosenth]

Yes, you can dissect the error code using the APIs provided to find out exactly what type of error it was.

[Test Screen Name]

Does the crash happen in Acrobat? I wouldn't expect Reader to save, maybe it was a bug that was fixed.

[Guest]

Yes, this works fine with Acrobat DC. Acrobat plugin copies this document to defined location without any errors.

[Test Screen Name]

Sounds deliberate, then. A bug fix.

[lrosenth]

It looks like there is something about the file that Reader isn’t liking to permit you to save...