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

Oreynolds

Member
Local time
Today, 21:14
Joined
Apr 11, 2020
Messages
157
Hi all,

I have been slowly developing my DB for 20 years and other than odd little issues it has been extremely stable. The DB users recently requested a basic means of allocating themselves and each other tasks. Rather than reinventing the wheel I used the MS Office Task Management template and largely copied across the tables and forms and then amended them to suit.

The task module works extremely well and everyone is happy with it however since rolling it out to all the users I now have an issue with Access randomly crashing on 4 of the 12 machines. To try and pinpoint the issue I set up a log and asked all users to record details of the crash, time/date/what they were doing/what form they were on. Sadly it has not shown any real patterns with the exception it is limited to 4 users out of 12.

Given the DB has always been so stable this pointed me to it potentially being an environment issue with those particular users and on further investigation it turns out the one common thing that all these users have in common that is different to everyone else is they have MS Access 365 64 bit on their machines where as everyone else who is not suffering any issues at all are running 32 bit.

Strangely prior to my task module implementation these 64 bit machines (which have been in service for approx 12 months) were not having any issues which is clearly shown in the computer management application logs which all show the crashes starting on the 64 bit machines on the day I implemented the task module.

It would be easy to blame some issue with the task module I built, however it is pretty basic with very little VBA code and also the 32 bit machines are not have any issues with it at all??

Does anyone else have any experience with this issue and any pointers to getting to the bottom of the issue?

Thanks
 

Joe Boatman

New member
Local time
Today, 21:14
Joined
May 30, 2020
Messages
25
In my experience, Access VBA doesn't work well if you have API calls which are mainly 32 bit. I found some postings about this and suggested methods which I tried to implement but it was a lot of work and I found it simpler to install 32 bit Office. I will look for links to help and update this post.
 

Oreynolds

Member
Local time
Today, 21:14
Joined
Apr 11, 2020
Messages
157
Application error is consistent as follows:

Faulting application name: MSACCESS.EXE, version: 16.0.12730.20270, time stamp: 0x5eb57471
Faulting module name: OLEAUT32.dll, version: 10.0.18362.836, time stamp: 0xd79b97e6
Exception code: 0xc0000005
Fault offset: 0x000000000008c808
Faulting process id: 0x1a80
Faulting application start time: 0x01d6382291177f52
Faulting application path: C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE
Faulting module path: C:\WINDOWS\System32\OLEAUT32.dll
Report Id: 927584e9-f595-4253-892d-963a8fc714cb
Faulting package full name:
Faulting package-relative application ID:
 

Joe Boatman

New member
Local time
Today, 21:14
Joined
May 30, 2020
Messages
25
This is from my documentation - hope it helps
32-bit and 64-bit Windows and Office
09 May 2019

Office 2016 comes in 32-bit and 64-bit versions. OurDb has been created in 32-bit VBA which should only be installed on 32-bit or 64-bit machines.

See Working with VBA in the 32-bit and 64-bit Versions of Office 2010 – web link.

How should I make my VBA code compatible with 64-bit Windows? Note that it indicates using the following code for API calls when using 32-bit Office on a 64-bit machine so that Windows calls are properly made.

Code:
#If VBA7 Then
    Private 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
#Else
    Private Declare 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
#End If

This is all a bit strange because there's a VBA7 constant and a Win64 constant: VBA7 is true if the VBE editor is version 7 (Office 2016 VBE Help > About shows v7.1) and Win64 is False if using the 32-bit version of Office – so why call it Win64 which suggests a test for Windows, not Office; it should be Off64!
 

Micron

AWF VIP
Local time
Today, 17:14
Joined
Oct 20, 2018
Messages
3,476
Want a reliable solution from what I've read? Replace 64 bit version with 32.
Unless you need the extra memory that 64 can access, or have Office files larger than 2Gb, you're better off with 32 IMO.
With Access 64 bit, some add-ins and after-market controls won't work, then there is the issue with Declare Statements, which is what ptrSafe is about.
You didn't need Office 64 in the past by the sounds of it, so probably don't need it now. Likely IT wants to have the latest and greatest under the hood because they can and seem to think this is some sort of unwritten rule, but in these cases it's not a good enough reason.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:14
Joined
Feb 28, 2001
Messages
27,001
Exception code: 0xc0000005

Exception code 0xc00000005 tells you two things. The "c" says "fatal to the process i.e. not continuable." The "0005" is a memory fault which is most often caused by addressing problems trying to touch an unmapped section of virtual memory. However, there is also the odd chance that the fault was an attempt to write to a protected section of memory that is read-only using the Win10 feature to memory-lock all sections of memory that contain executable code. I'm betting "inaccessible address" rather than "locked address" but that is an OPINION based on odds, not a certainty.

File OLEAUT32, called out by that error, is a 32-bit version of an OLE interface utility file. Here is a description of it.


As noted by Joe Boatman, and consistent with your observation of the four machines being on Office 64-bit versions, you have a software compatibility problem. What I believe is that there is no way to fix this for the four users of 64-bit Office EXCEPT to remove that version of Office and reinstall with 32-bit Office instead as Joe B. and Micron have suggested. This is because the OLEAUT32 file isn't something YOU call from one of your code modules. I don't believe you can make a declaration that will "fix" this call. It is something that Access itself calls, related to some interface, and you cannot change their call sequence. That code isn't visible to you.

By the way, capturing the fault message sequence was an excellent choice for reporting the problem. Thanks, because it makes diagnosis easier.
 

Oreynolds

Member
Local time
Today, 21:14
Joined
Apr 11, 2020
Messages
157
Exception code 0xc00000005 tells you two things. The "c" says "fatal to the process i.e. not continuable." The "0005" is a memory fault which is most often caused by addressing problems trying to touch an unmapped section of virtual memory. However, there is also the odd chance that the fault was an attempt to write to a protected section of memory that is read-only using the Win10 feature to memory-lock all sections of memory that contain executable code. I'm betting "inaccessible address" rather than "locked address" but that is an OPINION based on odds, not a certainty.

File OLEAUT32, called out by that error, is a 32-bit version of an OLE interface utility file. Here is a description of it.


As noted by Joe Boatman, and consistent with your observation of the four machines being on Office 64-bit versions, you have a software compatibility problem. What I believe is that there is no way to fix this for the four users of 64-bit Office EXCEPT to remove that version of Office and reinstall with 32-bit Office instead as Joe B. and Micron have suggested. This is because the OLEAUT32 file isn't something YOU call from one of your code modules. I don't believe you can make a declaration that will "fix" this call. It is something that Access itself calls, related to some interface, and you cannot change their call sequence. That code isn't visible to you.

By the way, capturing the fault message sequence was an excellent choice for reporting the problem. Thanks, because it makes diagnosis easier.

Thanks very much for this detailed response, extremely helpful.

To update you slightly I have already taken the step of changing one of the 4 users on 64 bit down to 32. They are a heavy user and went through the entire day without a crash proving unequivocally that it is a 32/64 bit issue.

I am still slightly confused as to how this has happened when all four users have been running 64 bit for 12 months or more without any issues whatsoever. Then following my minor task module implementation on the DB on the 15/5/20 all of a sudden they all instantly start reporting issues whilst all other 32 bit users don't?? Whilst its easy to blame my new task module which is very basic with minimal code why don't the 32 bit users suffer? Is it possible something I copied over form the MS template into my DB affects 64 but not 32 bit operators......seems odd to me?

My longer term concern in terms of trying to fix it is the prospect of MS removing support for the 32 bit version as is their trend these days. This could happen at any time and out IT support have warned of this as a possibility. I'm not sure if you have an opinion on this?
 

Joe Boatman

New member
Local time
Today, 21:14
Joined
May 30, 2020
Messages
25
"MS removing support for the 32 bit version" is a good point but I think that until MS change their APIs to 64 bit we will be OK. Once MS have APIs compatible with Access & VBA 64 bit, then we can switch over.
 

Gasman

Enthusiastic Amateur
Local time
Today, 21:14
Joined
Sep 21, 2011
Messages
14,047
Might even be worth posting your code for you task module to see if anyone can shed any light on what you might be able to change.?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:14
Joined
Feb 28, 2001
Messages
27,001
I am still slightly confused as to how this has happened when all four users have been running 64 bit for 12 months or more without any issues whatsoever. Then following my minor task module implementation on the DB on the 15/5/20 all of a sudden they all instantly start reporting issues whilst all other 32 bit users don't??

It's because something you do in your Access app is different than what these 64-bit users were doing before. It may be cold comfort but they were just lucky until now. The other major Office apps are mostly independent of each other in that it is very rare to implement VBA code underneath Word or PowerPoint or Excel (at least for the average user). But Access touches a lot of things via OLE methods. The fact that the faulting module is OLE related means that you triggered an interaction through a library module that the other Office programs were less likely to use.

The real question is, when in the app does the crash occur? Directly upon launch? Or when you trigger a feature, launch a form or report, open a table? When does the crash occur from the operational viewpoint? Your experiment shows the answer to your other question: "Whilst its easy to blame my new task module which is very basic with minimal code why don't the 32 bit users suffer?" If the problem is a 32/64 addressing issue, then the 32-bit users don't try to use a 64-bit address to activate a 32-bit routine. They use a 32-bit address to do so, and that is "innocuous" behavior. It is of no consequence WHAT you were actually doing. It matters more HOW you were doing it - 64 bits at a time.
 

Oreynolds

Member
Local time
Today, 21:14
Joined
Apr 11, 2020
Messages
157
It's because something you do in your Access app is different than what these 64-bit users were doing before. It may be cold comfort but they were just lucky until now. The other major Office apps are mostly independent of each other in that it is very rare to implement VBA code underneath Word or PowerPoint or Excel (at least for the average user). But Access touches a lot of things via OLE methods. The fact that the faulting module is OLE related means that you triggered an interaction through a library module that the other Office programs were less likely to use.

The real question is, when in the app does the crash occur? Directly upon launch? Or when you trigger a feature, launch a form or report, open a table? When does the crash occur from the operational viewpoint? Your experiment shows the answer to your other question: "Whilst its easy to blame my new task module which is very basic with minimal code why don't the 32 bit users suffer?" If the problem is a 32/64 addressing issue, then the 32-bit users don't try to use a 64-bit address to activate a 32-bit routine. They use a 32-bit address to do so, and that is "innocuous" behavior. It is of no consequence WHAT you were actually doing. It matters more HOW you were doing it - 64 bits at a time.

Thanks again for your response, and the answers to your questions are where my confusion starts.

My method for tracking down the source of the issue was to create an Excel log that all users were instructed to record details of every crash they experienced. By doing this I hoped to find a pattern or consistency to the crashes.

After a week had elapsed just over 30 crashes has been recorded but there were literally no patterns. Crashes occurred on different forms, doing different processes, on entering username in the log in form......all just totally random. Weirdly they often occurred in batches, 3 or 4 crashes in the space of just a few minutes but each time doing something completely different and unrelated. The only consistency my crash log provided was that they were all recorded by 64 bit users.

To be clear most of the crashes recorded also did NOT relate to the new task module I had recently introduced.

So whilst I totally understand it’s without doubt a 32/64 bit issue, what I still don’t understand is why if the crashes are not specific to the new Task module introduced and the 64 bit machines have worked fine for a year or more why have they suddenly become an issue?

You/we may not ultimately be able to answer it I guess but it’s a bit unnerving going forward....?!
 

Oreynolds

Member
Local time
Today, 21:14
Joined
Apr 11, 2020
Messages
157
Might even be worth posting your code for you task module to see if anyone can shed any light on what you might be able to change.?

Thanks, I could do this but as per my previous post the crashes are not related to the task module, they occur randomly from just about anywhere. It’s only that they have started since the task module was introduced back on 15/05. The obvious source would be the tasks but if it’s crashing when tasks are not even in use then that also doesn’t make sense...??
 

Micron

AWF VIP
Local time
Today, 17:14
Joined
Oct 20, 2018
Messages
3,476
An answer to the outstanding question could be "updates"- perhaps even inconsistently applied across the organization. Do all the affected users have something in common such as belonging to the same branch?
 

Minty

AWF VIP
Local time
Today, 21:14
Joined
Jul 26, 2013
Messages
10,355
Windows/Office updates have done some weird shizzle recently.
I've had PowerPoint automation that has been working fine for 6 months keel over in the last 3 or 4 weeks.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:14
Joined
Feb 28, 2001
Messages
27,001
the answers to your questions are where my confusion starts.

Well, we can't have confusion lingering, now, can we?

This might be more than you wanted to do, but there is a definitive way to narrow this down IF it relates to some particular module. It might not. And it will be your call as to whether you want to go this far. I can't make that decision for you but I can tell you how to narrow down your list of suspects.

Add an event-audit table to your DB with a Date field and a Short Text field of 60-120 bytes depending on just how wordy your module names are. Then at the entry point for each of your functions and subroutines (and event routines, since they are subs), make an entry that stores date and time via Now(), as well as some message like the name of the entry point. This becomes an action trace log. Then you get to observe these logs and see where they end. OR you could instead log the name and the value of the Timer() function (which is a SINGLE, not a DATE), which is ticks since midnight, accurate to about 1/60th of a second. Either way you get to see exactly what gets called and when (and in what sequence).

If you were planning to just convert everyone anyway, this history log wouldn't really be useful for THIS problem. - but it might help you with other problems later.

Let me ask a question or two that might sound random, but trust me they aren't.

Do you have anything embedded in your DB like a picture or document, and if so, is there code to open the embedded object?
Do you have hyperlinks stored as fields in your DB and if so, do you have any code that might look at the content of the hyperlinked object?
Do you have any code which creates an application object, and if so do you attempt to actually use that object?
Do you have any code which creates dynamic variant arrays, and if so do you do much with those arrays?

I found a list of entry points for OLEAUT32 (over 400 of them) and my questions relate to things found in that module that might relate to your code touching something external, whether it be embedded, referenced, or instantiated. The list includes support for the topics of my four questions.
 

Oreynolds

Member
Local time
Today, 21:14
Joined
Apr 11, 2020
Messages
157
Well, we can't have confusion lingering, now, can we?

This might be more than you wanted to do, but there is a definitive way to narrow this down IF it relates to some particular module. It might not. And it will be your call as to whether you want to go this far. I can't make that decision for you but I can tell you how to narrow down your list of suspects.

Add an event-audit table to your DB with a Date field and a Short Text field of 60-120 bytes depending on just how wordy your module names are. Then at the entry point for each of your functions and subroutines (and event routines, since they are subs), make an entry that stores date and time via Now(), as well as some message like the name of the entry point. This becomes an action trace log. Then you get to observe these logs and see where they end. OR you could instead log the name and the value of the Timer() function (which is a SINGLE, not a DATE), which is ticks since midnight, accurate to about 1/60th of a second. Either way you get to see exactly what gets called and when (and in what sequence).

If you were planning to just convert everyone anyway, this history log wouldn't really be useful for THIS problem. - but it might help you with other problems later.

Let me ask a question or two that might sound random, but trust me they aren't.

Do you have anything embedded in your DB like a picture or document, and if so, is there code to open the embedded object?
Do you have hyperlinks stored as fields in your DB and if so, do you have any code that might look at the content of the hyperlinked object?
Do you have any code which creates an application object, and if so do you attempt to actually use that object?
Do you have any code which creates dynamic variant arrays, and if so do you do much with those arrays?

I found a list of entry points for OLEAUT32 (over 400 of them) and my questions relate to things found in that module that might relate to your code touching something external, whether it be embedded, referenced, or instantiated. The list includes support for the topics of my four questions.

Thanks, no confusion is not great and whilst downgrading to 32 bit is a fix in the short term it doesn't bode well to leave known issues in the DB that will come back to bite you going forward on 64bit as and when MS pull the 32 bit option!

I will look at your audit log idea, thanks.

In answer to your questions which may help point us in the right direction:

Do you have anything embedded in your DB like a picture or document, and if so, is there code to open the embedded object?
I have a single .png logo on each of the main forms. This logo has been there for many years, originally as a .bmp and more recently as a .png so inclined to think these are not an issue. That said interestingly the new Task module I brought over from the MS template includes an Attachment field in the table accessible through one of the Task forms that I also copied over. This is the first attachment field I have ever had in the DB and aside of this crashing issue I was thinking of removing it due to the concern of people using it too much and bloating the data file. Is this potentially linked do you think?
Do you have hyperlinks stored as fields in your DB and if so, do you have any code that might look at the content of the hyperlinked object?
I do have hyperlinks in fields and have done for some time. When I say hyperlinks they are fields which for example show the record ID of a product and when clicked it opens up the product form to allow you edit the product details. This occurs in several places performing similar form opening functions but not looking at the content of an object as such. These hyperlinks have been in use in places for a long time so again I'm not inclined to think these are an issue.
Do you have any code which creates an application object, and if so do you attempt to actually use that object?
I have code in several places that creates emails, excel files and word documents. All these have been in use for many years without issue on both 32/64 bit machines.
Do you have any code which creates dynamic variant arrays, and if so do you do much with those arrays?
No I don't.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:14
Joined
Feb 28, 2001
Messages
27,001
OK, for my questions, the hyperlinks and app objects are the more likely points of interest. An embedded image is the lowest probability of the three themes to have caused this.

Your responses seem to have this underlying "tone" or "theme" that you feel you have done something terribly wrong with your code. But really, you can't say that. You don't have a ticking time bomb that will reach out and grab you in 32-bit environments; at least, not unless Microsoft comes back and actually DOES pull the 32-bit plug.

I'm not going to worry about 32-bit Office going away. In order for that to happen without losing major customer blocs, MicroSoft would have to first create 64-bit versions of all of their libraries. (I.e. create an OLEAUT64 to go with the 64-bit versions.) Otherwise, customers would (rightly) see that as MS abandoning their customers, and they don't want that. But more important, some of the libraries in question are used by MS's own 32-bit utilities that they never bothered to upgrade for 64-bit machines. They want repeat business and a LOT of 32-bit implementations are hanging around out there. Not to mention virtual machine technology that gives you 32-bit environments, often for compatibility with older software anyway. So ... yes, MS can go crazy and kill 32-bit environments. And that is the day a significant number of their customers will jump ship. You should know this: the U.S. Government is one of the largest customers of MS Office and they have bloc buying power in the "millions of licenses" category. For the U.S. Navy's MILNET alone, their address book was in the tens of thousands. For security reasons I cannot be more specific than that and besides, I lost track of that when i retired. However, trust me. I wouldn't hold my breath on that one happening any time soon. But I digress...

You found no pattern in where these crashes were happening - different forms, different, actions, no obvious pattern. Here is my take on that, and it might help you orient your thinking a little bit. (Or maybe not...)

1. You have a single logo on each of the forms. If you have this logo on an "opening form" (a.k.a. startup form) then your users would crash on launch so skip that. It is of no concern, is static in nature, and probably ignorable - particularly if it is small. Further, static images are well-known and unlikely to contain active code.

2. Your concern over bloating via the new "attachment" field is of proper concern if people can use it to add some potentially large object to your DB. Bloat is nothing to treat lightly. A mechanism that changes the attachment from being embedded in the DB to being kept in a common folder (and the field contains the hyperlink to it) might be worth looking into, and my concern there might be focused on this, which you say is a relatively new feature. The idea/feature might not itself be bad, but the way it is implemented might risk severe bloat. (And see below for more.)

3. Hyperlinks that launch other Access objects within the same DB are not an issue. From the nature of the OLEAUT32 descriptions I got online, I get the sense that if there IS a problem, it is something to do with external linking to a non-Access entity. I wouldn't focus on that FIRST.

4. External app objects can certainly be an issue. But they tend to be opened predictably and that doesn't match your (non-)pattern of crashes.

So... my next question relates to your expressed concern over your new attachment feature. Can you correlate the start of the crashes to the start of deployment of the new feature? And my follow-up question relates to the attachment field: Is there some commonality in the crash actions such that your users might not be defining the field, but might be trying to use it? Which would explain the spread-out nature of your crashes. I keep coming back to the idea that OLEAUT32 (Object Linking/Embedding AUTomation 32-bit) is going to be employed when dealing with something foreign to access because otherwise it isn't an OLE situation.

You see, what I keep returning to is that you are not having a crash at a particular point, a particular CALL interface or declaration. It is not at all deterministic. That apparent "randomness" would occur if it were data-dependent rather than code-dependent. Which means it would depend not what someone was using, but what they were touching when they did it, which would point to a possibly "funky" attachment that IMPLICITLY triggers some internalized routine to handle the attachment. Not a routine that you wrote, but one internal to Access that is being triggered by the fact that Access detected something that needed an OLE interaction based on what it saw. Am I being clear enough on this?

IF I am correct, then you CANNOT fix this by altering a particular API call to honor 64-bit environments - because this literally isn't your call. It is buried inside Access itself. Or worse, inside the greater sphere of Office products in general, because one of the BIG moves in the Office 2003-2007 version change was the way Office Components interacted with each other. They are a lot more common in their usage of Office support code than they used to be. (It was a GOOD thing - but required rethinking some interfaces.) I'm saying it that way because you don't have to make a reference to OLEAUT32 in order for it to work. And that means it is covered by the Office "umbrella."
 

kentgorrell

Member
Local time
Today, 21:14
Joined
Dec 5, 2020
Messages
47
Hi all,

I have been slowly developing my DB for 20 years and other than odd little issues it has been extremely stable. The DB users recently requested a basic means of allocating themselves and each other tasks. Rather than reinventing the wheel I used the MS Office Task Management template and largely copied across the tables and forms and then amended them to suit.

The task module works extremely well and everyone is happy with it however since rolling it out to all the users I now have an issue with Access randomly crashing on 4 of the 12 machines. To try and pinpoint the issue I set up a log and asked all users to record details of the crash, time/date/what they were doing/what form they were on. Sadly it has not shown any real patterns with the exception it is limited to 4 users out of 12.

Given the DB has always been so stable this pointed me to it potentially being an environment issue with those particular users and on further investigation it turns out the one common thing that all these users have in common that is different to everyone else is they have MS Access 365 64 bit on their machines where as everyone else who is not suffering any issues at all are running 32 bit.

Strangely prior to my task module implementation these 64 bit machines (which have been in service for approx 12 months) were not having any issues which is clearly shown in the computer management application logs which all show the crashes starting on the 64 bit machines on the day I implemented the task module.

It would be easy to blame some issue with the task module I built, however it is pretty basic with very little VBA code and also the 32 bit machines are not have any issues with it at all??

Does anyone else have any experience with this issue and any pointers to getting to the bottom of the issue?

Thanks
Try removing any conditional formatting for any form that you may be opening.
Function FormatConditions_Delete()
Dim frm As Form
Dim ctl As control
Dim strFormName As String

strFormName = "frmWhatever"
DoCmd.OpenForm strFormName, acDesign
Set frm = Forms(strFormName)
For Each ctl In frm.Controls
If ctl.ControlType = acTextBox Or ctl.ControlType = acComboBox Then
ctl.FormatConditions.DELETE
End If
Next ctl
DoCmd.Close acForm, strFormName, acSaveYes
End Function
worked for me
 

Blonkos

New member
Local time
Today, 22:14
Joined
Nov 22, 2020
Messages
7
OK, for my questions, the hyperlinks and app objects are the more likely points of interest. An embedded image is the lowest probability of the three themes to have caused this.

Your responses seem to have this underlying "tone" or "theme" that you feel you have done something terribly wrong with your code. But really, you can't say that. You don't have a ticking time bomb that will reach out and grab you in 32-bit environments; at least, not unless Microsoft comes back and actually DOES pull the 32-bit plug.

I'm not going to worry about 32-bit Office going away. In order for that to happen without losing major customer blocs, MicroSoft would have to first create 64-bit versions of all of their libraries. (I.e. create an OLEAUT64 to go with the 64-bit versions.) Otherwise, customers would (rightly) see that as MS abandoning their customers, and they don't want that. But more important, some of the libraries in question are used by MS's own 32-bit utilities that they never bothered to upgrade for 64-bit machines. They want repeat business and a LOT of 32-bit implementations are hanging around out there. Not to mention virtual machine technology that gives you 32-bit environments, often for compatibility with older software anyway. So ... yes, MS can go crazy and kill 32-bit environments. And that is the day a significant number of their customers will jump ship. You should know this: the U.S. Government is one of the largest customers of MS Office and they have bloc buying power in the "millions of licenses" category. For the U.S. Navy's MILNET alone, their address book was in the tens of thousands. For security reasons I cannot be more specific than that and besides, I lost track of that when i retired. However, trust me. I wouldn't hold my breath on that one happening any time soon. But I digress...

You found no pattern in where these crashes were happening - different forms, different, actions, no obvious pattern. Here is my take on that, and it might help you orient your thinking a little bit. (Or maybe not...)

1. You have a single logo on each of the forms. If you have this logo on an "opening form" (a.k.a. startup form) then your users would crash on launch so skip that. It is of no concern, is static in nature, and probably ignorable - particularly if it is small. Further, static images are well-known and unlikely to contain active code.

2. Your concern over bloating via the new "attachment" field is of proper concern if people can use it to add some potentially large object to your DB. Bloat is nothing to treat lightly. A mechanism that changes the attachment from being embedded in the DB to being kept in a common folder (and the field contains the hyperlink to it) might be worth looking into, and my concern there might be focused on this, which you say is a relatively new feature. The idea/feature might not itself be bad, but the way it is implemented might risk severe bloat. (And see below for more.)

3. Hyperlinks that launch other Access objects within the same DB are not an issue. From the nature of the OLEAUT32 descriptions I got online, I get the sense that if there IS a problem, it is something to do with external linking to a non-Access entity. I wouldn't focus on that FIRST.

4. External app objects can certainly be an issue. But they tend to be opened predictably and that doesn't match your (non-)pattern of crashes.

So... my next question relates to your expressed concern over your new attachment feature. Can you correlate the start of the crashes to the start of deployment of the new feature? And my follow-up question relates to the attachment field: Is there some commonality in the crash actions such that your users might not be defining the field, but might be trying to use it? Which would explain the spread-out nature of your crashes. I keep coming back to the idea that OLEAUT32 (Object Linking/Embedding AUTomation 32-bit) is going to be employed when dealing with something foreign to access because otherwise it isn't an OLE situation.

You see, what I keep returning to is that you are not having a crash at a particular point, a particular CALL interface or declaration. It is not at all deterministic. That apparent "randomness" would occur if it were data-dependent rather than code-dependent. Which means it would depend not what someone was using, but what they were touching when they did it, which would point to a possibly "funky" attachment that IMPLICITLY triggers some internalized routine to handle the attachment. Not a routine that you wrote, but one internal to Access that is being triggered by the fact that Access detected something that needed an OLE interaction based on what it saw. Am I being clear enough on this?

IF I am correct, then you CANNOT fix this by altering a particular API call to honor 64-bit environments - because this literally isn't your call. It is buried inside Access itself. Or worse, inside the greater sphere of Office products in general, because one of the BIG moves in the Office 2003-2007 version change was the way Office Components interacted with each other. They are a lot more common in their usage of Office support code than they used to be. (It was a GOOD thing - but required rethinking some interfaces.) I'm saying it that way because you don't have to make a reference to OLEAUT32 in order for it to work. And that means it is covered by the Office "umbrella."
thank you i like your answer .
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 16:14
Joined
Feb 28, 2001
Messages
27,001
As an addendum to this thought, I want to clarify my comments: If this apparent randomness persists and you cannot track it with the internal logging I suggested, then the problem isn't with what your users touch within Access; it is what your app touches that is the problem. I.e. data dependency on something external to Access itself. Because OLEAUT32 deals with various kinds of OLE activation. That means that you are launching something else besides Access to open something. So that would indicate that some non-Access object is malformed.
 

Users who are viewing this thread

Top Bottom