Opening some reports in Access 2010 ADP crashes after KB5064081

[rsocol]

Hello,

After installing the Windows updates published in 29 August 2025 or in 9 September 2025 (KB5064081 or KB5065426, maybe also others), Access 2010 crashes when opening some reports. More specifically, those reports are using a non-standard grouping interval (e.g. month or year) instead of "by entire value". In other words, there is a non-zero value for the GroupOn property of the GroupingLevel object.

In Event Viewer we can see the following details:
Faulting application name: MSACCESS.EXE, version: 14.0.7256.5000, time stamp: 0x5f125152
Faulting module name: msjtes40.dll, version: 10.0.26100.5074, time stamp: 0x5eef5084
Exception code: 0xc0000005
Fault offset: 0x0000f414
Faulting application path: C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE
Faulting module path: C:\Windows\System32\msjtes40.dll

This problem is somewhat similar to the one mentioned in by NikBab in another recent thread on this site. However, I was unable reproduce the problem with a supported version of Access, to report it to Microsoft.

Considering the crash is in MSJTES40.DLL (not in MSACCESS.EXE), I'm still hoping that Microsoft will see the crash reports in the telemetry and develop a fix at some point. Is there any hope for a such a fix in a reasonable timeframe? Or should I redesign those reports avoiding the non-standard grouping interval?

Thanks,
Razvan

 

[GPGeorge]

Given the fact that Access 2010 is long out of support, and that ADPs have been deprecated for a few years, and that the faulting dll is related to JET 4.0, which has been supplanted by ACE, I doubt there's a high likelihood of a fix.

 

[tvanstiphout]

There have been other reports in this forum about that DLL, such as this one so there is a chance the issue is more universal (read: more likely to get fixed) than that property in ADP reports.
I would start with rolling back the latest updates.
And long-term staying with technology that has been DEAD for more than a decade is not a good idea.

 

[rsocol]

It's strange that Microsoft recently updated MSJTES40.DLL, probably to fix a vulnerability, but without documenting that a vulnerability was fixed.

 

[tvanstiphout]

It's strange that Microsoft recently updated MSJTES40.DLL, probably to fix a vulnerability, but without documenting that a vulnerability was fixed.

You're right. I first thought "es" in the filename stood for "Espana", but it is "Expression Service". Mine is v6.2 from 2025-09-09. In an obscure folder is a v4.0 from 2024-04-01.
I think your chances for a fix just went up. If only we could make it crash with current A365.

I just tried, but it is not possible to set a Reference to JET Expression Service Type Library. "Error in loading DLL" will occur.

 

[isladogs]

You're right. I first thought "es" in the filename stood for "Espana", but it is "Expression Service". Mine is v6.2 from 2025-09-09. In an obscure folder is a v4.0 from 2024-04-01.
I think your chances for a fix just went up. If only we could make it crash with current A365.

I just tried, but it is not possible to set a Reference to JET Expression Service Type Library. "Error in loading DLL" will occur.

Following your prompt, I just successfully added the Jet Expression Service Type Library as a reference in 64-bit Access 365:

Perhaps it worked for me because in Win 10, I have an older version v4.00.9801.0 dated 07/12/2019.
There isn't a newer version of the file anywhere else on my system

 

[tvanstiphout]

Following your prompt, I just successfully added the Jet Expression Service Type Library as a reference in 64-bit Access 365:

View attachment 121480

Perhaps it worked for me because in Win 10, I have an older version v4.00.9801.0 dated 07/12/2019.
There isn't a newer version of the file anywhere else on my system

Very curious. DLLs in the SysWow64 folder are usually 32-bit (on 64-bit Windows).
I was using 32-bit Access for my test, and selected the one in SysWow64. Just for grins I also tried the one in the system32 folder (which should be 64-bit), and got "Can't add a reference to the specified file". I don't have 64-bit A365 handy here.

 

[Gasman]

I have two versions on my computer.
The syswow folder has the 5074 version. I am on 32bit Access.
I seem to recall I could recreate the issue that was mentioned in that other thread after I applied the update that caused it.

 

[isladogs]

Very curious. DLLs in the SysWow64 folder are usually 32-bit (on 64-bit Windows).
I was using 32-bit Access for my test, and selected the one in SysWow64. Just for grins I also tried the one in the system32 folder (which should be 64-bit), and got "Can't add a reference to the specified file". I don't have 64-bit A365 handy here.

Yes I agree about SYSWOW64.

However I repeated the test on 32-bit Access in 64-bit Win 10
Again the only (non-archived) copy of the msjtes40.dll file was in the SYSWOW64 folder and was the same version v4.00.9801.0 dated 07/12/2019.
Once again, the reference library loaded without error.

Not only that, it is in the reference list in both bitness of Access. I don't even have to browse for it!

@Gasman
As I expect you noticed, you are getting duplicate entries for each copy of the .dll
You didn't say whether you could load the file as a reference.

 

[Gasman]

As I expect you noticed, you are getting duplicate entries for each copy of the .dll

Yes, I have asked the developer of Eveything as to why, as it is not a duplicate of every file in the list.
In this case it actually is, but with other searches, it is not the case.

Edit: Just had a response from the developer David Carpenter.

NTFS volumes are automatically indexed by "Everything".
Adding a NTFS volume as a folder index will show duplicated results.
Please remove any NTFS volumes from your folder indexes:

In "Everything", from the Tools menu, click Options.
Click the Folders tab.
Select any NTFS volumes and click Remove.
Click OK.

To check which NTFS volumes are automatically included:

In "Everything", from the Tools menu, click Options.
Click the NTFS tab.
NTFS volumes that have Include in database checked are already included as a NTFS index.

 

[sonic8]

Again the only (non-archived) copy of the msjtes40.dll file was in the SYSWOW64 folder and was the same version v4.00.9801.0 dated 07/12/2019.
Once again, the reference library loaded without error.

Exactly the same here if I look for the DLL using Windows Explorer or Everything.
However, if in Access (2010 and 365CC, 32bit) VBA, I use the "Browse" button to add a reference and navigate to C:\Windows\System32, I also see this file there! ?
If I try to actually add the DLL from System32 to the references, I don't get any error message but the DLL is not added.
Adding the DLL from the SysWow64 folder does work.

 

[isladogs]

Exactly the same here if I look for the DLL using Windows Explorer or Everything. However, if in Access (2010 and 365CC, 32bit) VBA, I use the "Browse" button to add a reference and navigate to C:\Windows\System32, I also see this file there! ? If I try to actually add the DLL from System32 to the references, I don't get any error message but the DLL is not added. Adding the DLL from the SysWow64 folder does work.

I can replicate that also but only in 32-bit Access with 64-bit Windows.
None of the msj*.dll files shown below appear when viewed in File Explorer

I think the reason is that there is actually only one copy of these files and that registry redirection is involved in a mixed bitness system which gives the impression of there being two separate files. Its a complicated subject and I may not have the details exactly correct.
For more details, see:

Registry Redirector - Win32 apps

The registry redirector isolates 32-bit and 64-bit applications by providing separate logical views of certain portions of the registry on WOW64.

learn.microsoft.com

Accessing an Alternate Registry View - Win32 apps

By default, a 32-bit application running on WOW64 accesses the 32-bit registry view and a 64-bit application accesses the 64-bit registry view.

learn.microsoft.com

 

[sonic8]

I think the reason is that there is actually only one copy of these files and that registry redirection is involved in a mixed bitness system which gives the impression of there being two separate files.

I think, you confused registry redirection and file system redirection. Apart from that you are spot on!

Quote from File System Redirector:

In most cases, whenever a 32-bit application attempts to access %windir%\System32, [...] the access is redirected to an architecture-specific path.

 

[The_Doc_Man]

In other operating systems, what you are describing is sometimes called a "File Alias" - where you have a directory entry for the same file in two different directories. One of them is the "original" entry and one of them is the "alias." The danger is that deleting the file through one entry doesn't delete the other entry - but it will no longer work correctly.

 

[isladogs]

I think, you confused registry redirection and file system redirection. Apart from that you are spot on!

Quote from File System Redirector:

That was me dredging up long buried memories. In one sense close.... but in another completely wrong.

In other operating systems, what you are describing is sometimes called a "File Alias" - where you have a directory entry for the same file in two different directories. One of them is the "original" entry and one of them is the "alias." The danger is that deleting the file through one entry doesn't delete the other entry - but it will no longer work correctly.

In Windows, that is just a shortcut! Delete the shortcut...the file still works but of course the reverse isn't true