We may have another issue to watch out for this week. A couple of users have now reported that installing KB5064081 is causing their Access applications to crash, specifically when running code that uses ADO and/or DAO.
One such report can be found:
My workarounds found until now (while still using ADO): Use ACE provider “Microsoft.ACE.OLEDB.12.0” instead of “Microsoft.Jet.OLEDB.4.0″
(only works with 64-bit?)
Uninstall…
If this were a one-off, I wouldn’t raise the alarm just yet. But with multiple independent reports of the same behavior, it’s something we should keep an eye on.
It seems that this may be related to using the old ‘Microsoft.Jet.OLEDB.4.0’ reference library, something in the KB5064081 update appears to break it. Yes it is old, but it was previously functional. So the recommendation is to either hold off installing the KB5064081 update OR update the VBA reference and use ‘Microsoft.ACE.OLEDB.12.0’ instead of the ‘Microsoft.Jet.OLEDB.4.0’ library.
The issue here is that because this impacts an old Jet reference, we don’t know if Microsoft will address it with its limited resources, so delaying the install may not be the best course of action in this specific case. Now this is just my opinion and Microsoft has yet to say anything on the matter, so who know, they may surprise me and fix it promptly.
👉 If you’ve installed this update and are experiencing similar crashes, please share your experience in the comments below.
We are also seeing this with an Access app using DAO
Are you also using the older Jet reference library or were you already using the ACE library?
We are also experiencing crashes that can be related to the KB5064081 update for Win11 24H2.
The Windows Event Viewer lists “ucrtbase.dll” as the faulty module with the exception code 0xc0000005.
Debugging the application has shown that the error occurs when accessing the user collection of the DBEngine object.
Replacing “dao360.dll” in the “Program Files (x86)\Common Files\Microsoft Shared\DAO” folder with the old version of the file did not change anything, nor did replacing “ucrtbase.dll” in “Windows\SysWOW64”. The only reliable workaround is to uninstall the Windows update.
Can I ask you what version/build & bitness of Microsoft Access are you running that experienced this issue?
Access 2002, v. 10.00.6771, 32-bit
and please: no discussion about using such an outdated Access version
“no discussion about using such an outdated Access version”
Come on! Please … In a seriousness, I still have clients running 2003 and even prior versions. I’m not like most pushing new versions down peoples’ throats! If it works great, don’t mess with it. My preferred versions remain 2000 and 2013. Until very recently the newer version truly didn’t offer anything whatsoever over the older version and IMHO actually had more issues. It is only now with the Modern Web Browser control and the Monaco SQL Editor that perhaps there is merit in upgrading, but even then, with the plague of bugs, even that is VERY debatable. Hopefully, things will get fixed, so maybe in a year or 2 it truly will be worth the upgrade.
Sadly though, because you are running 2002, Microsoft is HIGHLY likely to ignore any such reports as it is EOL. To them Access 2013 (and prior) no longer exists and are no longer their problem. Even 2016 is a month or so away from EOL and I doubt they want to mess with it either, but they may not have a choice in this instance, time will tell.
I just wanted to avoid the classic discussion of “upgrade to a current version to solve the problem.”
Microsoft will not fix problems that occur in Access 2002. However, Jet4.0 and DAO3.6 are still used in the background in many programs, so there is hope that the problem created by the Windows update will be fixed by Microsoft.
If this doesn’t happen, you will have to find ways to work around the error.
My workaround, more and more, with all the continued issues has been to migrate away from using Access at all. That’s what the past 10+ years of decreasing software quality from Microsoft has taught me.
We have kind of a similar problem, but in a different manner: When calling a MFC C++-DLL (32bit) in Access 365 (2508 Version) that uses MSJet 4.0 (DAO) it crashes with the same entry in the log.
When the DLL is called outside of the Access Environment, it just works without problems. Seems like a scope-problem from where it´s called. The only option is to uninstall the Windows Update.
Bonjour,
Le problème provient effectivement d’Access (32 bits, O365, 2019)
Le code suivant est en échec :
(err=-2147417848 error= Erreur Automation, l’objet invoqué s’est déconnecté de ses clients)
MAIS FONCTIONNE parfaitement sous Excel et Word !!
Public Function Get_Sage30_Transactions1() As String
Dim ADOConn As Object ‘ADODB.Connection
Dim ADORecSet As Object ‘ADODB.Recordset
Dim Sage30_DB As String
On Error Resume Next
Sage30_DB = “C:\temp\wz_Etude.mdb”
Set ADOConn = CreateObject(“ADODB.Connection”)
ADOConn.Open “Provider=Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Engine Type=4;Data Source=” & Sage30_DB
Set ADORecSet = CreateObject(“ADODB.Recordset”)
With ADORecSet
.Source = “Select * From Transactions1 Order by Counter”
.LockType = 3 ‘3=adLockOptimistic
.CursorType = 1 ‘1=adOpenKeyset (0=adOpenForwardOnly, 2=adOpenDynamic, 3=adOpenStatic )
.CursorLocation = 3 ‘3= adUseClient (autrement Read-Only) , (2=adUseServer)
ADORecSet.Open , ADOConn
If Err 0 Then
‘err=-2147417848 error= Erreur Automation, l’objet invoqué s’est déconnecté de ses clients.
MsgBox “Echec recordset” & vbCrLf & Err & vbCrLf & Error
End If
End With
ADORecSet.Close
End Function
Here too!
Older VB program now crashed with KB5064081 installed and shows reverence to ucrtbase.dll version 10.0.26100.5074 updated by this update.
After removing the update, it works again.
Thank you for the information. I’ve passed it along to MS.
Microsoft has updated “ucrtbase.dll” to version 10.0.26100.6899 in the new KB5068835 update.
Unfortunately, this does not solve the problem. On computers where the error occurred with updates KB5064081 and KB5065426, it still occurs even after the latest update.
It is noticeable that “ucrtbase.dll” received an update with KB5068835, but “dao360.dll” did not.
At the moment, uninstalling the update is the only option for us, even with KB5068835.