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-06-30T18:56:04+00:00

    Thanks for the heads up. Our organization uses the semi-annual enterprise. That still provides two chances per year to get burned.

    We have a user that is not experienced the crashes. He's on (ahem) 1908 build 11929.20838. Researching the error, I saw a claim that it only affected 64-bit products. So (another ahem) I dumped 64-bit 365 on my laptop, loaded 32-bit on it and recompiled the app for 32. I can't get it to crash. This same laptop crashed multiple times earlier today. We have a bunch of workstations using this app, so this is NOT A GREAT SOLUTION. But it might have to be a workaround. Need to test a few more workstations.

    Regarding my screen name, I was once required to create one on a popular site and the form came back, "already in use." I tried another. "already in use." Another. Same thing. ANOTHER. Same thing. I was so frustrated I typed "ihatescreennames". It came back, "already in use". I then tried ihatescreennamestoo, then ihatescreennamesmore, then ihatescreenanamesmorethanyou. I finally had a winner. :-)

    Was this answer helpful?

    0 comments
  2. Anonymous
    2020-06-30T18:14:42+00:00

    Lol... nice screen name! I have seen everything from what you have above as well as a growing list of other issues. The thing is there are updates in Windows, Office 2016 and 2019, and SQL Server that all have bugs that affected us. We did revert back to older versions where the changes mattered, and shut off updates on all of them until Microsoft gets this figured out. This did fix some of the most important issues. I learned this lesson a long time ago and got complacent, but I will never allow Microsoft to automatically update software again. This kind of thing does not happen often, but the few times I have had a similar experience over a couple of decades of working with MS products, it has always been a pain in the behind. Lesson learned... again. I will wait for consensus. I have faith they will get these issues taken care of though, and their Agile-fu will improve.

    Was this answer helpful?

    0 comments
  3. Anonymous
    2020-06-30T16:25:50+00:00

    I started putting this on another thread but I think it belongs here.  We are experiencing the issue with Access crashing too. But we only have a couple tables in our db that use decimal and they are not referenced anywhere in the steps that cause it to crash. Also, the crash is truly intermittent. Sometimes Access behaves exactly as it always has. And sometimes it vaporizes after opening a form from our app's opening form. Maybe 1 time in 3 or 4 it switches the cursor to an arrow with an hourglass and crashes. The rest of the time the form works fine. If it works then the whole app seems to behave, that is, I can't get it to crash after successfully opening a form from the opening form. But sometimes clicking a button to open a form immediately after opening the app shuts it down. Tracing the VBA code, it makes it through the On Load just fine before it crashes.

    Even though I doubted the decimal problem was the culprit, I decided to see if I was lucky when I had no logical explanation for a random shutdown and I updated to the new Access version 2005, build 12827.20470 ctr. It did not change my situation. I've decompiled and repair/compacted and recompiled. Still randomly flaky. One of my users has some critical weekly reports to generate but for him, attempting to open any of the forms used to launch reports crashes has copy. (Each user has a copy of the frontend on their machine.)

    After opening it and a form 15 or so times and getting 5 crashes, I looked in the event viewer and found 5 application errors.  They all read like...

    Faulting application name: MSACCESS.EXE, version: 16.0.12827.20470, time stamp: 0x5ef2a45e

    Faulting module name: ntdll.dll, version: 10.0.18362.815, time stamp: 0xb29ecf52

    Exception code: 0xc0000374

    Fault offset: 0x00000000000f9229

    Faulting process id: 0x3ae4

    Faulting application start time: 0x01d64ee426ad18fe

    Faulting application path: C:\Program Files\Microsoft Office\root\Office16\MSACCESS.EXE

    Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll

    Report Id: 141a0658-0ecf-451f-b214-9d6999ac7855

    Faulting package full name: 

    Faulting package-relative application ID: 

    Log Name: Application

    Source: Application Error, Logged: 6/30/2020 8:41:32 AM

    Event ID: 1000, Task Category: (100)

    Level: Error, Keywords: Classic

    Was this answer helpful?

    0 comments
  4. Anonymous
    2020-06-20T18:55:15+00:00

    On the positive side, beyond the fact that you are now up and running, you are testing the fix for all of us. Good news now at least makes me optimistic that Microsoft heard clearly and reacted appropriately. I have since worked around the issue in a variety of ways, so I am fine waiting to see how your and other's testing goes. Thanks for the feedback!

    Was this answer helpful?

    0 comments