Quick post to get this out in the wild and see if anyone else is having similar issues.

I started getting the following error just a couple of hours ago (about 1 PM EDT on 29 Aug 2025):

The error was first reported by a customer who was getting it in one of our deployed applications. This is calling code that has not been touched in years.

Another computer with the same application at the same client did not receive the error. Key difference between the two computers? Their Access versions.

• BAD: Access version 2508: this computer got the error shown above
• GOOD: Access version 2507: no error message; RE.Replace() works as normal

I checked the Office update history on the computer, but that just takes you to the following website: Release notes for Current Channel.

Release notes for Current Channel releases - Office release notes

Provides IT Pros with release notes for Monthly Channel releases for Microsoft 365 Apps.

Microsoft LearnTimDavenport

Here's the text of the website at the time of publication:

I told my customer to wait until after the long weekend to give Microsoft a chance to fix the problem, as his was the only complaint I had received.

And then a few hours later, I fired up a different Access application on a different machine (my dev machine) and got the same unhappy error message on the same lines of code:

Microsoft Visual C++ Runtime Library
Assertion failed!

Program: ...
File: g:\vba\src\65_VC8\VBA\rt\rtre.cxx
Line: 946

Expression: replaceVar.vt == VT_BSTR

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts

(Press Retry to debug the application - JIT must be enabled)

I worry that this may be related to Microsoft's plans to kill off VBScript, which is the library that provides RegEx support in VBA:

Microsoft Announces the Death of VBScript

As seems to be their new modus operandi, Microsoft has quietly rolled a hand grenade into the VBA development world with very little fanfare.

No Longer SetMike Wolfe

I should note that VBScript itself is working just fine on my computer (running Win 11). It has not even switched over to a Feature On Demand (yet). So maybe I'm just being paranoid.

My fear, if this doesn't get resolved quickly, is that I will need to reimplement all of my VBA regex functionality using some other alternative on a much shorter timeline than I anticipated. This is probably where I would start:

GitHub - sihlfall/vba-regex: A regular expression engine written entirely in VBA

A regular expression engine written entirely in VBA - sihlfall/vba-regex

GitHubsihlfall

Let's hope it doesn't come to that...at least not yet.

Verified Workaround

UPDATE [2025-08-29 23:10 EDT]: I found the following Reddit thread, which describes the behavior I observed earlier today:

Buried in that thread is the following observation:

The relevant part is this line, "Our fix was using cStr on the replacement string when using it in RegEx.Replace."

However, the full explanation didn't quite make sense to me. In my code, the ReplacePattern variable I was passing was already declared as a String. So these last lines, "My guess is that for some reason the empty string was interpreted as a variant instead of a string causing the error. Using cStr makes sure that BStr is used as the data type which prevents the error," did not explain what I was seeing.

I wondered whether the real reason CStr() worked is because it had the side effect of forcing the replace pattern parameter to be passed by value to the .Replace() method. I tried simply wrapping the replace pattern variable in parentheses–which also forces the argument to be passed by value–and that also fixed the problem.

BOTTOM LINE: Wrap the second argument to the RegExp Replace() method in parentheses, and the Visual C++ assertion error goes away:

Now, with a bit of luck, the Office team will roll back whatever caused this problem via their opaque (but handy!) feature gates system before I have to add this bit of workaround code to literally dozens of active Access applications. 😬