Question General Runtime Error? (1 Viewer)

[KACJR]

Greetings to the well of knowledge...

We have an MS Access front-end interface to an SQL Server 2014 DB. Our users access it via MS Access Runtime 2016. As the developer, I use full Access 2010 as we still have some individuals using 2010 runtime.

On occasion, a user will receive the error: "Execution of this application has stopped due to a run-time error. The application cannot continue and will be shut down."

When the user clicks OK, Access shuts down. Any attempt to launch the application after results in this error appearing on startup. The only fix is to have the user logoff and then log back on. This seems to "clear something", allowing the user to launch the application and continue working as if nothing ever happened.

This error happens randomly; it can't be pinned down to any one operation or function the user might be doing. I ask the user "what were you doing before the error happened". I reproduce his/her steps, hoping it will fail and I can debug it, but the operation works with no error.

It feels like I'm chasing a phantom.

Any thoughts from the experts out there?

Thanks,
Ken

 

[isladogs]

Can you please confirm whether users are sharing the same front end stored somewhere on the network or if they have their own copy of the front end stored on their own computer

 

[KACJR]

All users have their own local copy of the front end. The front end builds several local tables as part of its processing so a shared network copy would be dangerous.

 

[MarkK]

The only fix is to have the user logoff and then log back on.

Log off of what? The app has crashed here, so they are not logging off the app. So log back on to what? Windows? The domain?

Every unhandled error in a runtime version will crash the app. You are premature to say "this" error, because ALL unhandled errors will look the same. Without more information, I would not assume that all your crashes are caused by the same problem.

The best solution to this is to implement better error handling, and to not just MsgBox the user when an error happens, but record the error in a table so you can see it for yourself. Users, like witnesses at car accidents, almost always remember it incorrectly.

Yes, the runtime is a cheaper way to deploy multiple FEs, but troubleshooting, as your case shows, is harder. So you HAVE to implement better error handling in your code, or you are essentially blinded by your lack of a debugger. That information HAS to get back to you as a developer, what exactly is going wrong, or there is no way to fix it, or you are, as you are now, just guessing at the problem.

hth
Mark

 

[Cronk]

I follow Mark's suggestion of having error handling and recording error information in a table.


When I'm called to a site, I check the error log and can be proactive in addressing any issue that has been happening. Recording the procedure where the error has occurred and having the error description and number helps. Sometimes, I'll add line numbers at strategic points in a procedure and record them in error handling to narrow down a more obscure issue.

 

[isladogs]

Agree totally with both MarkK & Cronk.
All errors need to be both handled (to prevent crashes) and logged (to help with fixing issues)

For one of my larger apps, I also setup a system whereby any errors triggered an automatic email giving details of who/what/where/when.
Obviously I had to get permission from my clients to do this
The point was that I no longer had to rely on customers informing me of errors - it happened automatically with no user input required.
i.e. user / workstation / application version / Access version / error location, number & description
As a result, I knew instantly when errors had occurred and exactly what had happened ...

This made a huge difference in problem solving and meant that, within a few weeks, all errors were fixed.
Mind you those first few weeks were very busy fixing issues arising ....

 

[Mark_]

When the user clicks OK, Access shuts down. Any attempt to launch the application after results in this error appearing on startup. The only fix is to have the user logoff and then log back on. This seems to "clear something", allowing the user to launch the application and continue working as if nothing ever happened.

By log off and log on, is this in effect rebooting the machine or simply re-establishing their network connection? Symptom is a resource is being allocated that doesn't want to be allocated for... reason. Say an activeX control that has run out of memory or the like.

Can you please let us know if you have any issues with network connectivity also?

The other's have already gone into "You really need to put in error handling" so I'm hoping you are already working on that. In the mean time, this gives you an idea what you may want to check FIRST. Seldom should you get this from "Open report", but you can get it from "ActiveX control on report".

 

[The_Doc_Man]

There is A CHANCE (not at all a certainty) that you can find this error from the user's machine and learn something useful from the log.

1. Tell your users to be on the lookout for this crash event. When it happens, have them IMMEDIATELY note the computer's time of day (system time), which is usually in the lower right corner of the screen, on the far right end of the task bar. (Or if they have a clock "gadget" on screen, even better! But not required.) It is enough, though, that this time would be to the minute. Have them write it down.

2. ON THE USER'S SYSTEM: Click from Start >> Control Panel >> Administrative Tools >> Event Viewer. From there, look on the "navigation" panel to the left to see what logs you can examine.

Look at the system logs and the application logs. Some systems will even have a separate Office Apps log. It won't hurt to check each log that is available, but I'm betting on something being in one of System, Application, or (if you have it) Office logs. Since these logs are sorted by date/time, you should be able to quickly find the time of day of the crash in one of them. You should know right away whether anything is there because of the fact that everything is time-sorted.

See if ANYTHING got logged. In particular, look for MSACCESS.EXE as the logging program. I believe the runtime has that name when you don't have a full version of Access on the machine.

It is technically incorrect to say that the crash was caused by unhandled error. There is actually no such thing in Windows. What IS correct is to say that it was an error not handled by your App or by Access itself. Which means it got passed to the O/S. If it had NOT been passed to the O/S, there would have been no task crash. The task crash (actually, an I/O rundown caused by a process forced exit) occurs because the error caused a "stack unwind" operation that unwound all the way out of your process and into Windows itself. (Your process, believe it or not, is a subroutine of the Windows process scheduler.)

When the error unwinds past your process, the Windows logging takes over, which is why I think there is a CHANCE that there will be an event log for that time and date in one of the logs. And if so, you can perhaps find an error code that might be meaningful.

 

[MarkK]

I also setup a system whereby any errors triggered an automatic email giving details of who/what/where/when.

I did this too, but I just coded it to periodically email me the whole errors table
Mark