PDF XChange Forum

We are using the PDF Tools SDK 4 and have been for years now in production code in 64 bit. We have since migrated the application to a new server OS, Windows 2016 server, and now running it in the 64 bit process does not work properly. It worked properly in the 64 bit mode on the old Windows Server 2008 OS, so I am not sure why it will not work on the new OS.

It works fine in a 32 bit process in the new Windows Server 2016 OS, but we are getting the exception below when we attempt to run it in a 64-bit process.

System.AccessViolationException: 'Attempted to read or write protected memory. This is often an indication that other memory is corrupt.'

This exception occurs when we call “PDFXC_Funcs.PXC_AddEnhMetafile(pdf, metaFile.GetHenhmetafile(), out image);”.

We have the DLLImport defined as followed:


[DllImport("pxclib40")]
public static extern int PXC_AddEnhMetafile(int pdf, IntPtr metafile, out int image);

Can you shed any light on why we are receiving this exception?

I was directed to this forum by the official support team so I am a little confused as to why I wouldn't at least receive some type of response. Is there a way to escalate the issue? Thank you.

Hello Greg C,

Apologies for missing your original post!
I've just passed this forum topic to our devs who were working on the Tools SDK, and we will post again here as soon as I have nay feedback for you!

Regards,
Stefan

Thank you Stefan. Like I mentioned before, the code runs fine on the old Windows Server 2008, but not on the new Windows Server 2016.

Hello Greg C,
Can you provide a minimal sample application that reproduces this issue (along with the EMF file)?

Also can you please run the following command from Visual Studio Command Prompt: This command will modify the exe file to possibly workaround this issue.

Thank you. Using that EditBin command does make the sample I have work in 64-bit mode, but doesn't setting those values essentially make the 64-bit process operate much like a 32-bit process in the way of potential memory consumption (or lack thereof)?

Also, was that the suggested resolution to the issue or does that now give you guys the information you needed to make an actual fix where that will not be required? Please let me know.

doesn't setting those values essentially make the 64-bit process operate much like a 32-bit process in the way of potential memory consumption (or lack thereof)?

Yes, this will prevent your application from using memory addresses over 2 GB.

was that the suggested resolution to the issue or does that now give you guys the information you needed to make an actual fix where that will not be required?

You can use this for now as a quick workaround.

Can you provide us with a minimal sample application that reproduces this issue (along with the EMF file)?

Hi Roman, I have a sample that I have attached that exhibits the behavior. Please let me know what you find. Thank you.

The problem is with declarations of functions exported from the SDK.

For example Type int is 32-bit type, while for 64-bit configuration pdf and page arguments of this function should be 64-bits as they represent pointers to the SDK internal objects.

You should use IntPtr instead of int there.