Our SSIS process has been running reliably for over two years without any issues. However, starting in August 2025, we began encountering a consistent crash when loading large Excel (.xlsx) files using the Microsoft.ACE.OLEDB.16.0 driver. The crash occurs midway through the SSIS execution—log output stops abruptly—and each time, a COM+ error is thrown. Please refer to the attached screenshot from the Windows Application Logs in Event Viewer for details. Key observations: The issue only affects large Excel files. No changes have been made to our SSIS packages or the ACE OLEDB driver. System resources (CPU and memory) remain stable during execution. The SharedSection parameter in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows shows no changes to desktop heap. The problem began after recent Windows updates early August 2025, though we are unsure which specific patch introduced the issue. (Our last successful run of the same SSIS package was 7/29/2025. As it's a weekly process, our first occurrence of the SSIS COM+ error was 8/12/2025) We suspect a recent Windows patch may be causing this SSIS crash. Could Microsoft investigate this regression?

Installing MS 365 Access Runtime maybe fixed it: tldr: Installing MS 365 Access Runtime worked for us We are exporting data from our database and ran into the same com+ error. We tried to resolve the issue by uninstalling Access Runtime 2016, installing 2013 since 2010 was not available and then installing 2016 again, suggested by @Frazell Thomas . Since this unfortunately did not work for us, and since we could not find the 2010 version we tried what @Yorley García was suggesting in a comment and installed the MS 365 Access Runtime . This seemed to work for a specific testcase that previously failed. We are currently checking if it works for us in every scenario. I found a Question regarding the end of life for Access DB Engine 2016 that lead to this article wich suggests that if no office is installed, the MS 365 Access Runtime should be installed. I am somewhat optimistic, that hopefully installing this runtime wich includes the Access Database Engine could be neccessary either way after the end of life for the 2016 Access Database Engine and might not be a workaround but a solution that will not be broken in the future. If you have further knowledge or one of my assumptions is incorrect please feel free to leave a comment.

I can confirm, at least for us, that uninstalled the Access Runtime 2016 and installing Microsoft 365 Access Runtime resolved the issue. Uninstalling 2016 removed both the Microsoft.ACE.OLEDB.12.0 and Microsoft.ACE.OLEDB.16.0 providers and installing the 365 version replaced them both. I noticed right away that my queries ran faster than they had been over the past week and the Complus errors have not occurred once. Crossing fingers, but at least for tonight, I can sleep.

In our environments, the issue started on August 13 and, without any action on our side, it appears to be working again today. Could you please check in your environments and confirm whether the problem has been resolved or if you are still experiencing it?

And nothing worked for us. We did the following: Installed/uninstalled M365 32-bit runtime Installed/uninstalled 2010 and 2016 runtime Installed/uninstalled 2013 runtime (32- and 64-bit) The only thing that sort-of works is installing the M365 64-bit runtime. It will work (slowly) for smaller exports, but bombs out on larger ones. I'm going to go back to MS with this and see what they suggest.

Problem: Using ACE OLEDB 12 all the datatransfer from an Access Database to a SQL Database became super slow suddenly. UnInstalling the 2010 Access Database Engine and Installing the 2013 Access Runttime worked for us. After installing the Access Runtime 2013 it enabled/added ACEOLEDB 15 to our SQL Server which added a ACE OLEDB 15.0 provider, we used this 15 provider to add the LinkedServer to access the AccessDatabase. This fixed our issue and also improved the performance quite a bit. Still we don't know which patch/release is causing this, would be great if someone knows

SSIS (DTExec.exe) Complus (COM+) Error with Large Excel Files Since August 2025 Patches

Cheng Wang 120

Our SSIS process has been running reliably for over two years without any issues. However, starting in August 2025, we began encountering a consistent crash when loading large Excel (.xlsx) files using the Microsoft.ACE.OLEDB.16.0 driver.

The crash occurs midway through the SSIS execution—log output stops abruptly—and each time, a COM+ error is thrown. Please refer to the attached screenshot from the Windows Application Logs in Event Viewer for details.

Key observations:

The issue only affects large Excel files.
No changes have been made to our SSIS packages or the ACE OLEDB driver.
System resources (CPU and memory) remain stable during execution.
The SharedSection parameter in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows shows no changes to desktop heap.
The problem began after recent Windows updates early August 2025, though we are unsure which specific patch introduced the issue. (Our last successful run of the same SSIS package was 7/29/2025. As it's a weekly process, our first occurrence of the SSIS COM+ error was 8/12/2025)

We suspect a recent Windows patch may be causing this SSIS crash. Could Microsoft investigate this regression?

User's image

ABannister 0 Reputation points

2025-08-13T15:43:19.9666667+00:00

We upgraded 1 of our 2 SQL servers to Server OS 2022, whereupon July updates applied after updates and now we are experiencing this issue with SSIS jobs running between the SQL servers.
Sean Smith 20 Reputation points

2025-08-13T15:45:56.4266667+00:00

We're running Windows Server 2019/SQL Server 2017.
Sean Smith 20 Reputation points

2025-08-13T17:02:33.3066667+00:00

Alright - so something changed in or around SSIS, but KB5062557 isn't the culprit.

We're still encountering issues. It would be nice if someone from Microsoft could give us a hand here...

Yorley García 10

Hi!, it affects Blue Prism application any interaction OLEDB ACE 16 to query excel files, it is slowed to even some cases 15 minutes on very small excel files less than 50 rows in some cases.
using something like this:

Private moConnection As OLEDBConnection 

''-For Opening a Connection (Lasts at least more than 50 secs)
If moConnection Is Nothing 
Then moConnection = New OLEDBConnection(ConnectionString) 
moConnection.Open() 
End If

''For closing use this method (last at least more than 30 seconds)
moConnection.Close() 
moConnection.Dispose() 
moConnection = Nothing

Sean Smith 20 Reputation points

2025-08-13T20:11:20.46+00:00

When I look in Event Viewer, I'm seeing the following error:

The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below.

Component Prog ID: DSODispenser

Method Name: IDispenserDriver::DestroyResource

Process Name: sqlservr.exe

Exception: c0000005

Address: 0X00007FF8E15D5642

I opened a ticket with MS through M365, so I don't know if I'll get a response. If I do, I'll post it here.
Sean Smith 20 Reputation points

2025-08-13T20:13:11.47+00:00

I'm seeing the following error message in Event Viewer when exports start failing:

The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below.

Component Prog ID: DSODispenser

Method Name: IDispenserDriver::DestroyResource

Process Name: sqlservr.exe

Exception: c0000005

Address: 0X00007FF8E15D5642

I've opened a ticket with MS through M365, so I don't know if they'll respond. If they do, I'll post it here.
Erland Sommarskog 124.9K Reputation points MVP Volunteer Moderator

2025-08-13T21:15:08.99+00:00

We suspect a recent Windows patch may be causing this SSIS crash. Could Microsoft investigate this regression?

If you want Microsoft to investigate this, you should open a support case. This forum is not a support forum, but a peer-to-peer forum. (Well, to be precise, when it comes to SQL Server on-prem it is. If you are in Azure and have a development support plan, Microsoft Q&A is indeed the venue for support.)
Sean Smith 20 Reputation points

2025-08-13T21:31:58.83+00:00

I did, and I'm waiting for a response.
C Laxdal 0 Reputation points

2025-08-14T01:22:03.7633333+00:00

We are getting the same error running SSIS packages that connect to Excel files using Visual Studio 2017. We believe it is due to a Microsoft 365 update installed on 8/12/2025 (see below). Our packages use "Provider=Microsoft.ACE.OLEDB.12.0" to connect to Excel files.

We used "PackageA.dtsx" to load "ExcelFileA.xlsx" on 8/11/2025 and it worked normally. After the patch was applied on 8/12/2025, we can no longer use PackageA.dtsx to load ExcelFileA.xlsx. As of now, we cannot import xlsx files of any size using SSIS. I tried creating a new package from scratch and it didn't work either. In each case, the package starts but never completes, and clicking on Visual Studio brings the "Visual Studio is not responding" error message. We see the same error in the Windows Application Event Log:

The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below.

Component Prog ID: DSODispenser

Method Name: IDispenserDriver::DestroyResource

Process Name: devenv.exe

Exception: c0000005

Address: 0X5294E436

The only updates installed on 8/12/25 were
Cheng Wang 120 Reputation points

2025-08-14T01:43:43.61+00:00

On our Windows Server 2019, Office or Microsoft 365 is not installed. The driver we’re using in SSIS — Microsoft.ACE.OLEDB.16.0 — does not require Excel to be present on the system.
David Kühnemann 105 Reputation points

2025-08-14T14:31:29.6166667+00:00

We are currently experiencing the same error when trying to import data from Access databases into a sql server.
The first occurence of this error was 8/12/2025 for us.
Carlos Oliveira 0 Reputation points

2025-08-14T21:01:59.4466667+00:00

Guys I had the same problem. To solve I unstall the office and install the 365 version, and then worked fine
Anucha Patthanajan 0 Reputation points

2025-08-15T03:17:33.4+00:00

I had same problem too, but on my server no office installed have only Microsoft Access database engine 2016
Sean Smith 20 Reputation points

2025-08-15T19:43:09.2066667+00:00

Frazell:

Did it work as a solution or just as a workaround ie. are exports still slow?

Thanks!

Sean
Frazell Thomas 40 Reputation points

2025-08-15T19:54:42.0233333+00:00

Sean,

It worked as a solution for us. Previously excel interaction was taking a VERY long time and it went back to the standard few seconds.

I only classify it as a workaround as it can be broken by a future patch until the underlying issue is resolved, but for us it is a complete fix.
Ron Kidwell 0 Reputation points

2025-08-15T20:07:12.5133333+00:00

Started having the same problem this week. Not good.
Shun 0 Reputation points

2025-08-17T19:23:47.53+00:00

Frazell: Thank you for sharing the workaround. I followed the steps, but unfortunately, it didn’t work in our case so it may depend on the environment.

Sean: Have you received any response from Microsoft regarding this issue?

Thanks, everyone!
Sean Smith 20 Reputation points

2025-08-18T11:09:55.2433333+00:00

Shun:

Not a peep. They asked for a bunch of information on the 14th, which I provided... then nothing. I'm doing to poke them now.
Shun 0 Reputation points

2025-08-18T13:30:30.2466667+00:00

Sean: Thanks for the update. Hope we can resolve this soon.
Frazell Thomas 40 Reputation points

2025-08-18T14:59:55.3766667+00:00

We also have had some success in our additional testing when removing the 2016 (and if installed for the workaround 2010) runtime and installing the Access 2013 runtime with success. Hopefully this path helps some others who are still impacted.

https://www.microsoft.com/en-us/download/details.aspx?id=39358
Sean Smith 20 Reputation points

2025-08-18T15:05:25.3433333+00:00

Frazell:

32 or 64 bit?
Frazell Thomas 40 Reputation points

2025-08-18T15:15:47.2033333+00:00

Sean, for us it was 64bit, but we're using 64bit versions of Office. I'd imagine it would work the same for 32bit environments.
Zaiger, Marc 0 Reputation points

2025-08-18T20:27:25.4833333+00:00

Can somebody post back when Microsoft responds on best path forward? What I am reading is support for Access Database Engine 16.0 driver ends in October 2025 because Microsoft Office 2016 support ends. Is that true? Also I asked copilot what they recommend to replace this driver and they said to use ODBC driver for Access and Excel. I created simple Access Import and it worked. Has anybody had success with these drivers? For Access and Excel? I would rather not have to update all my sources/destinations in my SSIS packages if not reliable. The ODBC 32-bit drivers might of been installed when SQL Server was installed because they already existed on our environment. Might need to install 64-bit if your using 64 bit. You will need to set your runtime in Agent job and in Visual Studio to 32-bit mode, if using 32 bit drivers.
Sean Smith 20 Reputation points

2025-08-18T20:37:16.01+00:00

Microsoft's response:

Hello Team,

I hope you are doing well.

We understand our customers busy but when you get a chance, please let me know if issue is resolved by the link you shared with us.

Have you tried the steps on the reinstalment suggestions.

1.    Uninstall Access Database Engine 2016

2.    Install Access Database Engine 2010

3.    Install Access Database Engine 2016 while leaving Access Database Engine 2010 installed (effectively upgrading Access Database Engine)

Plan an upgrade from older versions of Office to Microsoft 365 Apps - Microsoft 365 Apps | Microsoft Learn Please let me know if you have any questions

Thank you Kindly.

Best Regards,   Work: + 1425-727-7324 Muna Semon    ******@microsoftsupport.com Microsoft Work Hours: Monday- Friday Big Data Support Engineer M-F: 09:00 AM-06:00 PM PST If you need to work with another Support Engineer outside of my working hours, please send email **azurebu@microsoft.com & sqlmmdt@microsoft.com **with your case number, and availability. We are always interested to hear your feedback. Please feel free to reach my manager Josh Farnsworth ( v-josfar@microsoft.com)
Sean Smith 20 Reputation points

2025-08-18T20:38:08.57+00:00

So, essentially... do what Frazell suggests.

I didn't know about the EOL for 2016... I'll let our coders know we'll have to move off of that.
Erland Sommarskog 124.9K Reputation points MVP Volunteer Moderator

2025-08-18T21:22:55.58+00:00

I can't say that I am impressed by this resolution. But maybe someone else in the thread has a more heavy-duty support contract and can escalate the issue. Somehow, I have the feeling that the suggested resolution is not feasible for everyone.

Myself, I'm only watching this thread from the sidelines, not using SSIS myself.
Audrey Abbey 0 Reputation points

2025-08-19T00:40:09.41+00:00

Microsoft's solution is to install 2010 - but it is no longer available to download. FANTASTIC.
Daniel Müller 0 Reputation points

2025-08-19T04:53:09.54+00:00

At first the reinstallation of 2010 and 2016 didn´t work for us. But then: instead of installing 2016 back again, we used 2013 as Thomas commented and now it "works" again.
Anucha Patthanajan 0 Reputation points

2025-08-19T07:34:57.2566667+00:00

The issued has been solved by override office URL in hosts file.
David Kühnemann 105 Reputation points

2025-08-19T09:38:38.6566667+00:00

@Anucha Patthanajan could you maybe go into a little detail?
I would like to know what you changed to "solve" the issue.
Anucha Patthanajan 0 Reputation points

2025-08-20T01:51:12.4966667+00:00

David Kühnemann i added
0.0.0.0 nexus.officeapps.live.com in to hosts file
Emily H 0 Reputation points

2025-08-20T16:34:28.6133333+00:00

I just wanted to comment that my company has 5 SSIS servers (a random mix of svr2019 and svr2022) that use ACECORE OLEDB with the Access Database Engine 2016 Redistributable x86 and all of them started failing the same day except for one, which continues to work today. The key difference that I can see is related to patching. This server was built in June from a template that hasn't been patched in a while, and when the sysadmins at my company build a new machine with our automation they tend not to go out of their way to patch it and will just let it patch during the next maintenance window. We skipped patching for all machines in June and July for various reasons (that I don't agree with but I'm not one to argue with the PIC), so this new one is still vulnerable and still works. Here is a list of missing patches on that machine, I assume one of them would break it if I installed them today:

Microsoft ODBC Driver for SQL Server 17.10.6.1 - less likely because we use OLEDB but still possible.

Microsoft OLE DB Driver for SQL Server 18.7.4 - more directly correlated by name

KB5054833 - Cumulative Update 32 for SQL Server 2019

And all the following patches related to Office 2016
KB5002340 – The downloaded patch file name for this makes me suspect it as where the problem lives because it’s called ace2016-kb5002340-fullfile-x86-glb
KB5002588 – Similar to above, the file name downloaded is ace2016-kb5002588-fullfile-x86-glb

KB5002623

KB5002575

KB5002573

KB5002636

KB5002469

Here's a full list of every patch executable that is missing on the unaffected server that the others do have installed, only filtered to patches released prior to June, 2025:

NDP481-x86-x64-AllOS_V2.exe

msodll40ui2016-kb5002469-fullfile-x86-glb.exe

ace2016-kb5002340-fullfile-x86-glb.exe

msodbcsql_17.10.6.1_x64.msi

msodll202016-kb5002575-fullfile-x86-glb.exe

msoledbsql_18.7.4_x64.msi

mso2016-kb5002636-fullfile-x86-glb.exe

sqlserver2019-kb5054833-x64.exe

msodll302016-kb5002573-fullfile-x86-glb.exe

ace2016-kb5002588-fullfile-x86-glb.exe

msodll202016-kb5002623-fullfile-x86-glb.exe

So basically my point is that if this was not intended and Microsoft needs to do some RCA and issue a fix, they have a list of patches to look through.

If it was intended... well they really could have done a better job communicating their intent. :)

Anyway, I went ahead and installed Microsoft 365 Access Runtime and production has resumed. Thank you so much for this thread, and specifically to David Kühnemann
Stefano Sotto Corona 10 Reputation points

2025-08-21T10:01:49.5033333+00:00

In our environments, the issue started on August 13 and, without any action on our side, it appears to be working again today. Could you please check in your environments and confirm whether the problem has been resolved or if you are still experiencing it?
Abhiram Munaga 0 Reputation points

2025-08-21T15:09:09.3866667+00:00

Problem: Using ACE OLEDB 12 all the datatransfer from an Access Database to a SQL Database became super slow suddenly.

UnInstalling the 2010 Access Database Engine and Installing the 2013 Access Runttime worked for us.

After installing the Access Runtime 2013 it enabled/added ACEOLEDB 15 to our SQL Server which added a ACE OLEDB 15.0 provider, we used this 15 provider to add the LinkedServer to access the AccessDatabase. This fixed our issue and also improved the performance quite a bit.

Still we don't know which patch/release is causing this, would be great if someone knows

Accepted answer

David Kühnemann 105 Reputation points

2025-08-19T12:01:31.49+00:00

Installing MS 365 Access Runtime maybe fixed it:

tldr: Installing MS 365 Access Runtime worked for us

We are exporting data from our database and ran into the same com+ error.

We tried to resolve the issue by uninstalling Access Runtime 2016, installing 2013 since 2010 was not available and then installing 2016 again, suggested by @Frazell Thomas .

Since this unfortunately did not work for us, and since we could not find the 2010 version we tried what @Yorley García was suggesting in a comment and installed the MS 365 Access Runtime.
This seemed to work for a specific testcase that previously failed.
We are currently checking if it works for us in every scenario.

I found a Question regarding the end of life for Access DB Engine 2016 that lead to this article wich suggests that if no office is installed, the MS 365 Access Runtime should be installed.
I am somewhat optimistic, that hopefully installing this runtime wich includes the Access Database Engine could be neccessary either way after the end of life for the 2016 Access Database Engine and might not be a workaround but a solution that will not be broken in the future.

If you have further knowledge or one of my assumptions is incorrect please feel free to leave a comment.
Please sign in to rate this answer.

6 people found this answer helpful.
Florecente 20 Reputation points

2025-08-19T14:37:47.02+00:00

This solution worked for us. Thank you.

We had 2010 and 2016 driver installed. Removed both and installed 365 driver and that fixed it.

Also worked well with 2013 version after Removing the 2 existing drivers: 2010 and 2016.

David Kühnemann 105 Reputation points

2025-08-19T15:43:41.18+00:00

FYI: In our case uninstalling the 2013 Access Database Engine after installing the MS 365 Access Runtime leads to the OLEDB Driver being unregistered and makes a reinstallation of the MS 365 Access Runtime necessary.

Cheng Wang 120 Reputation points

2025-08-19T15:54:35.3633333+00:00

For those still using the Access Database Engine 2013, please check whether you've upgraded to the Microsoft.ACE.OLEDB.16.0 driver/provider. This driver appears to work seamlessly with the Microsoft 365 Access Runtime, and it's also the recommended solution from Microsoft Support.

I’ve uninstalled the Access 2016 driver and installed the Microsoft 365 Access Runtime on our DEV servers. This resolved an issue I was experiencing when loading a medium-sized Excel file (~12MB, ~100K rows), no more COM+ errors. I’ll continue testing in our DEV environment for a few more days before promoting the change to our production server.

Zaiger, Marc 0 Reputation points

2025-08-19T15:56:45.8366667+00:00

Somebody posted before that it broke linked servers when trying this method. Has anybody tested this?

Sean Smith 20 Reputation points

2025-08-20T12:26:54.2766667+00:00

We tried the solution suggested by David, and it didn't work for us - smaller exports still take longer than expected, and larger ones fail completely. We tried both the 32- and 64-bit M365 Access Runtime. 32-bit failed completely, and 64-bit put us back in our original boat.Next we're going to try the 2010/2016 solution. I'll report back as to whether or not it worked.

And Microsoft still hasn't helped much at all here.

Gianluca Pinelli 0 Reputation points

2025-08-21T07:14:15.08+00:00

We started having problems with Excel tasks with SSIS (VS 2019) on August 13 (the jobs had always worked before, and had been in production for about three years).

The server was last updated in May 2025.

The installed provider was Access Database Engine 2016.

ETL tasks with access to Excel files started to freeze without returning any errors.

(It should also be noted that we did not encounter any problems with small files).

We first tried reinstalling Access Database Engine 2016.

This was unsuccessful.

We then followed David's suggestion, uninstalled Access Database Engine 2016, and installed Microsoft 365 Access Runtime.

The problem was magically resolved, and we also noticed a marked improvement in both validation and execution times for Excel tasks.

The question remains as to what could have caused this problem.

Microsoft, are you there?

--
Gianluca
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

12 additional answers

Ron Kidwell 0 Reputation points

2025-08-20T20:50:00.8433333+00:00

I can confirm, at least for us, that uninstalled the Access Runtime 2016 and installing Microsoft 365 Access Runtime resolved the issue.

Uninstalling 2016 removed both the Microsoft.ACE.OLEDB.12.0 and Microsoft.ACE.OLEDB.16.0 providers and installing the 365 version replaced them both. I noticed right away that my queries ran faster than they had been over the past week and the Complus errors have not occurred once.

Crossing fingers, but at least for tonight, I can sleep.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Stefano Sotto Corona 10 Reputation points

2025-08-21T10:00:02.7966667+00:00

In our environments, the issue started on August 13 and, without any action on our side, it appears to be working again today. Could you please check in your environments and confirm whether the problem has been resolved or if you are still experiencing it?
Please sign in to rate this answer.
Shun 0 Reputation points

2025-08-22T09:19:02.1633333+00:00

Same here. I checked and could not reproduce the error which I could the day before yesterday.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Sean Smith 20 Reputation points

2025-08-21T12:01:23.34+00:00
And nothing worked for us. We did the following:

Installed/uninstalled M365 32-bit runtime

Installed/uninstalled 2010 and 2016 runtime

Installed/uninstalled 2013 runtime (32- and 64-bit)

The only thing that sort-of works is installing the M365 64-bit runtime. It will work (slowly) for smaller exports, but bombs out on larger ones.

I'm going to go back to MS with this and see what they suggest.
Please sign in to rate this answer.
Schueller, Matthew 0 Reputation points

2025-08-21T20:42:55.6766667+00:00

Have you checked to see if it is working now? Our environment started working today, with no changes made.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Abhiram Munaga 0 Reputation points

2025-08-21T15:09:38.54+00:00

Problem: Using ACE OLEDB 12 all the datatransfer from an Access Database to a SQL Database became super slow suddenly.

UnInstalling the 2010 Access Database Engine and Installing the 2013 Access Runttime worked for us.

After installing the Access Runtime 2013 it enabled/added ACEOLEDB 15 to our SQL Server which added a ACE OLEDB 15.0 provider, we used this 15 provider to add the LinkedServer to access the AccessDatabase. This fixed our issue and also improved the performance quite a bit.

Still we don't know which patch/release is causing this, would be great if someone knows
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

SSIS (DTExec.exe) Complus (COM+) Error with Large Excel Files Since August 2025 Patches

Installing MS 365 Access Runtime maybe fixed it:

12 additional answers

Your answer