Solved Dreaded Access Process Staying Open (1 Viewer)

[moanz]

Hi all,

I have been having problems with the Access (x86 CTR 365) process remaining open after closing it down, but only after a form has been opened containing a control. If I don't open the form, the process closes fine. The database lock file DOES get removed every time though.

I haven't found much on the web about it, apart from this post, which recommended putting the db in a trusted location, which I have already done to no avail. I have also checked that the Window's text cursor indicator setting is off.

learn.microsoft.com/en-us/answers/questions/681552/msaccessexe-all-versions-won39t-close-properly-whe.html

(couldn't insert this as a link btw as it then considered my post spam)

Has anyone else experienced this kind of thing and/or can give me some pointers?

I was on the latest build 15726.20202, but I have also tried:

• A quick repair
• An online repair
• A complete uninstall, reboot, reinstall
• Rolling back to a few previous versions from earlier in the year.

All ideas welcome.

 

[moanz]

I just tried this in a different Windows user account (on the same machine) and it was fine so it is something to do with my user profile I think.

 

[gemma-the-husky]

if the locking file disappears, then you are just in the access shell

I just opened a database and did either file close, or X the database., then access remained open. If I close the database with the access X top right, then the access application closes together with the current database. Is that what you mean?

 

[moanz]

Hi gemma-the-husky,

Does this video help?

http://imgur.com/a/BG9jp58

 

[GPGeorge]

Hi gemma-the-husky,

Does this video help?

http://imgur.com/a/BG9jp58

It is not clear what the actual problem is. Your video shows that closing the Access application itself -- and not just an Accdb opened within the Access application -- does remove the MSAccess process from the ROT. What else do you expect to be happening?

 

[moanz]

The video shows me opening Access twice. The first time I don't open the form and so it closes properly, the second time I do open the form and so it doesn't close the process. The form is nothing special - doesn't have any code at all.

 

[The_Doc_Man]

You suggest that this works for another account. Obviously, you need to consider differences between those accounts. The one that most often reaches up to bite you is "file permissions" and, sometimes the file permissions of the folder where the app's file is kept. If this folder is different from your folder that is located in the partial path ...\users\your-user-name\documents... (where files go by default if no path is specified) then you need to check permissions on the folder where the app file is kept. NOTE: If the file is actually in your \users\username\... path then this might not be the right answer because if it is in your \users\ path then you should already own the file and have Full Control over it.

From EACH user account (as two separate experiments), find the file in its folder. RIGHT-click to follow properties >> security >> advanced security and then look for EFFECTIVE permissions. For the app file, perhaps these permissions will be the same, perhaps not. But NOW, repeat that on the folder in which that file is located. I.e. the folder's file permissions, not the application file's permissions. Again, they SHOULD be the same - but if they are not, you might have found your culprit.

Normally, proper permissions on an Access folder and app file are the broad-brush (i.e. simplified) "Modify" permission. If you tried to set the individual "advanced" permissions, you would probably have to set about a dozen different items, but the simplified Modify setting sets all of the ones you need.

 

[moanz]

Thank you all for your suggestions so far.

I can create the accdb file in any folder on the drive and I get the same problem. If I do so, I am making sure that I also add that folder to the trusted locations in Access before doing the test. I have checked the file and folder permissions though and they all look okay.

I have had a poke around in ProcessMonitor (from sysInternals.com) to see if I could find some path or registry key that it was attempting to access, but was unable to, (with the hope of then finding that as a success in the other user profile) but there is a lot of info coming back. Even when I run it in the user profile that doesn't have the issue, there is still quite a few entries where the result is NAME NOT FOUND or BUFFER OVERFLOW etc. so I am a little overwhelmed with that method currently. It would be nice if I could know if it was a registry or file issue and then I could apply the filters accordingly.

 

[moanz]

One thing I completely forgot to try before, is running Access as Admin (whilst logged on to the profile with the problem). The process does NOT stay open when I do this - i.e. problem goes away.

 

[Solo712]

Hi, I recall reading about issues with 365 MSACCESS remaining open (and related issues) after closing it. Do not recall the details but it had a simple solution: adding a trusted location for the file. You might want to check that out.

Best,
Jiri

 

[moanz]

Hi, I recall reading about issues with 365 MSACCESS remaining open (and related issues) after closing it. Do not recall the details but it had a simple solution: adding a trusted location for the file. You might want to check that out.

Best,
Jiri

Thanks Jiri,

I have seen a few posts suggesting that, but I have already added the path to my trusted location I'm afraid

 

[The_Doc_Man]

By any chance is this a non-split database i.e. monolithic? Your discussion in post #8 suddenly made me wonder.

 

[moanz]

By any chance is this a non-split database i.e. monolithic? Your discussion in post #8 suddenly made me wonder.

No this is occurring on a brand new tester accdb file that I created just to prove the behaviour. If I create a new db & form, I get the same, so I think it is a problem with the environment rather than the project.

 

[MarkK]

I have this problem routinely. I run a script when my last form closes with code...

Dim oShell : Set oShell = CreateObject("WScript.Shell")
' wait five seconds
WScript.Sleep 5000
' then kill access
oShell.Run "taskkill /f /im MSACCESS.EXE", 0, True
' clean up
Set oShell = Nothing

If users have this problem, they can subscribe in their User Preferences to automatically run this script run when they exit the database. It doesn't happen on all machines, but if the hidden instance is running, Access doesn't start.

 

[moanz]

In case it helps anyone else, I finally figured out what was causing this problem. I had Grammarly for Windows & Grammarly for Office installed on one user account but not the other. That seems to be keeping the process open. If I close the Grammarly for Windows tray icon, the problem goes away.

I'm not really sure if it's a problem for MS or Grammarly to fix.