Access Office 365 64 Bit Random Crashes whilst 32 Bit All OK (1 Viewer)

[Kman79]

I would like to add my experience with this same crash I was experiencing after a move from 32 to 64bit access (Faulting module name: OLEAUT32.dll).

Just like the original poster this crash didn't occur until the move to 64 bit and had no error message, just a crash to the desktop after loading a specific form. The crash didn't happen every time and seemed somewhat random. Usually the form would load fine the first few times, then crash a few times, then load fine a few etc etc..

This crash, for me, had nothing to do with the VBA code (did extensive testing) but had to do with some corrupted text boxes that were on the form (the form has plenty of other text boxes that I found to not be involved in the crash). I figured this out by creating a copy of the access application and just started deleting objects off of the form until I got to the point were I was able to load the form 5 - 10 times in a row without a crash. Once the crashes stopped I narrowed it down to a group of text boxes that had nothing special about them. They didn't have a record source, there was no code being applied to them on form_load, there were no filters etc.. I tried cutting them off the form then pasting them back in and it did not fix the issue.

To fix them I needed to create brand new text boxes. I gave them the exact name as the old ones and the exact same properties and the crash has not occurred anymore.

The method described above is how I fixed a handful of applications that all had this same crash start happening with the move to 64bit. Hopefully it can help anyone else seeing this error (Faulting module name: OLEAUT32.dll).

I would love to hear if anyone has an idea of why a text box would cause this type of crash though.

 

[The_Doc_Man]

KMan, that is an EXCELLENT story and a demonstration of good debugging technique. The "process of elimination" showed you some corrupted items which you removed - and fixed the problem.

As to why a text box would cause this kind of crash, you have asked an incomplete question. It should be "why a CORRUPTED text box..."

And there is a potential answer. During development of the form, was there ever a time when the text box was something else and, in design mode, you RIGHT-clicked the box to change it to a text box? If that was done raggedly or saved improperly then the box became malformed and we ALL know Access doesn't like malformed structures. It barfs.

The problem with malformed / corrupted objects is that it becomes a matter of HOW it was corrupted - i.e. what was wrong with it? And considering how many properties exist even on a text box, ... that's a LOT of places for something to go wrong.

 

[kentgorrell]

KMan, I had a similar experience except that it was with combo boxes not text boxes. This was on a single record view, unbound form. I removed and recreated to fix the issue.

But then I had crashes on another (Continuous form). again, combo boxes. After much addoo, wailing, nashing of teeth and trial and error, it came down to the conditional formatting on those combos.

These may be two entirely separate issues. and as Doc Man points out, there are a lot places for things to go wrong with what appear to be 'simple' controls. I admit that after a couple of decades working with Access, there are lots of control properties I've never touched. Never had the need or curiosity.

But as I inherited these forms, I've no idea what someone may have done to them previously.

 

[Babycat]

I have a project on Access 365 (32 bit) which there is one form crashing most of time when I go to form design or typing code in VBA editor, confirmed it also happens on O365 64 bits... Will try to narrow down. It is really anoying. My currrent solution is go to virtual machine and work with Access 2019, it does not crash at all )

 

[The_Doc_Man]

The question is whether any part of the project was developed in 64-bit context while any other part was developed in 32-bit context. That mixed context development would kill you pretty quickly, I think.

 

[Babycat]

The question is whether any part of the project was developed in 64-bit context while any other part was developed in 32-bit context. That mixed context development would kill you pretty quickly, I think.

Oh God, I did not know that. In fact, I have developed most form, report, queries and VBA code on O365 64 bit. After crashing occurs oftenly, i try to search and ppl saying that 32 bits version is better. Therefore, I install 32 bits version which is currently using. However, there were 2-3 crashes yesterday. With almost zero understanding, I think that 32bits and 64bits are only matter in accde...

 

[The_Doc_Man]

Bitness (32- vs. 64-) matters, period. You can't very well mix them during development. In fact, it should fail if you even try. But if you run on the other bitness than the one under which you developed, that will be pretty bad too.

 

[Babycat]

Bitness (32- vs. 64-) matters, period. You can't very well mix them during development. In fact, it should fail if you even try. But if you run on the other bitness than the one under which you developed, that will be pretty bad too.

For those projects have been mixed design using both O365 32bits and 64bits. Can I create a blank project in 64bit then copy whole things from the mixed one? Does that help to eliminate the potential issues?

 

[The_Doc_Man]

For those projects have been mixed design using both O365 32bits and 64bits. Can I create a blank project in 64bit then copy whole things from the mixed one? Does that help to eliminate the potential issues?

Yes and no. You should be able to import object from a 32-bit to a 64-bit environment. HOWEVER, not all libraries (VBA page >> Tools >> References) have been ported to 64-bit so you might not be able to implement some things in a way you would have liked. Offhand, I don't know what is and what is not available, 64-bit-wise, but we have seen reports on this forum of one library or another that is 32-bit only and hasn't been converted. I have never needed the size implied by 64-bit Office and thus have never bothered to convert.

 

[Babycat]

Yes and no. You should be able to import object from a 32-bit to a 64-bit environment. HOWEVER, not all libraries (VBA page >> Tools >> References) have been ported to 64-bit so you might not be able to implement some things in a way you would have liked. Offhand, I don't know what is and what is not available, 64-bit-wise, but we have seen reports on this forum of one library or another that is 32-bit only and hasn't been converted. I have never needed the size implied by 64-bit Office and thus have never bothered to convert.

Thank you, Sir.

For me, i dont know which version (32 or 64bits) customer using, since I distribute accde file so it is likely I have to have both 32 and 64 bit available...

 

[Gasman]

Or just use the compiler directives, and then only have to maintain one system?

 

[Babycat]

Actually my VBA code is pretty simple, no special Reference lib.
There is only one compiler switch

#If VBA7 Then
 Public Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#Else
 Public Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
#End If

Until now, I dont see any different behaviour of my project on 32 and 64 bits...

 

[The_Doc_Man]

The problem is that if you distribute an .ACCDE, those switches cannot take effect based on environment. Those are COMPILER options, not run-time options. That .ACCDE is either 32-bit or 64-bit based on the bitness of Access on the machine where it was developed.