Access random crashing after moving to X64

[exebat]

Hi all,

I have an Access database that was working fine on Access 32bit, but since I had constant "no enough memory" errors I decided to move to X64 version of Access.

Now the error is gone but Access crashes randomly for no apparent reason.

I tried to decompile, compact and repair and also to import everything to a new database.

I also had one timer that I disabled so that is not a problem.

The error in Event viewer is


Faulting application name: MSACCESS.EXE, version: 16.0.16626.20170, time stamp: 0x64cc5e20
Faulting module name: VBE7.DLL, version: 0.0.0.0, time stamp: 0x63e1cbeb
Exception code: 0xc0000005


Fault offset: 0x0000000000390d46
Faulting process id: 0x0x171E4
Faulting application start time: 0x0x1D9CB90EED4CE46
Faulting application path: C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE
Faulting module path: C:\Program Files\Common Files\Microsoft Shared\VBA\VBA7.1\VBE7.DLL


It also crashes on other computers with the same error.

Access version:
Microsoft® Access® LTSC MSO (Version 2307 Build 16.0.16626.20170) 64-bit

Running on Windows 11

References are attached


None of additional references are used at the moment of crash


It usually crashes while I am in VBA editor. Sometimes after 5 minutes and sometimes after an hour.


What might be the problem ?

[Welshgasman]

Have you amended any code that is required to be changed, to 64bit?

[exebat]

Have you amended any code that is required to be changed, to 64bit?

I followed Microsoft docs to change the code to work in X64 and it works but randomly crashes.

For example it just crashed while in VBA editor. I tried changing Public SUB to Public Function and it froze and crashed while offering me to save a backup. Only one form (main form) was open and VBA Editor

[moke123]

I would suggest posting the code for the API's you converted so someone can confirm its correct.

[exebat]

I would suggest posting the code for the API's you converted so someone can confirm its correct.

I just changed some Long to LongPtr. I dont use many API's.

Is there a way to log the module that caused the Access to crash ?

[moke123]

I just changed some Long to LongPtr.

I'm just learning the conversion myself but it isn't just a matter of changing longs to longPTR's.
I believe it's just pointers that need to be converted.

[NAustin]

I am having the same issue after upgrading to 64-bit Access in Office 365. However, my crashes aren't quite random: I have a bit of code in a timecard database to check if someone has entered both time in and time out, and then subtract the two (military time):

#If IsNull(Me![WorkShiftIn]) Or IsNull(Me![WorkShiftOut]) Then Exit Sub
#Me![Hours] = Me![WorkShiftOut] = Me![WorkShiftIn]

The above lines cause Access to just close. So I commented out the code, and it still crashes. If I completely remove all code for this event and save my form. it doesn't crash. A few more notes:
1. This works fine in 32-bit Access
2. It's not just me (i.e., not like I have a bit of bad memory), it crashes for any other users who have also upgraded but works fine for those who are still using 32-bit
3. My code compiles without any errors (I have updated all "Declare Function" to be "Declare PtrSafe Function")
4. I have created a new Access database and copied all my objects into it, to no avail
5. I even exported all my objects as text files and then imported them into a brand-new Access file, no luck
6. I have several other Access databases that all seem (I haven't tested all their functionality yet) to be working fine in 64 bit

I don't have any choice but to use 64-bit Access, so any help would be greatly appreciated!

[Welshgasman]

You didn't copy that code did you but write it from scratch?

Me![Hours] = Me![WorkShiftOut] = Me![WorkShiftIn]

[moke123]

What are the octothorpes(#) for?

What api's do you have?

If you have api's there is more to conversion than just changing the declarations to PTRSafe.

[NAustin]

The octothorpes/pound signs/hash tags were because I misread this:

Please use # icon on toolbar when posting code snippets.

I've put my api calls below. I have also decided to completely recreate this form, copying and pasting each bit of code into an empty copy of the form. I'm about 25% finished and so far everything works fine, which leads me to believe there's something funky in the original, probably something I've forgotten I ever used and should have cleaned up long ago.

'-- API Calls for getting the current user and computer names
Declare PtrSafe Function wu_GetUserName Lib "advapi32.dll" Alias _
   "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) _
   As Long
Declare PtrSafe Function wu_GetComputerName Lib "kernel32" Alias _
   "GetComputerNameA" (ByVal lpBuffer As String, nSize As Long) _
   As Long
 
Public Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long
 
Declare PtrSafe Function ShellExecute Lib "shell32.dll" Alias _
   "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation _
   As String, ByVal lpFile As String, ByVal lpParameters _
   As String, ByVal lpDirectory As String, ByVal nShowCmd _
   As Long) As Long
 
Declare PtrSafe Function apiFindWindow Lib "User32" Alias "FindWindowA" _
   (ByVal lpclassname As Any, ByVal lpCaption As Any) As Long

Thank you so much for your time.

[Welshgasman]

You said you changed Long to LongPtr?

I do not see where?
I believe the pointers should at least be LongPtr

Edit: Ah that was the O/P that changed the Long.

[moke123]

did you check to see if any of the longs are handles/pointers?
for instance I think hwnd is a longptr but not positive.

[isladogs]

The last two are incorrect:

Declare PtrSafe Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hwnd As LongPtr, ByVal lpOperation As String, _
ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As LongPtr
 
Declare PtrSafe Function apiFindWindow Lib "User32" Alias "FindWindowA" _
   (ByVal lpclassname As Any, ByVal lpCaption As Any) As LongPtr

Also I've recently written a series of 4 articles on 32-bit to 64-bit conversion which you may find useful.
The first is at 32 to 64-bit Conversion (isladogs.co.uk)

[NAustin]

ShellExecute seems to work fine as written above, so I don't think hwnd is the problem.

I am now 90% of the way through recreating my one troublesome form (lots of controls but only one subform) and everything is working properly. I left out some code that I had used for a drag-and-drop box, but when I tried an older version of the project after removing just those lines, it still died. I will have to export my code and do a comparison to see what's different.

What really gets me about all this is that multiple copies of the same database all died in the same after_update event. When I removed that entire event, any given copy would die at the next after_update event. I now have the same code in the same places in a new file and it works as expected. Color me confused!

Thanks again for your time.

[NAustin]

I updated ShellExecute and FindWindow but my old (pre-recreated form) Access file still crashes. Good to going forward, though. And your articles are much appreciated.