Access 2016 accde "DoCmd.OutputTo acOutputReport, , acFormatPDF..." crashes after 10 minutes

Just to give everybody a heads up. Our company also discovered this problem with exporting to PDF in .accdr files and Access 2016. We went through the same troubleshooting steps as everybody else in this thread and discovered the issue was new in 2016 and the export process worked fine in Access 2010/2013. We created a test database from scratch to test not only the function, but also using the pdf export button in the Access 2016 ribbon. In both instances Access crashes after its been open a certain amount of time. As another posted indicated, the MSI and earlier click to run versions seem to crash much earlier while the more recent builds appear to crash after Access has been open between 1-2 hours.

We opened a paid support ticket with Microsoft Support and after going through several levels of support over the course of several weeks, the Office VBA Support team confirmed this is a bug and it will be fixed at some point in the future. The support fee we paid was refunded because it was a confirmed bug.

We were told an ETA could not be provided, but we were told it was confirmed to be a bug and was added to their database of bugs to fix.

This issue has been driving me crazy ever since we upgraded our MS Access database to 2016 runtime *.accde

We have the full version of Access which we run in runtime to protect the code and structure of the database from accident tampering.

After moving to Access 2016 this started happening, and is affecting all our users. Please fix this Microsoft.

Today, I did one last experiment on Office365 Version of Access2016 (16.0.7341.2035) to confirm 80 minutes or more is problematic --> that is, results in app crash upon command to "store report as pdf". 

Today's experiment is a simpler experiment than those I've done in the past, which were carried out programmatically.  For instance, my March 29, 2016 posting indicates that my experiments have involved a built in pause (of varied duration) followed by a call to a method that stores a report as a pdf.   Experiments of those kinds were great for determining precisely when things go unstable, to the second.  Yet, they are somewhat artificial and add additional variables (a call to the Sleep method for instance).  They leave one wondering:  is there some artifact of the experiment responsible for app crash???  To be specific, does this artifact cause an 80 minute threshold for "Office365 version of Access2016" and an "8 minute threshold for MSI Volume License Access2016"???

With these concerns in mind, I devised a simpler experiment, that instead simulates the experience of a user who opens the application, and from time to time presses a button to store some report as a pdf.  Clearly, said user might become frustrated if, after the application is open for 80 minutes, the command results in app crash!

So, today I opened the Access database in runtime mode, and every 10 minutes, pressed a button to store the report as a pdf to C:\Temp.  As I neared the 80 minute threshold, I issued the command more frequently than once every 10 minutes for the sake of added clarity.  I found that, though I could still "store as a pdf" at 78 minutes after opening the app, and 79 minutes after, and 79.5 minutes after, I couldn't at 80 minutes after opening the app!  At 80 minutes, the pushing of the button results in app Crash with no pdf created!  These findings are consistent with test done programmatically (described in my March 9, 2017 post).

To sum, I have learned that this 80 minute threshold is real.  It is not an artifact of my former testing method. 

To further sum, we have an 8 minute threshold for Access2016 (MSI, Volume License, 16.0.4456.1003) and an  80 minute threshold for Office365/Access2016 (16.0.7341.2035). 

Please note that, in all cases, Access was 32bit and installed on Win10 (64bit).

That is all.

Wow, Alex, these are very interesting findings. So they didn't fix the issue in Office 365 after all, they just made it less severe.

Does anyone reading this have a *Premier* MS Support contract and wants to open a case with MS? (As we all know, "Professional Support" is useless for getting bugs fixed.)

Best regards

Heinrich

Thank you Kirk.  This is a very unusual bug.    Happens for Office365 version of Access2016 as well as MSI Volume License of Access2016.  However, the "time limit" required for a crash to occur differs!  8 minutes for MSI, 80 minutes for Office365.  Yes, the crash threshold differs by a factor of 10!  Please read on.

Concerning MSI Volume License of Access2016 (16.0.4456.1003, tests done March 2017)

We consistently experience App Crash 100% of the time if the MSI Volume License copy of Access2016 has been open for 8 minutes or more when the command to 'store as pdf' is given.  Please see my 29th March, 2016 posting for a description of how testing is done (Version  16.0.4456.1003, MSI Volume License).  The calendar year 2016 testing was redone in March of 2017 with the same result.  Please note that 7 minutes and 59 seconds is fine.  No App crash.   Pdf is stored fine. 

Concerning Office365 Version of Access2016 (16.0.7341.2035, tests done March 2017).

We consistently experience App Crash 100% of the time if the Office365 version of Access2016 has been open for 80 minutes or more when the command to 'store as pdf' is given.  Testing done in same way as described in my 29th March, 2016 posting.  Please note that 79 minutes and 59 seconds if fine. No App crash.  Pdf is stored fine. This is very repeatable.  Three times, success when command given at 79 minutes and 59 seconds. Three times app crash when command given at 80 minutes and 00 seconds!  Please note that I explored a time range from 20 seconds to 300 minutes, binary search style.  24 trials were run.

Question:

Why would there be an order of magnitude difference in the time threshold :  8  versus 80 minutes?  I am puzzled!!!