Cannot start Access today. Get error "Automatic configuration of the current version of Microsoft Access has failed."

Hi ThomasAJ

Like you, I had been using Office 365 Home 2016 subscription, the ACCESS component without any changes on my part. On Friday, it stopped working with the same error message that has been stated in this stream.  

I tried Quick Repair, Online Repair, Uninstall, Install (not just once...because I must be insane...several times).  Also tried downloading the Database Engine and encountered the same 32-bit vs 64-bit issue you encountered.   I did not want to install Office 64-bit to see if it resolved the issue.

Talked to Microsoft Consumer support person who informed me they would charge me $499 if I needed to have an engineer fix the problem. 

We have 3 PC's in the house.  Only mine, at the Office build (16.0.9029.2167) that was downloaded recently, has the problem.   I thought-- well, I'll wait -- when this build gets distributed out to a wider audience it will get attention.  

But, I couldn't wait -- since I volunteer~support a couple Not-For-Profit agencies for their MS-Access applications,  and most of them are even less technical than I am.

So I looked for a way to revert to a build that didn't have this problem.  The first one I tried failed.  Then tried build 16.0.9001.2138 -- that, THANKFULLY, does work.

Here's a link of the steps to do (and there isn't any Registry tweaking)

https://blogs.technet.microsoft.com/odsupport/2014/03/03/the-new-update-now-feature-for-office-2013-click-to-run-for-office365-and-its-associated-command-line-and-switches/

Use this build 16.0.9001.2138

I hope this works for you.

Did you see: http//www.devhut.net/2018/03/05/ms-access-bug-automatic-configuration-of-the-current-version-of-microsoft-access-has-failed/ ?  I mention the current 2 workarounds.

Okay I have Access working again thanks to one of the suggestions above although I am not sure of how it leaves me placed in the longer term.

As others have noted, the issue may be that the InprocServer32 registry entry for various classes are expecting ACEOLEDB.DLL to be in "c:\Program Files\Common Files\Microsoft Shared\OFFICE16\ACEOLEDB.DLL".

However ACEOLEDB.DLL & the rest of the access database dlls are actually located at "C:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16" on my system with 64 bit office installed. The Access database engine files located here are dated 2 March 2018 and are version 16.0.9029.2054. These are from the recent automatic update.

So given the apparent mismatch between the registry entries and actual files thanks to the update, I could have, as some suggested, edited the registry entries so they point to the actual database engine file location now. But I worry if that will have some unintended consequences elsewhere.

So I downloaded and installed the 64 bit Access database engine from the link given by another user above. Oila! Access now works. The registry entries are unchanged but there is now a copy of the Access database engine in the expected location (c:\Program Files\Common Files\Microsoft Shared\OFFICE16). So I can work again, hurrah.

BUT the version of the files located in this spot and presumably being used are an older version dated 7 March 2017 16.0.4492.1000.

So now my concern is, that I seem to be using a copy of Access which mixes together program files from different versions: some from  March 2017 and probably some from March 2018. Is this likely to introduce problems or incompatibilities? How will it interact with future automatic updates to Access?

I have to say that I am incredibly disappointed with Microsoft about this issue.

I remember when they introduced a bug into an automatic update of Access back in the first week of March 2016* which broke the program for every user worldwide that received automatic updates. Back then, they were very apologetic, fixed it quickly and vowed it would not happen again. Not only has it happened again but this time they seem to be very lax in their response. Rather than having improved their quality control and approach, it seems to have gone considerably downhill.

* is it just a coincidence that Microsoft keep breaking Access in the first week of March or do their testing and quality assurance people all go on holidays then?

Considering this issue just surfaced with the release of the latest update, have any of you tried reverting/uninstalling the latest update and going back to a previous build 9001.2138  as mentioned as successfully restoring Access in fiddlestix's post above (and the disable automatic updates).  This has been reported as being a workaround that works while we wait for Microsoft to decide to get involved and fix this mess.

Hi Daniel,

Thanks for your reply.

I considered that but by that stage I wanted the quickest possible fix and thought downloading the MSAcess engine might be that.

Also those who have uninstalled then reinstalled Office (a logical early step) only to find they still have the problem, I don't think the option of a roll-back of the update would be available, would it?

I am a bit surprised at the slow response from Microsoft this time. It has been a good two days already since this surfaced with no response. I struck it yesterday when I used Access for the first time in a few days. I spent a bit of time investigating and trying Office fix etc before contacting MS Office support, only to be told that they don't support Access. They tried to transfer me to the business group that do support Access but they, understandably, are only available in long office hours and I had just missed them. So I was asked to call back in 12 hours time. I wish had been told then that support for Access is only available with payment, even if it is a MS introduced bug. If I had known, I might not have bothered waiting and moved to attempt a fix myself immediately and not been so annoyed with them.

My memory of the similar past snafu was that they had a fix being distributed by this time and they certainly had acknowledged and offered advice well before this.

Regards,

David Young