Access crashing

[CedarTree]

Hello,

Getting unexplained crashes when selecting different records on a table (subform) that then drives other subforms via master/child relationships. This seems to be a recent new error and it doesn't stop the code... just closes Access. When selecting a record, it does open PDFs in a webcontrol, but that's about it in terms of complexity - otherwise not a very complex database. I notice that the crashes are MUCH more likely when selecting records quickly right after each other. It's as if Access can't keep up. How can I determine the cause of the crash? Other suggestions?

 

[CedarTree]

I should add the database is linked to a back-end database. Is it possible a back-end database corruption can impact a front-end database?

 

[CedarTree]

This is what the Windows Event log gives me...

Faulting application name: MSACCESS.EXE, version: 15.0.5023.1000, time stamp: 0x5aa77fd6
Faulting module name: MSACCESS.EXE, version: 15.0.5023.1000, time stamp: 0x5aa77fd6
Exception code: 0xc0000005
Fault offset: 0x00216095
Faulting process id: 0x23ac
Faulting application start time: 0x01d46fc5bb4b2b80
Faulting application path: C:\Program Files\Microsoft Office 15\Root\Office15\MSACCESS.EXE
Faulting module path: C:\Program Files\Microsoft Office 15\Root\Office15\MSACCESS.EXE
Report Id: b2100020-dbba-11e8-8081-f48c50c63f58

 

[CJ_London]

I don't follow the fault codes you have but in answer to

Is it possible a back-end database corruption can impact a front-end database?

- definitely since the corruption can impact your parent/child relationships among other things.

but it is also possible your code (even if a few lines) can cause the issue if it doesn't handle all potential situations such as null values, numbers out of range, etc

When selecting a record, it does open PDFs in a webcontrol

don't know what this means.

Suggest step through your code, checking values as you go - and compact/repair both front and backend just in case of corruption.

Is this a multi user system? if so, does each user have their own copy of the front end? if not, and they share a common one on the server, it is most likely a corruption of the front end - front ends should not be shared, to do so will result in corruption.

 

[CedarTree]

So back-end is not corrupted (I created it from scratch). And each user has their own copy of the FrontEnd. Can't make sense of the random crashing.

Webcontrol is a control that allows me to show PDFs within Access (or any webpage really).

 

[JHB]

To find out if it is definitely the WEB-control that cause the problem, you could create a copy of the form and delete the WEB-control.
How do you get the content for the WEB-control, by code or ..?

 

[CedarTree]

Thanks. Webcontrol URL is developed by code (just a file name) and the controlsource of the webcontrol is set. It works generally. When I switch between files, it works fine but then randomly crashes. As if it's a memory leak somewhere in Access.

 

[The_Doc_Man]

The first thing to note in the exception data is that this is a pure Access situation. This is shown by

Faulting module name: MSACCESS.EXE, version: 15.0.5023.1000, time stamp: 0x5aa77fd6

and by

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

plus the other two lines also containing MSACCESS.EXE, the "proper" name of the thing that incurred the fault. That means that this probably did not occur in a referenced library but rather was in Access itself. Your mention of the Webcontrol thing as though it is an add-in is material in that if there is a problem with Webcontrol, access didn't get there - because the faulting module was Access, not whatever .DLL holds the control to which you referred.

The Exception code of 0xc0000005 tells us this is an access violation (little-a in this case) meaning that the hardware tried to access a memory location that either was not there or you didn't have permission to touch that memory. It is a crash because it is a C-class violation (0xc000... as opposed to 0x8000...). Hexadecimal "C" in that context has the "Severe" bit turned on, which means you cannot continue from the trap event that triggered this.

Webcontrol is a control that allows me to show PDFs within Access (or any webpage really).

The descriptions I have found online regarding the exception code point to any of several possible sources. Two of the most common are faulty updates and low physical memory. A third is Data Execution Protection, which stops hackers from overwriting buffers and then executing them. So here are a couple of things to determine:

1. When this happens, WHEN does it happen? On the first attempt to use the Webcontrol or in a later use in a single session?

2. Does the code EVER work for those folks seeing the failure?

3. If this is in a form, have you tried replacing the Webcontrol with a hyperlink followed by your code opening (following) the hyperlink? (Look up Application.Followhyperlink)

4. After an error, it would be good to verify that the reference that gave you Webcontrol is still valid.

5. I don't know what Webcontrol does. Is there a chance it is an Active-X control? (In which case such controls often need special setup on first execution.)

6. One of the possible causes is low memory. You said this:

I notice that the crashes are MUCH more likely when selecting records quickly right after each other. It's as if Access can't keep up.

IF you have a "Windows Gadget" that shows memory usage, it might be a good idea to have that running when trying this behavior to see if something is consuming memory. Otherwise you would have to use the Resource Monitor to discover that one.

 

[JHB]

..Webcontrol URL is developed by code (just a file name) and the controlsource of the webcontrol is set...

Could we see that code?
Sometimes, especially in queries with heavy data load, MS-Access execute the code faster as the query is able to deliver the data, (then an error occur), in such cases a DoEvents helps. You could try to place a DoEvents just before and after the code line where you set the control source of the WEB-control.