Access crashes since latest (June) Office 365 update 16.0.12827.20268

A complete guide how to rollback is available here: https://support.microsoft.com/en-us/help/2770432/how-to-revert-to-an-earlier-version-of-office-2013-or-office-2016-clic

Art.

I have begun noticing a lot of issues in MS Access Office 365 C2R since the latest June update.  Using VBA to query tables with certain combination of fields causes Access to close without warning.  Editing a code module on a form with a large list view freezes Access cold without closing it.  Querying data sets using VBA returns corrupt data. I verified this latter item is the case with SQL linked tables as well as with an internal MSAccess table. I have created a sample database that exhibits some of these issues. Using Access 2013 everything is just peachy good. ??!? 

I can open tables to read data directly and even design and use queries to pull and read and write data just fine.  All these crashes appear to originate when VBA code is executed and/or COM+ or code calls to memory objects are invoked. It is not always consistent. Sometimes stepping through code it is fine but data is still corrupt. Other times stepping through code line by line Access just vanishes off the screen and out of memory. Did something go sideways recompiling the VBA interpreter?

I have started getting calls from clients who are becoming affected by this issue and so far have a dozen affected people in two companies plus my own workstation. I am concerned this is a widespread issue that if everyone updates it will kill functionality of  MS Access for my entire client base (everyone). This has happened once already last year with the "Query is Corrupt" bug that took over 4 weeks to resolve.  Very concerning that MS Access is no longer the stable product that has led so many to use it for effective business solutions. Let me know what I can do to assist and so we can get the CR2 update path fixed before too many more get hit with issues?

Ebo Quansah:

This temporary fix did not work for us. Perhaps that follows with Sooz_24's comment, though we were able to revert back to Office 2016.

I have seen everything that everyone else has seen with regards to the failure of MS Assess 2019 to complete its VBA routines. This is especially noticeable where DAO, loops, and calculations are involved.. There is no doubt that this issue started immediately following the most recent Windows 10 updates. A new company-wide system just completed and in use for the last 2 months was crippled immediately. One by one the systems went down as the update was loaded. The first thought was a compromise of some sort--which was not found to have taken place. The second thought that came to mind was a faulty update from Microsoft either for Office/Access, Windows, Server, or SQL Server . After a little research, I found that the latter was definitely the issue as it pertained to Windows 10. I thought, "where is the regression testing", then I found that Microsoft released the update with known issues that directly affected the product. So we are left to solve an issue that is costing our company extra time and money to deal with.

So, there is the vent. Now regarding working toward a solution: We found that reverting back to Office 2016 Pro did not work in our case. Trying to rollback the updates did not work. Rather the update rollback process would fail, thus not allowing us to remove all of them. Trying to revert Windows back to an earlier state did not work. It seems that this was also "broken" with the update. The only working solution we have right now, is for users to work on the few systems have 2016 or 2019 versions of Office and did not have the most current Windows 10 update; or, Work with a few remaining older systems that still had Windows 7. Nothing else, as of yet, seems to work.

Given that the rollback to Office 2016 was not an effective solution, I am concerned that potentially the issue may go beyond a Windows 10/Office issue, and also include Windows Server and SQL Server issues. If so, this could get pretty messy. So that leaves me with the following question: How far does this issue potentially reach?  Will the ramifications of the changes that Microsoft deems necessary affect other products as well (e.g. Server, SQL Server, and so on)? This will definitely play a role in the decision making process regarding this issue.

So for now, our solution is to temporarily turn off updates across the board as the lesser of two evils.

I was able to successfully rollback to early May version and all is working now. Following the procedure PNL posted above.