Access instance remains in memory once closed

[isladogs]

Thanks Ron. That's good news!

Please could you provide the version / build for each. I tested in both:

• Windows 11 Pro 25H2 26200.7705 and Access 365 v2603 19727.20000 Beta Channel
• Windows 10 Pro 22H2 19045.6809 and Access 365 v2603 19728.20004 Beta Channel

 

[RonPaii]

Thanks Ron. That's good news!

Please could you provide the version / build for each. I tested in both:

• Windows 11 Pro 25H2 26200.7705 and Access 365 v2603 19727.20000 Beta Channel
• Windows 10 Pro 22H2 19045.6809 and Access 365 v2603 19728.20004 Beta Channel

Windows 11 Pro, Version 25H2 (OS Build 262000.7623)
Microsoft® Access® for Microsoft 365 MSO (Version 2511 Build 16.0.19426.20260) 64-bit Monthly Enterprise Channel

In an unrelated note. I do on occasion get the following pop-up error on reboot/shutdown. All programs are closed before the shutdown.

Access application error: The instruction at 0x00007FF6B6144735 referenced memory at 0x0000000000000048. The memory could not be read.

 

[isladogs]

Thanks

 

[RonPaii]

Thanks

I just tried it on Runtime. The 1st form opened but Access hung on opening the 2nd db. Ended with a runtime error.

Event viewer showed no error or warning, but this information log.

- System

  - Provider
   [ Name]  Microsoft Office 16 Alerts
  - EventID 300
   [ Qualifiers]  0
   Version 0
   Level 4
   Task 0
   Opcode 0
   Keywords 0x80000000000000
  - TimeCreated
   [ SystemTime]  2026-02-06T14:02:57.1312249Z
   EventRecordID 12
   Correlation
  - Execution
   [ ProcessID]  0
   [ ThreadID]  0
   Channel OAlerts
   Computer PC0075.pa.packairinc.com
   Security

- EventData
   Microsoft Access Execution of this application has stopped due to a run-time error. 
   The application can't continue and will be shut down. 
   507898 
   16.0.19628.20150

Don't know an easy method to get the version but registry is as follows
RuntimeVersion v2.0.50727
Windows 10Pro Version 22H2 (OS Build 19045.6456)

Maybe add to the 1st form the current Windows/Access information to report back to you.

 

[isladogs]

Yes. I'd expect it to fail using / simulating Runtime.
In fact, no need to try and do the automation as you will get that error if you just click the View / Edit Code button when using Runtime

In case you or anyone else would find it useful, I do have a free Windows / Office / Access version checker add-in:

Access/Windows Version Check Add-In

Use this add-in to obtain the full Access/Windows/Office 365 version and bitness information. It also provides details of the VBA references used by the host application

www.isladogs.co.uk

However of course you can't load add-ins in Runtime mode but you run run an add-in such as that as a standalone app in Runtime mode.
I haven't got a current VM with an actual Runtime version available to test on.

 

[RonPaii]

Yes. I'd expect it to fail using / simulating Runtime.
In fact, no need to try and do the automation as you will get that error if you just click the View / Edit Code button when using Runtime

In case you or anyone else would find it useful, I do have a free Windows / Office / Access version checker add-in:

Access/Windows Version Check Add-In

Use this add-in to obtain the full Access/Windows/Office 365 version and bitness information. It also provides details of the VBA references used by the host application

www.isladogs.co.uk

However of course you can't load add-ins in Runtime mode but you run run an add-in such as that as a standalone app in Runtime mode.
I haven't got a current VM with an actual Runtime version available to test on.

This was a real Runtime computer.
It crashed clicking the next form button.

 

[isladogs]

Not sure what you mean as it only has one form.
Again it would have been surprising if it had worked in runtime.
To get all the version info, the code runs various WMI functions, checks multiple registry locations, runs various SysCmd checks and even does a web scrape of the Office 365 release history web page to get the Office YYMM version number.

 

[RonPaii]

Not sure what you mean as it only has one form.
Again it would have been surprising if it had worked in runtime.
To get all the version info, the code runs various WMI functions, checks multiple registry locations, runs various SysCmd checks and even does a web scrape of the Office 365 release history web page to get the Office YYMM version number.

I added a registry lookup to display the Access version and error trapping to catch the error. Apparently Access automation from runtime is not allowed.

 

[cheekybuddha]

Apparently Access automation from runtime is not allowed.

Colin did try and explain that to you in Post #85

I'd expect it to fail using / simulating Runtime.
In fact, no need to try and do the automation as you will get that error if you just click the View / Edit Code button when using Runtime

 

[isladogs]

Runtime versions have several limitations
Not being able to do automation is I think a perfectly reasonable limitation.
In fact I'd go further and say its a good thing

 

[isladogs]

I finally discovered the reason for all these hanging instances this afternoon.
I turns out that the cause was something else completely - Microsoft Teams!!!!
In case it helps anyone else, here is a summary:

In post #79 last Friday, I confirmed getting hanging instances with Access each time it was closed on two machines.

The issue went away on my Win 10 machine the next day though I hadn’t knowingly changed anything
However my Win 11 laptop continued to leave behind a background process whenever I closed Access
I then realised it did so even if I opened & closed Access without loading any databases.

Next I discovered exactly the same issue occurred with Excel, Outlook (classic), PowerPoint & Word.
It was Office wide - not an Access bug

I spent several hours going around in circles – changing Office channels, running quick & online repairs and reinstalling Office completely.
I even cleared out folders left behind after Office is uninstalled to get a clean start. No joy!

I then turned to CoPilot which led me down more rabbit holes than I choose to ever see again.
After lots of fruitless PowerShell checks I then looked at OneDrive integration with Office – not a problem in my case though it might be the cause for others. If so, try disabling OneDrive syncing and see if it helps

I then Quit Teams from the system tray – problem immediately solved. Restarted Teams & it returned

A quick test on my Win10 machine – restarted Teams and the problem returned!
Similarly on my Win11 tablet which hadn’t been running Teams earlier . . .

The problem was Teams integrating itself insidiously into Office apps and preventing them closing nicely when Teams was running.

I’ve now found the settings needed to allow Teams to co-exist with Office apps without causing hanging instances.
If this is an issue for anyone else, I’ll happily provide the details.

Colin

 

[CJ_London]

I’m certainly interested

Teams and PowerShell open in startup when I reboot - even when I remove them from startup, they return.

 

[Minty]

I'm interested.
Although I haven't been suffering for this, I did some time ago, and ended up doing a full Windows re-install/upgrade.
I'm sure some clients are probably experiencing it without realising.

 

[isladogs]

I expect there is more than one cause for the hanging instances that various people in this thread are afflicted by.

So whilst Teams was the problem in my case, it may not solve the problem for others.

For those who are getting hanging instances, first check if Teams is running.
Go to the notifications area in the taskbar, right click the Teams icon (if present) and click Quit Teams. The icon will disappear

Now open an Access database then close and Quit Access. Do you still get an instance of Access left in background process?
If yes, then Teams isn't the problem in your case so stop reading here!

If no, then Teams is responsible, so read on.

Teams and PowerShell open in startup when I reboot - even when I remove them from startup, they return.

That may not matter but if you don't want it to happen, you can prevent Teams loading at startup in several ways:
1. Windows Settings | Apps | Startup - toggle the slider for Teams to Off

No idea if PowerShell is an issue but probably there will be a similar entry for that

2. Open Teams - click the ellipsis ( . . .) at the top right and click Settings | General and untick Auto-start Teams

That screenshot also shows the unexpected option that was the problem for me

In the latest version of Teams 26005.213.4315.4117, the fourth option under General was enabled (not by me)
In my case that was hooked into my Office apps and preventing them closing cleanly

Untick Register the new Teams as the chat app for Microsoft 365.
Then close all Office apps. From now on, you shouldn't see any instances of Access (or other Office apps remaining in Task Manager after closing.

NOTE: If you only see the top two options, you may need to change the Language and regional format settings lower down under General, close and restart Teams.

One more thing that is worth checking whilst Settings is open
Click Files and links and set Word, PowerPoint and Excel file to open in the Browser (NOT Teams)

Hope that helps at least some of you to fix this issue

 

[isladogs]

I have just written this up as a web article with additional detail.

Teams Integration Causing Office Problems

This article describes how Teams integration with Office may cause hanging instances of Office apps to remain as background processes in Task Manager. It also provides a guide to troubleshooting the problem and what changes to make if this is the cause.

www.isladogs.co.uk

However, after getting feedback from a couple of other MVPs that those Teams settings were not causing problems for them, I have, at least temporarily, reversed the settings again. Inexplicably, so far the problems have not returned. I will continue to monitor the situation.