We have Adobe DC Pro 2015 installed on many computers, but this issue only happens on one computer running Windows 7 x64.
When trying to print from Dynamics GP to Adobe PDF, it frequently freezes Dynamics GP entirely. The program must be forcibly exited and restarted. Adobe DC Pro 2015 has been reinstalled to no effect. No other program is used as frequently as Dynamics GP on the computer in question, so I can't tell the user to test hundreds of individual print jobs using different programs.
Dynamics GP support (Aptean) has spent a lot of time with this user, including installing CutePDF for printing (which worked without issue), but was unable to find any problems with Dynamics GP and how it interacts with printing to Adobe PDF. They have exhausted their troubleshooting and have told us the issue is with Adobe in some way.
I can't find a way to ask Adobe directly for help, since all attempts are redirected to this forum. Can anybody help?
I’ve now first looked into what Dynamics GP is. As it is npot a standard of the shelf program that many users will use, I think it would be worth explaining what the software is. What I have found is “Microsoft Dynamics GP”, an accounting program.
Now to the problem:
My first question is: Do the other computers also run this Dynamics GP program or is this the only machine with this program?
If it is not the only machine and the other machines are working fine, it may be in connection with hardware defects or the user profile has a problem. It would anyhow be a solution to try a second machine. If that works fine it may be more useful just to switch the computers.
If however you suspect a bug either in Dynamics GP or in the Acrobat Printing subsystem:
Printing to the Acrobat printer works like printing to any other printer from the applications point of view. As the interaction is geared through the Windows API, the application has even no idea if the printer is a virtual one, physically attached to the computer or a networked printing system as I have at work, where I print to the server and fetch my prints at any location with my identifyer. For this to work, the Windows API has to shield the user program from the printing system. This means : there is no interaction between the application and the printer.
It may now be, that for some reason unknown to me, Dynamics GP uses undocumented API calls to access the printer directly. If that happens, it may be that the PDF-print subsystem does not react as expected and Dynamics GP stalls.
A solution path to this would be:
I've exhausted all other options, so I reset the user's domain local profile. The jury's still out on whether this will work; I'll reply back after a few days and after a week with results to let people know whether or not this was successful.
cool! I hope the jury will give you full points!
Copy link to clipboard
Resetting (deleting and recreating) the user's domain local profile seems to have fixed this issue. Our user was able to perform the actions in Microsoft Dynamics GP 2015 that usually lead to "print to Adobe PDF" crashing the program.
Thanks for the help.