Update KB5002121 causing problems with A13 Runtime?

[JohnPapa]

Today I had 2 clients who had problems using my application that runs with A13 Runtime.

They could not enter the application. The problem was solved when I removed KB5002121.

Do we have any news about this update?

 

[FoxVillage]

We have had the problem with several users today who use our Access application for their horse shows. Completely uninstalling all Office / Access programs, full, runtime, etc. rebooting and reinstalling seems to fix the issue. Still a huge time amount of customer support today..

 

[pbaldy]

I don't have any news, but we had the same problem with a number of users today. Removing that KB also resolved it for us.

 

[JohnPapa]

"Glad" to hear that others had the same problem. All I can say is "scary".

 

[JohnPapa]

Just had a third client call with the same problem. Problem was fixed when we removed KB5002121.

BTW we are running .accde as FE, .accdb BE, using the A13 Runtime.

 

[zoinky]

Hi all,

we have discovered a temporary work around (which is abit of a cludge). In Access we use an autoexec macro - which started a form immediately. If you add a step before that (in the autoexec macro) which calls code in a module which does Sleep(5000). The next step for autoexec macro then opens form in the application as expected - just a slight delay before seeing first form. this has worked on office 2013, office 2016, office 2019 and whatever 365 variant our users are at.

 

[isladogs]

MS have confirmed the bug is caused by a Windows security update and are currently investigating its scope and severity.
Public announcement to follow.

 

[JohnPapa]

Thanks. I guess MS did no testing before they released their update. More like shoot and ask questions later.

 

[GPGeorge]

No, no, no. Microsoft has millions of "testers" all over the world. It's called "post-release testing", as opposed to "pre-release testing". The sad thing is that so many of us have been trained to participate in it.

 

[JohnPapa]

"Post release testing" indeed...

 

[A Real Human]

If anyone is looking for a solution for the time being, I found something that works for me.

If I create a blank form with no codebehind, and add an extra step at the beginning of the AutoExec macro to open that form first, and then open the real form afterward, it does not throw any errors. I can then add another step in the macro to close that blank form and continue on my way.

(last time microsoft broke access with a security update like this it took them over a month to fix it, so I started looking for ways to deal with it)

 

[Gasman]

Someone found a short delay before calling form worked as well.?

 

[A Real Human]

Someone found a short delay before calling form worked as well.?

If that works for you then great. I wasn't able to get any code to run first thing, even the delay. I can add steps in the AutoExec macro, but running any code that was in a module was failing.

 

[BlueTuesday]

We have a piece of Access accde software in use on around 300 sites. We first noticed this problem on Wednesday morning on one of our in house test computers (Windows11, Office 365). Recreating the accde on that machine fixed the problem. Yesterday it started to hit client sites and it's a bit of a nightmare, because the fix seems to vary across the various combinations of Windows 10/11 and Access 2013/2016/365 full and runtime. On some sites installing the accde created on our test machine works, others it doesn't. Some sites putting a pause in the autoexec works, others it doesn't. Some sites uploading the acdb and recreating the accde on site works, others it doesn't. We had one site where we had to upload the accdb with the pause and create the accde on site to get it working. We've not yet tried the open a blank form first trick, although that might work simply because it introduces a delay before opening a real form.

Yesterday was a bit stressed, but so far we haven't noticed a pattern as to which Windows/Access combination requires which fix. Un installing the update isn't always an easy option as we aren't the resident IT company on any of our sites, we just supply our product. One thing we have noticed is after opening and closing it leaves the lock file there and in use, as in the machine needs a reboot before it can be deleted. Which is similar to the last time Microsoft did this trick.

If I find any consistency or a single fix I'll let you know.

 

[JohnPapa]

With the update, MS managed to block users out of their .accde. If MS wanted to achieve this, it would be a challenge.

Unfortunately, without knowing exactly what MS did (I doubt whether it is clear to MS exactly what they did), the various fixes, as you have found out, are not a solution. The only valid and quick solution is to remove KB5002121, until MS fixes the problem with another update.