Access crashes since latest (June) Office 365 update 16.0.12827.20268

Anonymous
2020-06-08T08:51:19+00:00

Since the latest Office 365 Update (June update) a returning error emerges when opening (larger) forms in MSACCESS.

Using the Access runtime (2013 tested on) instead of the full Office365 Access seems to solve this problem for now.

Here is a summary of the error, below I added a screenshot of the event viewer error log (it is in dutch though):

Faulting application name: MSACCESS>EXE, version: 16.0.12827.20268

Faulting module name: ntdll.dll, version: 10.0.18362.815

Exception code: 0xc0000374

Fault offset: 0x000dfa1d

Faulting process id: 0x1f30

Microsoft 365 and Office | Access | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments
Answer accepted by question author
Anonymous
2020-06-09T03:27:13+00:00

Thank you for your feedback. Very soon, we will ship a new data type, known as Date & Time Extended, which enhances syntax compatibility with SQL while increasing accuracy & level of detail in date & time records.

While the feature is not yet enabled in Current Channel builds, most of the code for the feature is in the product in an inactive state. Nonetheless, we are aware of a problem that currently exists with this new code. As of today, if you are on version 2005, build 12827.20010 or greater, and you manipulate Decimal fields (Access DataType=Number/FieldSize=Decimal, or SQL DataType=Decimal) using DAO (Data Access Objects), you might have identified your app crashing. If you hover a variable with the type in VBA code, you may see that the field is not being displayed properly; either reading as ‘?????’ or giving a Type Mismatch error, or Access may crash.

We are very sorry for the inconvenience this causes in your Access app. The Access team is working on resolving this issue as soon as possible, and we will report back to you once this error has been fixed. In the interim, we’d recommend for you to roll back to a previous version (https://support.microsoft.com/en-us/help/2770432/how-to-revert-to-an-earlier-version-of-office-2013-or-office-2016-clic), or switch to a slower channel (e.g Monthly Enterprise Channel, or SemiAnnual Channel), until the issue is fixed in Current Channel.  The issue only impacts Decimal types so if avoiding DAO code that manipulates Decimal types is possible, we’d advise this as a short term solution.

Was this answer helpful?

10+ people found this answer helpful.
0 comments

57 additional answers

Sort by: Newest
Most helpful Newest Oldest
  1. Anonymous
    2020-09-15T08:13:14+00:00

    The same problem here:

    Name der fehlerhaften Anwendung: MSACCESS.EXE, Version: 16.0.13127.20408, Zeitstempel: 0x5f56c673

    Name des fehlerhaften Moduls: ntdll.dll, Version: 10.0.18362.1049, Zeitstempel: 0xb5beef21

    Ausnahmecode: 0xc0000374

    The form worked until recently, now it crashes one time out of ten starts... and its getting worse...

    Please fix this!!!

    Was this answer helpful?

    0 comments
  2. Anonymous
    2020-09-02T21:25:07+00:00

    I would like to add to this thread that an MS Access application was stable until recently, then started crashing every time on opening one particular form with this error:

    Faulting application name: MSACCESS.EXE, version: 16.0.13029.20344, time stamp: 0x5f2a276c

    Faulting module name: ntdll.dll, version: 10.0.17763.1432, time stamp: 0x80224f6f

    Exception code: 0xc0000374

    Decompiling, compact & repair, etc made no difference. 

    Reverting to version 16.0.12325.20288 from January 2020 resolved the issue immediately.

    This was in 64-bit Office. Switching to 32-bit is not an option.

    Really looking forward to a fix from Microsoft!

    Was this answer helpful?

    0 comments
  3. Anonymous
    2020-08-05T22:08:45+00:00

    I agree (i.e. "hmm"). I have been testing Microsoft's face-saving updates and so far they have worked pretty well on my test systems. No problems out of Windows, SQL Server, or Office. Have you tried the newest build for Office? I don't blame you if you don't really want to, but it might be worth doing on a test system. If you are already testing them, I am curious what your experience has been.

    Was this answer helpful?

    0 comments
  4. Anonymous
    2020-08-01T13:08:32+00:00

    I stalled for a while before replying to this, but since MS sent me a link to THIS thread as a solution to my issue, I should say that switching to 32-bit Access isn't a solution for me. All I've really done here is offer a temporary workaround to a few lucky people who read this thread and can reasonably switch all their users to 32-bit until MS wants to fix it.

    We really need 64-bit to work. Having our IT staff uninstall 64-bit office 365 from all of our HQ workstations, laptops and virtual stations, and install Office 32-bit in its place is not a solution for us. And it points to something bad. If regression testing isn't finding this in their 64-bit product updates, hmm.

    (I thought I must have some corrupt data in the Access database.  But I harvested the queries and grabbed the rest of the objects with SaveAsText, cleaned them and did LoadFromText to a new clean database and the issues didn't go away. I used Stellar Access Repair on it and no-worky. I have a basic database containing nothing but two forms, and on 64-bit it crashes when one form calls the other after opening the database about 1 time in 3. So Access's issues seem to be Access's issues.

    Was this answer helpful?

    0 comments