Random MS Access crashes when idle

Question

We have a custom MS Access application with linked SQL Tables that has been developed over the last 15 or so years. We recently upgraded the application to be 64 bit (VBA7) compatible. Both before the upgrade and after, the applicaiton would crash at random. It seems to have increased in frequency however for some users since the upgrade.

The application crashes when left idle, or inactive for a random length period. Some users can trigger a crash by locking and unlocking their PC. On most occasions however it crashes when a user switches to another application, and when they switch back to MS Access, it crashes. For one user, this occurs every 30 minutes, but for myself it only occurs if I leave the application unused for at least a few hours.

The application is distribited as an mde file and each user has a local copy on their C:\

Database version: MS Access 2002-2003 format 

All PCs are Windows 10 64-bit with Office 365 installation

Faulting application name: MSACCESS.EXE, version: 16.0.11901.20176, time stamp: 0x5d3baa73

Faulting module name: MSACCESS.EXE, version: 16.0.11901.20176, time stamp: 0x5d3baa73

Exception code: 0xc0000005

Fault offset: 0x000000000020f469

Faulting process ID: 0x9de4

Faulting application start time: 0x01d556352e77345b

Faulting application path: C:\Program Files\Microsoft Office\Root\Office16\MSACCESS.EXE

Faulting module path: C:\Program Files\Microsoft Office\Root\Office16\MSACCESS.EXE

Report ID: 9ac488a0-25fe-45e7-bf2a-ba97c17c56e4

Faulting package full name:

Faulting package-relative application ID: 

References:

Answer 1

It looks like Forms is used for clipboard methods, is there an alternate method for "PutInClipboard"?

Answer 2

Thanks Tom,

I've changed the application to ACCDB, and no luck, still the same crashes - Still, we will continue in this format.

Option Explicit is used on ever module.

From the tone of your reply, the answer is likely that this is a very old application written over 15 years by multiple programmers so the best bang for buch here would be to go through the application and ensure I don't need to use Forms, Active X, and CDO at the least. Would that be fair as the first place to start to resolve the crashes?

Cheers,

Paul

Answer 3

If this was my project, knowing how exceedingly rare it is to need Forms reference (after all, Access *is* a forms package; this is like adding Lotus123 reference to Excel), I would export all objects to text and search for usage of those items. I would want to understand why they are needed, and consider replacing them.

I would look at what ADO is doing for me while I already have DAO, for the same reason as above.

I would question the use of CDO. It is from the Windows Server 2000 era. What is it doing for me that an Outlook reference can't? Or perhaps a 3rd party library like Redemption.

I would also inspect any use of CreateObject. I do not want to see both early and late binding.

Do you have Option Explicit at the top of every module?

Do all users regularly run Windows Updates and Office Updates?

Why are you still on MDB format which was replaced 12 years ago?

Answer 4

Hi Tom,

Thanks for the reply.

I am unable to remove ActiveX, when I do so the application will not compile. There are a number of recordsets declared as ADODB.Recordset

In addition, I am prevented from removing forms 2.0, see this image:

Also the application is still in 2002-2003 compatability as an MDB compiled into an MDE front-end.

By C:\ I just mean we store the front-end on the users local drive, the actual path is: C:\Users<windows user name>\Cornucopia\TheSource

Cheers,

Paul

Answer 5

Are all references in use? I would uncheck Forms 2.0 and ActiveX data objects, and compile again.

Is everyone using a compiled ACCDE front-end (FE)?

Did you literally mean c:? that is an unusual folder.

Is the FE in a Trusted Location?

Did you decompile the FE before creating a new ACCDE?