Access crash on start-up

[pdanes]

I have a database that is used by an entire department, daily. Recently, it has started crashing on startup. Not always, sometimes more than others, but it is getting steadily worse, seemingly as the entire department migrated to Windows 10 and Office 365. My lastest build seems to have fixed the sporadic nature - it now crashes very reliably.

It has been repeatedly decompiled, compact and repaired - no help. There is no code that is throwing errors, or deliberately closing anything. In fact, the database often opens nicely, splashes the start-up screen, closes that and goes to the main screen, where it sits for a few seconds, doing absolutely nothing - just waiting for the use to make a move. The VBA window confirms that nothing is running. Then, for no reason that I can see, with NO action from the user, not doing ANYTHING else on the machine, Access just quits.



It seems that if I 'catch' it quickly enough, by clicking on a button or in a text window, I can prevent it from quitting. Once it gets started doing something, this never happens - the app runs very nicely. But this crash on start-up is getting to be a problem, and I am at a loss as to what to even look at. It is difficult to debug code when there is no code running.

Can anyone suggest something I might try?

[isladogs]

Some questions to assist with troubleshooting:
Have you tried importing into a new blank database?
How does the VBA window confirm that nothing is running?
Does it crash if you use the shift bypass to disable all startup code?
Do you have an autoexec macro? If so, what does it do? What happens if you disable it e.g. by renaming as autoexex?
Does it still crash if you disable the startup form and go to the main menu?
What if you disable the main menu? Or disable its form load/open/activate/current/timer events?

[CJ_London]

From your description it sounds like you have not split the db and all users are using the same file. Is this the case?

[Emmanuel]

Are all users using the same office version?
Because these issues may occur if the database is accessed by different users who have different office versions.

Try setting up the same version of office on all client machines, preferably the office version used to develop the database.

[pdanes]

Some questions to assist with troubleshooting:
Have you tried importing into a new blank database?

Doing that now, as a last resort. I didn't want to, because of the sheer volume of stuff, including around 20 custom document properties, which I have to copy across by hand – the import dialog doesn't do them. I suppose I should write some code to do that.

How does the VBA window confirm that nothing is running?

The VBA window title bar contains the word 'running' when there is some code executing. That disappears and the entire app is idle, then suddenly quits for no apparent reason.

Does it crash if you use the shift bypass to disable all startup code?

No, it only crashes after the app starts executing.

Do you have an autoexec macro? If so, what does it do? What happens if you disable it e.g. by renaming as autoexex?

I do not have an autoexec macro. I have an auto-startup form, specified on the 'Current database' tab of the properties dialog.
It opens a form named 'Start', which opens a user-specific splash screen and does some prep work, like testing the app's version number against the version number of the same app on the database server, to see if a new version is available to be downloaded. It gets through all that just fine.
Whe I rename that, the database throws an error on startup, that it can't find the form.

Does it still crash if you disable the startup form and go to the main menu?

No, it only crashes if the app starts, and generally after the app has finished all its start-up chores and is waiting for its first task. But not always – once in a while it crashes while still starting.

What if you disable the main menu? Or disable its form load/open/activate/current/timer events?

Not sure what you mean by main menu. I don't have anything like a dashboard – it goes right into the form that displays data. It doesn't display any data at first, because it initializes with a SQL Server query that intentionally returns zero records. The user must select some activity in order for the app to start retrieving any records. Once it starts doing that, it doesn't crash, ever (barring my programming errors, unrelated to this issue).

[pdanes]

Are all users using the same office version?
Because these issues may occur if the database is accessed by different users who have different office versions.

Try setting up the same version of office on all client machines, preferably the office version used to develop the database.

Everything is 64-bit Windows 10, 64-bit Office 365. Just migrated - until recently, I was on 2007 - to stay compatible with the oldest setup. Once all the users went to 10 / 365, I did as well. The crashing did not happen on my machine as long as I was still on Vista / 2007. Now it happens to me as well.

[pdanes]

From your description it sounds like you have not split the db and all users are using the same file. Is this the case?

No, it is a true client-server setup. The app communicates with a SQL Server database on a separate server, via an ODBC link. Each user has his own copy of the app, running on his own machine. When I release a new version, I give it a higher number. The app compares its own version number against the one on the server, and when the server version is larger, initiates a download script that overwrites the running version and restarts. That has all been in place for years and works perfectly.

[pdanes]

Just finished porting everything to a new database. No good - still quits for no reason after starting, while not doing anything. But not if I click on something, anything quickly enough, and give it something to do. Once it starts doing something AFTER finishing the startup and going idle, it's fine - never crashes after that.

It's 1:30 in the morning here and I have to get up before people start coming in to the office, so I have to get some sleep now.

[isladogs]

Good morning
When you imported everything into a new blank database, did you tick all the checkboxes in the Options sections of the import dialog?

You referred to a main screen in post #1. That was what I meant by main menu.
I don't understand why Access can't find the 'main screen' when you disable the autoexec.

Following your comments in post #6, it seems you've moved from A2007 (32-bit) to 64-bit A365.
Could there be issues with API conversions? Does it compile in 64-bit? Even if it does, incorrect API declarations could cause it to crash when referenced by code.
Also are any VBA reference libraries missing or are any old libraries than are 32-bit only?

Also, you say it only crashes if idle. Its fine as long as you give it something to do....
As a test, try adding a timer event to a hidden form loaded at startup and always running in the background. Does that fix the crashing?

[pdanes]

Good morning
When you imported everything into a new blank database, did you tick all the checkboxes in the Options sections of the import dialog?

I did not. I do not have any of the extras like import/export specs, so I left those unchecked, and imported only the standard – tables, queries, forms, reports, macros and modules. Do you think that might make a difference? I can certainly try it.

You referred to a main screen in post #1. That was what I meant by main menu. I don't understand why Access can't find the 'main screen' when you disable the autoexec.

Oh, sorry – guess I didn't explain the setup carefully enough.
There is a startup form called Start, specified in the setting as the form to automatically open on database start-up. When I change that name, the name of the form that is specified to be called on start-up does not change, so the database opens but nothing runs, since it can't find that start form – its name has changed. Manually double-clicking on that form makes it run normally. The Start form does a bunch of prep work, including a user-specific splash screen, then starts the main form with its record source set to zero records selected for display, then closes itself. This generally works fine, and after the main form has opened, start form closed, and loading action of the main form completed, the database goes idle. The VBA window no longer shows the word 'Running' in the title bar, all graphic activity has ceased and the main form sits, waiting for the user to do something. At that point, usually within a few seconds, Access suddenly just quits. No warning, no error messages, absolutely nothing – the entire app just vanishes, as if the process was killed from the task manager window.

Following your comments in post #6, it seems you've moved from A2007 (32-bit) to 64-bit A365.

That is correct. I stayed on Vista, because I liked it, and on 2007, because there were machines scattered around the department with various versions of Office. Since library versions are forward compatible, but not backward, I stayed level with the oldest stuff, so I would not deploy a build too new for some users. Recently, too many things would no longer work under Vista, and the entire rest of the department got upgraded to Windows 10 and Office 365, so I followed suit.

Could there be issues with API conversions?

I suppose there could, but I have no idea how to check. Do you?

Does it compile in 64-bit?

It does. I have a 64-bit machine, with 64-bit everything on it. I decompile and compile regularly – no issues with that.

Even if it does, incorrect API declarations could cause it to crash when referenced by code.

But would that not make it crash ALWAYS, if there was an incorrect reference?

Also are any VBA reference libraries missing or are any old libraries than are 32-bit only?

None are missing. I do not know how to tell if something is 32-bit only.

Also, you say it only crashes if idle. Its fine as long as you give it something to do....
As a test, try adding a timer event to a hidden form loaded at startup and always running in the background. Does that fix the crashing?

Good idea, I will try that.

[Minty]

Although it may not have any bearing, make sure that the Name Autocorrect is turned off in the database options.
And as a wild stab in the dark, try adding a DoEvents to the end of your splash screen?

[CJ_London]

one other thought - are you using the correct ODBC driver? if everything has been upgraded, perhaps this needs to be as well.

And how are you connecting to sql server? linked tables? dao queries? ado queries?

What are your timeout settings? perhaps too short?

And I presume this is happening to all users, not just one or two?

[pdanes]

Although it may not have any bearing, make sure that the Name Autocorrect is turned off in the database options.
And as a wild stab in the dark, try adding a DoEvents to the end of your splash screen?

Name Autocorrect was turned on. I just tried turning it off - no change. Still quits after start.

DoEvents are already in place, as are several calls to Sleep for 500 milliseconds.

[pdanes]

one other thought - are you using the correct ODBC driver? if everything has been upgraded, perhaps this needs to be as well.

I'll look at that, although I think that a new Windows 10 installation and a new Office 365 installation should have all the latest stuff.

And how are you connecting to sql server? linked tables? dao queries? ado queries?

Linked tables and pass-through queries.

What are your timeout settings? perhaps too short?

They are the standard 60 seconds, except in the cases of a few complicated queries, which I bumped to five minutes after a few time-out incidents. But on start-up, the unwanted quitting happens in a matter of seconds, long before any timeout should be hitting. And shouldn't that throw an error, rather than blowing away the entire Access application without a word?

And I presume this is happening to all users, not just one or two?

I think so, but I'm not positive. Various people use or don't use this, as their workload shifts. Not everyone has come to complain about it, but some are busy with other tasks. It works some of the time, which is one the maddening things that make it so hard to track down. Often when I play with it for a while, it stops happening, making me think that I've acidentally fixed it, but then I deploy a new version and the feedback tells me that it is not fixed. And sure enough, when I start in on it again, it starts doing it to me again. All the regular users have said that it happens.

[Minty]

I'll look at that, although I think that a new Windows 10 installation and a new Office 365 installation should have all the latest stuff.

Not true with the SQL drivers that is for certain, I would update to the latest ODBC Driver 17 for SQL Server.
https://docs.microsoft.com/en-us/sql...l-server-ver15

Can you alter your start-up code to do a simple
SET rs = Currentdb.openrecordset ("SELECT top 1 from AnyOldLinkedTable" , dbseechanges)

Then rs.movelast
MsgBox rs.recordcount & " Record queried"

And see if that stops it crashing?