VBA code crashes after installing KB5064081 update (4 Viewers)

[christian.dheureuse]

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).

Thanks, but it's not only ADOX but also simple ADO (see #21).
And the bug also occurs with the newest Access 365 (32-bit) under Windows 11 (with the newest update) and probably with other VBA code (Excel, Word) or other programming environments using ADO and Jet (i.e. provider "Microsoft.Jet.OLEDB.4.0").
And there is a risk that such a bug can be exploited as a security leak, because it's a low-level access violation exception within a DLL that is installed by default in the Windows 11 OS.

 

[isladogs]

It doesn't matter whether it’s ADO or ADOX. The main point is that you should be using Microsoft.ACE.OLEDB.12.0 with which there are no issues.

 

[isladogs]

Just to say I have now reported the issue direct to the Access team (with a link back to this thread) so that they can decide whether its important enough to fix

 

[NikBab]

Hello,

I just found that even the following piece of code causes the application to crash in the same manner:

    Set cnn = New ADODB.Connection
    cnn.open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=<path-tofile>"
 
    Set rs = New ADODB.Recordset
    rs.open "SELECT aCol FROM tbl", cnn, options:=adCmdText
    rs.Close
    Set rs = Nothing
  
    cnn.Close
    Set cnn = Nothing

The crash occurs on the following statement:

rs.open "SELECT aCol FROM tbl", cnn, options:=adCmdText

Windows event viewer reports the following error

Faulting application name: MSACCESS.EXE, version: 16.0.4266.1003, time stamp: 0x55ceaf3e
Faulting module name: msjtes40.dll, version: 10.0.26100.5074, time stamp: 0x5eef5084
Exception code: 0xc0000005
Fault offset: 0x0001e150
Faulting process id: 0x390
Faulting application start time: 0x1DC1D93103AD5D8
Faulting application path: C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE
Faulting module path: C:\Windows\System32\msjtes40.dll
Report Id: 6ca2d1fc-95ab-4f5e-b687-b8ca0253d34b
Faulting package full name:
Faulting package-relative application ID:

 

[isladogs]

Presumably its crashing on the same line and also that using the newer OLEDB.12.0 code works.
Even if MS do decide to fix it, I'd still change to the newer version throughout your code

 

[NikBab]

Presumably its crashing on the same line and also that using the newer OLEDB.12.0 code works.
Even if MS do decide to fix it, I'd still change to the newer version throughout your code

Yes, that is correct...the code works with the newer OLEDB.12.0 provider
However, since as I already mentioned it is a rather large codebase, I would like to defer having to perform this change to the newer provider at least right now

 

[isladogs]

Why?
You can do a simple find and replace on the entire project code. It will take no more than a few seconds to do.

 

[NikBab]

The truth is that I am afraid of new bugs that may occur due to this change.
So far, the application has been adequately tested as is and introducing such an extended change requires thorough testing not to break things that work well at this moment

 

[isladogs]

I very much doubt MS will spend time fixing the issue with the older version but I may be wrong about that.

Just make a copy and apply the changes.
Test it then release.
What’s the problem?

 

[NikBab]

The problem is that the application is a bit complex and an extensive test suite is needed before releasing it.
This requires quite a lot of time time which frankly I would rather spend in developing the new version which is already under way but not completed.
So, the best case scenario for me would be to provide a quick fix to existing customers without having to waste too much time.

 

[isladogs]

There is no guarantee that MS will fix the issue with this very ancient file, especially when there is a newer version that works perfectly. The time needed to make these code changes is literally seconds.

Personally I would recommend you just get on with making the changes needed especially as A2016 will no longer receive support of any kind including bug and security fixes after 14 Oct … not even for bugs reported before that date.

 

[christian.dheureuse]

There is no guarantee that MS will fix the issue with this very ancient file

It's clearly a software regression type of bug.

And it's not an ancient file.

The newest Windows 11 update KB5064081 has replaced the DLL file C:\Windows\SysWOW64\msjtes40.dll with a new version.

The old version was:

2024-04-01 09:22 290,816 msjtes40.dll Version 4.00.9801.0

The new version is:

2025-09-01 21:11 163,840 msjtes40.dll Version 10.0.26100.5074

As NikBab has explained, for some of us longtime developers it's not possible to just switch to ACE. This is due to various constraints and dependencies. These dependencies are ugly but they are a reality and our daily business. For one of my clients, I have to maintain a very large old Access Project (ADP) application that is only used in-house by two users. It would take me about 3 weeks work to adapt that ADP application to Access 365 and the client is not able to finance that (and I have no time capacity to do it). But their small business depends on it. I did that conversion for another client with a similarly large ADP application but with more financial resources. I know how to do it. The problems arise from the circumstances and we as software developers are caught between the needs and resources of our clients/users and the ever-changing software environments.

 

[RonPaii]

It's clearly a software regression type of bug.

And it's not an ancient file.

The newest Windows 11 update KB5064081 has replaced the DLL file C:\Windows\SysWOW64\msjtes40.dll with a new version.

The old version was:

2024-04-01 09:22 290,816 msjtes40.dll Version 4.00.9801.0

The new version is:

2025-09-01 21:11 163,840 msjtes40.dll Version 10.0.26100.5074

As NikBab has explained, for some of us longtime developers it's not possible to just switch to ACE. This is due to various constraints and dependencies. These dependencies are ugly but they are a reality and our daily business. For one of my clients, I have to maintain a very large old Access Project (ADP) application that is only used in-house by two users. It would take me about 3 weeks work to adapt that ADP application to Access 365 and the client is not able to finance that (and I have no time capacity to do it). But their small business depends on it. I did that conversion for another client with a similarly large ADP application but with more financial resources. I know how to do it. The problems arise from the circumstances and we as software developers are caught between the needs and resources of our clients/users and the ever-changing software environments.

If the software is critical for the business and they can't finance an update, then it looks like you will need to roll back the updates causing the problem then lock those computer down to not allow updates. Then to protect them disable the gateway on those computers NIC to keep them off the Internet.

 

[isladogs]

Happy to upload the old version of the file if that helps either of you.

 

[christian.dheureuse]

If the software is critical for the business and they can't finance an update, then it looks like you will need to roll back the updates causing the problem then lock those computer down to not allow updates. Then to protect them disable the gateway on those computers NIC to keep them off the Internet.

I can't take them offline because they sell goods over the Internet to a large customer base. They have been using this ADP application for 21 years, and they will retire in a few years.

I don't want to discuss the details here. I just want to say that it's not as easy to adapt for some of us.

 

[RonPaii]

I can't take them offline because they sell goods over the Internet to a large customer base. They have been using this ADP application for 21 years, and they will retire in a few years.

I don't want to discuss the details here. I just want to say that it's not as easy to adapt for some of us.

The next option would be virtual machines or RDP to 2nd computer.

You could setup a virtual machine on each computer, If the computers are using the Professional version of Windows 7,10,11 and the computers have plenty of memory and a good processor. Lock down the VM and install Access on the VM.

Use RDP, sent-up an old computer for the application, properly locked down. Each user would have 1 of these computers though RDP.