VBA code crashes after installing KB5064081 update (1 Viewer)

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