VBA code crashes after installing KB5064081 update

I have the same problem on several computers with Win11 and KB5064081. Different Access versions, but only 32-bit Access/Office.
My workarounds found until now (while still using ADO):
  • Use ACE provider "Microsoft.ACE.OLEDB.12.0" instead of "Microsoft.Jet.OLEDB.4.0"
  • Uninstall KB5064081
My test program to reproduce the error:

Code: 
Public Sub test1()
   Dim FileName: FileName = CurrentProject.Path + "\empty.mdb"
   Dim conn As ADODB.Connection
   Set conn = New ADODB.Connection
   conn.Provider = "Microsoft.Jet.OLEDB.4.0"
   conn.Properties("Data Source") = FileName
   conn.Open
   Const sql = "select 1 as v1"
   Dim rs As ADODB.Recordset
   Set rs = conn.Execute(sql, , adCmdText)
   MsgBox "Value=" & rs!v1.Value
End Sub

empty.mdb is a newly created empty database.
In this example, the error occurs when the VBA code calls Connection.Execute().
I tried other variants to open the recordset, other SQL statements, etc. all without success.
I also tried to install the Microsoft Access Database Engine 2016 Redistributable, but that didn't replace msjtes40.dll.

I reported the error via the Feedback Hub: aka.ms/AAxs979
Please upvote there.
 
Last edited:
Thanks @christian.dheureuse and welcome to AWF

I've tried your code with both OLEDB.4.0 and 12.0 using A365 v2509 19225.20000 64-bit but still get error 3706 on the Provider line
I'm reluctant to spend time reinstalling the drivers for 64-bit as the 2016 Redist no longer seems to be available and should no longer be needed anyway.
 
It's yet another reminder that distancing myself from Microsoft products—however challenging—is the right move. I genuinely sympathize with developers still in the trenches, producing commercial software, only to be blindsided when Microsoft breaks something and the client blames them. I've been there: countless hours lost patching broken code caused by careless updates and inadequate testing, often at the expense of time with family. That chapter's closed. Never again.
 
I've now done some more testing in both 32-bit & 64.bit Access 365

32-bit
The code works using OLEDB.4.0 with both .mdb and .accdb files.
In both cases, it fails with OLEDB.12.0

64-bit
Both sets of code fail with both .mdb and .accdb destination files

I agree with @tvanstiphout that this is based on old technology. It hasn't been updated in at least 22 years
My suggestion is also that its time to update the code so that it is based on either DAO or DDL.

At the moment, based on the incomplete information I have so far from the OP, its not a bug that I'm willing to pass on to the Access team.
They have plenty to do based on code for versions that are currently supported.
 
Sorry, I made a mistake with the 32/64 bit Access versions. I only tested with 32-bit versions of Access.
I tested with:
  • Access 365 v2507 19029.20208 32-bit.
  • Access Runtime 365 16.0.19127.20154, 32-bit.
  • Access Runtime 2010 32.bit. (Still in use for a very large old Access Project application for a very small client company.)

isladogs said:
32-bit
The code works using OLEDB.4.0 with both .mdb and .accdb files.
In both cases, it fails with OLEDB.12.0
Click to expand...

Did you test with version 10.0.26100.5074 of C:\Windows\SysWOW64\msjtes40.dll?
Powershell command to display the DLL version:

Code: 
(Get-Item "C:\Windows\SysWOW64\msjtes40.dll").VersionInfo.FileVersion

When you write "OLEDB.4.0", do you mean provider "Microsoft.Jet.OLEDB.4.0"?
And by "OLEDB.12.0", you mean provider "Microsoft.ACE.OLEDB.12.0"?

.accdb files cannot be opened with Jet. How could you open an .accdb data source with OLEDB.4.0?

When the error (0xc0000005 exception in msjtes40.dll) occurs, Access is terminated without displaying any error message. The error is only visible in the Windows application event log.
 
Last edited:
NikBab said:
Since this seems to be a problem that occurred due to Windows update (particularly msjtes40.dll), is there a way to report it directly to Microsoft so that -hopefully :)- a fix could be released in future updates?
Click to expand...

hurry up you only have a month to inform:

"Support for Microsoft Office 2016 ends on October 14, 2025. After this date, Microsoft will no longer provide security updates, bug fixes, or technical support for Office 2016. Continuing to use Office 2016 after this date will leave your devices vulnerable to security risks, potentially leading to security breaches, productivity losses, and compliance issues. It is highly recommended to migrate to a supported version of Office, such as Microsoft 365, to ensure continued security and support".
 
christian.dheureuse said:
Sorry, I made a mistake with the 32/64 bit Access versions. I only tested with 32-bit versions of Access.
I tested with:
  • Access 365 v2507 19029.20208 32-bit.
  • Access Runtime 365 16.0.19127.20154, 32-bit.
  • Access Runtime 2010 32.bit. (Still in use for a very large old Access Project application for a very small client company.)



Did you test with version 10.0.26100.5074 of C:\Windows\SysWOW64\msjtes40.dll?
Powershell command to display the DLL version:

Code: 
(Get-Item "C:\Windows\SysWOW64\msjtes40.dll").VersionInfo.FileVersion

When you write "OLEDB.4.0", do you mean provider "Microsoft.Jet.OLEDB.4.0"?
And by "OLEDB.12.0", you mean provider "Microsoft.ACE.OLEDB.12.0"?

.accdb files cannot be opened with Jet. How could you open an .accdb data source with OLEDB.4.0?

When the error (0xc0000005 exception in msjtes40.dll) occurs, Access is terminated without displaying any error message. The error is only visible in the Windows application event log.
Click to expand...
Mine is 10.0.26100.5074 after the update, which you would expect (hopefully). :)
 
@christian.dheureuse
Thanks for picking up the ambiguities in my previous reply.

As stated back in post #2, I do not have Windows 11 available
I tested in 365 version 2509 build 19225.20000 32-bit and 64-bit with Windows 10

The version of msjtes40.dll is 4.0.9801.0

I may have forgotten to change to ACE for version OLEDB.12.0 so I've just retested

64-bit Access
Both sets of code from post #1 and #21 fail with provider Microsoft.Jet.OLEDB.4.0
Both sets of code work using Microsoft.ACE.OLEDB.12.0.

32-bit Access
Both sets of code work with both Microsoft.Jet.OLEDB.4.0 and Microsoft.ACE.OLEDB.12.0.
The code from post #21 only works with .mdb files giving an unrecognized database format for .accdb
However, the code from post #1 works with both .mdb AND .accdb files

As @arnelgp pointed out, Access 2016 / 2019 will both reach end of support on 14 Oct
Users will not be able to download new versions after that date including those updates with fixes to bugs reported before that deadline.

I would again suggest this is the time to replace the old ADOX code with DAO or DDL
 
isladogs said:
@christian.dheureuse
Thanks for picking up the ambiguities in my previous reply.

As stated back in post #2, I do not have Windows 11 available
I tested in 365 version 2509 build 19225.20000 32-bit and 64-bit with Windows 10

The version of msjtes40.dll is 4.0.9801.0

I may have forgotten to change to ACE for version OLEDB.12.0 so I've just retested

64-bit Access
Both sets of code from post #1 and #21 fail with provider Microsoft.Jet.OLEDB.4.0
Both sets of code work using Microsoft.ACE.OLEDB.12.0.

32-bit Access
Both sets of code work with both Microsoft.Jet.OLEDB.4.0 and Microsoft.ACE.OLEDB.12.0.
The code from post #21 only works with .mdb files giving an unrecognized database format for .accdb
However, the code from post #1 works with both .mdb AND .accdb files

As @arnelgp pointed out, Access 2016 / 2019 will both reach end of support on 14 Oct
Users will not be able to download new versions after that date including those updates with fixes to bugs reported before that deadline.

I would again suggest this is the time to replace the old ADOX code with DAO or DDL
Click to expand...
Hello,

Forgive me for the late reply to your posts!
I didn't mean to be rude!

I have replaced Microsoft.Jet.OLEDB.4.0 with Microsoft.ACE.OLEDB.12.0 and it is working fine
Please see the modified code and a screenshot of code execution
I have one more question: do I need to include additional references for using OLEDB.12.0?

Thank you very much!

Code: 
Public Sub CreateTable(strPath As String)
Dim cnn As ADODB.Connection
Dim cat As ADOX.Catalog
Dim tbl As ADOX.Table
Dim idx As ADOX.Index
Dim flag As Boolean

Set cat = New ADOX.Catalog
cat.Create "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & strPath
Set tbl = New ADOX.Table
With tbl
    .Name = "Products"
    .columns.Append "Id", adInteger
    .columns.Append "No", adInteger
    .columns.Append "Percentage", adSingle
    .columns.Append "Code", adVarWChar, 50
    Set .ParentCatalog = cat
    .columns("Id").Properties("Default") = 0
    .columns("No").Properties("Autoincrement") = True
    .columns("Percentage").Properties("Default") = 100
    .columns("Percentage").Properties("Nullable") = False
    .columns("Code").Properties("Jet OLEDB:Allow Zero Length") = False
End With
cat.Tables.Append tbl
Debug.Print tbl.columns("Id").Properties("Default")
Debug.Print tbl.columns("Percentage").Properties("Default")
Set tbl = Nothing
Set cat = Nothing

End Sub

code_execution.png
 
NikBab said:
I have one more question: do I need to include additional references for using OLEDB.12.0?
Click to expand...
it is already working as you said, so obviously no need to add any Reference (reference already in placed).
 
NikBab said:
I have one more question: do I need to include additional references for using OLEDB.12.0?
Click to expand...

Actually better than that - you can now remove the old Microsoft Jet and Replications Objects 2.6 Library as its no longer needed

To run both sets of code I just needed these references:

1756892427791.png


Suggest you mark this thread as solved.
 
christian.dheureuse said:
empty.mdb is a newly created empty database.
In this example, the error occurs when the VBA code calls Connection.Execute().
I tried other variants to open the recordset, other SQL statements, etc. all without success.
Click to expand...
it is a New db obviously there is no table yet on it so your conn.Execute will not work.
 
equivalent code using DAO:

Code: 
Public Sub CreateTable(strPath As String)

    Dim db As DAO.Database
    Dim td As DAO.TableDef
    Dim fld As DAO.Field
    
On Error GoTo Err_handler
    ' check if the database exists
    If Len(Dir$(strPath)) = 0 Then
        ' databas does not exists, create it
        Set db = DBEngine.CreateDatabase(strPath, dbLangGeneral, dbVersion150)
        
    Else
        ' use the database
        Set db = OpenDatabase(strPath)
    End If
    
    ' create the table
    Set td = db.CreateTableDef("Products")
    
    ' create ID field
    Set fld = td.CreateField("ID")
    With fld
        .Type = dbLong
        .DefaultValue = 0
    End With
    ' append field to table
    td.Fields.Append fld
    
    ' create No field
    Set fld = td.CreateField("No")
    With fld
        .Type = dbLong
        .Attributes = dbAutoIncrField
    End With
    
    ' append field to table
    td.Fields.Append fld
    
    ' create Percentage field
    Set fld = td.CreateField("Percentage")
    With fld
        .Type = dbSingle
        .DefaultValue = 100
        'nullable = No
        .Required = True
    End With
    
    ' append field to table
    td.Fields.Append fld
    
    ' create Code field
    Set fld = td.CreateField("Code")
    With fld
        .Type = dbText
        .Size = 50
        .AllowZeroLength = False
    End With
    
    ' append field to table
    td.Fields.Append fld
    
    ' append table to our database
    db.TableDefs.Append td
        
    db.Close
    
Exit_Here:
    Set fld = Nothing
    Set td = Nothing
    Set db = Nothing
    Exit Sub
    
Err_handler:
    ' show the error
    MsgBox Err.Number & "-" & Err.Description
    Resume Exit_Here
End Sub
 
My conclusion is:
  • The error is in version 10.0.26100.5074 of C:\Windows\SysWOW64\msjtes40.dll (32-bit).
  • This version of the DLL is installed by the August 29 Windows 11 update KB5064081.
  • The DLL is used when Access is 32-.bit and the ADO provider is "Microsoft.Jet.OLEDB.4.0".
  • It's a low level crash within that DLL (Exception 0xc0000005, memory access violation).
    Such low level errors can sometimes be exploited as security leaks.
  • When the error occurs, Access is terminated without an error message. The error details are only visible in the Windows application log.
    Microsoft must currently be getting many crash reports for this error.
 
Last edited:
starting from Access 2007, connection string has shifted to Ace.Oledb.12.
 
christian.dheureuse said:
I'm new to this forum, but I'm disappointed. Why are all the experts here responding with appeasement instead of taking this severe error seriously?
Click to expand...
i am serious with my answer and what is your problem?!

recommendations have already been given to the OP.
and this came from CoPilot:

The recommended replacement for Microsoft.Jet.OLEDB.4.0 is:
✅
This provider is part of the Access Database Engine (ACE) and offers several advantages:

🔧 Key Benefits​

  • Supports both 32-bit and 64-bit environments — unlike Jet, which is 32-bit only.
  • Compatible with newer Office formats — including .accdb and .xlsx.
  • Actively maintained — ACE is still supported and updated by Microsoft.
 
christian.dheureuse said:
I'm new to this forum, but I'm disappointed. Why are all the experts here responding with appeasement instead of taking this severe error seriously?
Click to expand...

Because after several posts, it is clear that the failing code library is quite old, to the point of being obsolete, and that a relatively simple workaround exists.

IF this were a new version of some library, new enough that it wasn't going out of support anytime soon, there might be a different response. But as ArnelGP points out, that particular version is going off life-support soon and thus our window of getting MS involved is closing fast.

We can get very theoretical, very technical, even esoteric here. But there is also "practical" and I think that is what is dominating our responses for this thread. Right now, the idea of interesting MS in fixing that bug is a "don't hold your breath while waiting" case.

To me, it is a clear case of some code in the faulting module not having error handling AND not pre-checking parameters. Either one would catch the problem, but neither happened.
 
christian.dheureuse said:
I'm new to this forum, but I'm disappointed. Why are all the experts here responding with appeasement instead of taking this severe error seriously?
Click to expand...
I took it very seriously and spent a lot of time testing both sets of code on 2 different machines.
If the issue had affected the 'newer' OLEDB.12.0 provider as well, I would have reported it to the Access team as an issue needing attention.
Anyone using A2007 or later should be using that provider instead which, as already stated, does work with both 32-bit & 64-bit Access

So the issue should only affect the very small minority of users running ADOX code in A2003 or earlier under Windows 11 (if that is possible).
Bearing in mind that A2003 hasn't been supported for well over 10 years and that 2016/2019 won't be supported after 14 Oct, there are far more serious issues to worry about.

However I have already added it as the first item in my draft article about Access bugs for Sept 2025.

1756915885567.png
 
You must log in or register to reply here.

Similar threads

G
How do I diagnose Access repeatedly crashing ?
Replies
11
Views
4,248
The_Doc_Man
The_Doc_Man
P
Export to Excel not working after SetAccessWindow code
Replies
4
Views
1,498
isladogs
isladogs
Steve R.
Using ADOX to Create/Modify Tables in SQL Server
Replies
1
Views
3,626
Steve R.
Steve R.
Frothingslosh
  • Locked
Import Excel Data into Access via VBA
Replies
8
Views
67,218
Frothingslosh
Frothingslosh
M
alter odbc backend
Replies
5
Views
1,745
mikeo1313
M

Users who are viewing this thread

Total: 1 (members: 0, guests: 1)
Back
Top Bottom