Instr() function crashes MS Access after 4/4/2024 update to office 16.0.17425.20146

Anonymous
2024-04-05T16:32:38+00:00

After Office updated to version 16.0.17425.20146 my MS Access crashes when running very simple functions. I created a new database with one table and one query.

Table1.Text1
Zebra
x-ray
4x4
Posted to X
Next
axe
None
extreme
wax

This works:

SELECT Table1.Text1, InStr(1,[Text1],"x") AS Field2

FROM Table1;

Query1
Text1 Field2
Zebra 0
x-ray 1
4x4 2
Posted to X 11
Next 3
axe 2
None 0
extreme 2
wax 3

This crashes MS Access before returning any results:

SELECT Table1.Text1, InStr(1,[Text1],"x") AS Field2

FROM Table1

WHERE (((InStr(1,[Text1],"x"))>0));

I tried compact/repair. Tried recreating the database from scratch. Rebooted my computer. I uninstalled and re-installed MS Office.

Any ideas??

Microsoft 365 and Office | Access | For business | 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

54 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Anonymous
    2024-04-09T13:11:43+00:00

    I also hit this problem when updating Office to version 2403, and the query using InStr is still causing Access to crash even with the latest Office updates.

    After lots of investigation and testing I'll cut to the headline discovery I made.

    I was able to replicate the crash in a new blank DB by adding a tiny simple table and a tiny simple query that uses InStr.
    Opening the query, I am able to reproduce the crash simply by attempting to filter on the column that uses InStr.

    But the weird thing about this is that, initially, it repeatedly worked fine in the new fresh DB....but when I then did a compact and repair and tried the test again it then crashes when attempting the filter.

    Just running C&R on this new tiny simple DB resulted in it starting to crash when doing the filter test, where it worked fine on the freshly created DB before C&R was run.

    This is all repeatable. I have a copy of the new DB that hasn't had C&R run and the query continues to filter OK. I have a separate copy of that DB where I've run C&R and it continues to crash when doing the filter.
    ACCDBs uploaded here: Sample DBs

    This is the query: SELECT ID, InStr("abc", "x") AS [Filter Me] FROM Table1;

    This is the table schema and data:

    My PC:
    Microsoft® Access® for Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) 64-bit (Click-to-Run, Current Channel).
    Windows 11 Pro 23H2 10.0.22631.3374 (64-bit).

    I hope this helps with diagnosing the issue. I'd be interested to know if anyone else can replicate the behaviour with the two sample DBs.

    Was this answer helpful?

    0 comments
  2. Anonymous
    2024-04-09T08:42:43+00:00

    I am experiencing the same issue immediately after auto-update to Version 2403 Build 16.017425.20124 (64 bit). Any query with the instr() function in the expression crashes/closes Access whether compiled or uncompiled. On dozens of machines.

    I downgraded to Version 2402 Build 16.0.17328.20124 and it works fine. Turned off Office auto updates for now.

    I don't post much, so I hope I am replying to the correct post.

    Was this answer helpful?

    0 comments
  3. Anonymous
    2024-04-09T06:00:50+00:00

    > or it only crashes when the source database is in a Box.com or Dropbox folder.

    As my friend George has already indicated, you absolutely should never access JET (Joint Engine Technology aka *.mdb / *.accdb) databases stored on someone else’s server. JET databases are designed to be used on one’s local hard drive, or properly split as FE/BE, with a copy of the FE on each user’s local hard drive and the shared BE on a solid Local Area Network (LAN) only. If you have geographic needs that involve the public internet (WAN or Wide Area Network), then you should use either RDP (Remote Desktop Protocol) or a licensed product such as Citrix Terminal Server. Running JET databases over a WAN is just asking for trouble.

    > Or my specific malware defenses are killing a process due to a false positive detection.

    That should be easy enough to test by temporarily disabling your malware defenses. My test results, with the current Semi-Annual Enterprise Channel of 64-bit Access, were run with Malwarebytes active on my system.

    Was this answer helpful?

    0 comments