Access re-launches after close

[OldDBGuy]

I am having an issue with a new Dell PC. It passes all of their on-line diagnostic tests so I am not sure that the PC is the issue.
Basically, when I have almost any MS Access database open, and I dink around in the VBE (whether or not I make any changes) and then I close the VBE and later close MS Access, there is an 80% chance that MS Access will re-open (to the blank Access page where you can choose to create new, etc.) about 15 seconds later. I am a seasoned Access developer so all of my databases are de-compiled/re-complied, compacted/repaired, have no hanging objects in memory (RS.close, set DB=Nothing, etc.). And, I do not have this issue on any of my other PCs. Just the brand new Dell XPS-8940.

It appears that MS Access thinks it has crashed (as it closes) and thus the attempt to re-open. I have a WER log FULL of App-Crash events for MS Access.
Mind you everything runs just fine, until I close the database (almost any database).
I'm attaching the problem signature from the Even Viewer and I am hoping that DOC (or somebody) can point me in the right direction, as I have no idea what it indicates. I can (if need be) post the entire WER Metadata Dump but did not want to clutter this post with a lot of unnecessary stuff.
If somebody can, please let me know where to look for this issue, I would be most appreciative.

Problem signature:
P1: MSACCESS.EXE
P2: 16.0.14701.20226
P3: 61a92e56
P4: combase.dll
P5: 10.0.19041.1348
P6: baf10630
P7: c0000005
P8: 00000000000b1303
P9:
P10:

 

[sxschech]

I had similar experience a month ago. I closed the open form and then closed the database. After that I closed Access and then Access reopened itself and the file I just closed. It may have to do with another windows or office update as after a week of this annoyance, it stopped happening.

 

[GinaWhipp]

Hmm, not that I have had this happen but the first I would try is an Office Repair.

 

[arnelgp]

not sure whether DEP has something to do with it?

 

[OldDBGuy]

not sure whether DEP has something to do with it?

I’ve reinstalled 64 bit office. I’ve reinstalled Windows 10 pro. Ran sfc. Have all of the latest updates. Have the same exact version of Office/Access on a Windows 11 pc, and no problem with it. Have not had time to run a deep memory test, but that is next on my list. Any other ideas?

 

[OldDBGuy]

About ready to give up! I ran a better memory test on the new PC (the one with the issue) and it passed. Then, I took a close look at the even log on the other PC that has the identical version of office (but running Win 11 Pro instead of Win 10 pro). And, lo and behold there were several similar APPCRASH events (1001) in that log as well specifying MS Access.exe.

However, I do not recall MS Access ever re-launching after close on that PC. So, I have an event log FULL of MS Access crashes on the new PC, and it does not pertain to any one database. And, about 70 - 80% of the time, after I close an Access database, MS Access re-starts about 15 seconds later (Yes - about 15 SECONDS!) Doesn't do it all of the time, but it does it a LOT. I can eventually update the offending PC to Windows 11 Pro, but I do not want to do that just yet. And, I still have no idea what the issue might be.

Scanned for viruses
Ran SFC/SCANNOW
Ran DISM /online /cleanup-image /restorehealth
Re-installed MS Office 64 bit
Re-Installed Windows 10 Pro
And, there are NO OTHER ISSUES with this new PC. MS Access RUNS just FINE. I can code, and test, and de-compile/recompile, and compact/repair any database with no issues. It only get's weird when I close a database. I'm getting used to waiting 15 seconds to see if MS Access restarts before I proceed to my next task. (Sigh...)

 

[OldDBGuy]

About ready to give up! I ran a better memory test on the new PC (the one with the issue) and it passed. Then, I took a close look at the even log on the other PC that has the identical version of office (but running Win 11 Pro instead of Win 10 pro). And, lo and behold there were several similar APPCRASH events (1001) in that log as well specifying MS Access.exe.

However, I do not recall MS Access ever re-launching after close on that PC. So, I have an event log FULL of MS Access crashes on the new PC, and it does not pertain to any one database. And, about 70 - 80% of the time, after I close an Access database, MS Access re-starts about 15 seconds later (Yes - about 15 SECONDS!) Doesn't do it all of the time, but it does it a LOT. I can eventually update the offending PC to Windows 11 Pro, but I do not want to do that just yet. And, I still have no idea what the issue might be.

Scanned for viruses
Ran SFC/SCANNOW
Ran DISM /online /cleanup-image /restorehealth
Re-installed MS Office 64 bit
Re-Installed Windows 10 Pro
And, there are NO OTHER ISSUES with this new PC. MS Access RUNS just FINE. I can code, and test, and de-compile/recompile, and compact/repair any database with no issues. It only get's weird when I close a database. I'm getting used to waiting 15 seconds to see if MS Access restarts before I proceed to my next task. (Sigh...)

Lately, this is what shows up in the Even Log:
Fault bucket 1374643201473705203, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: MSACCESS.EXE
P2: 16.0.14701.20262
P3: 61ba84b9
P4: clr.dll
P5: 4.8.4420.0
P6: 6109cbc8
P7: c0000005
P8: 00000000001186f2
P9:
P10:
Almost always clr.dll. And, MS Access still re-launches after about 15 seconds (because it thinks there was a crash I guess). Any suggestions? (Please read previous posts first). Thanks!

 

[arnelgp]

did you check whether it was an issue with DEP? (post #4).
there is somewhat similar issue here:
Solved - Access 2003 database under Windows Serwer 2019 - form open restarts application | Access World Forums (access-programmers.co.uk)

 

[The_Doc_Man]

First... P1 tells you the crashing primary task. P2 is the build number of Access. P3 is the low-order 32 digits of the 64-bit internal timestamp. P4 is the name of the faulting module, which in your 2nd case is CLR.DLL - which is part of .NET, and P5 is the build number of the faulting module. P6 is another low-half of the timestamp. It is theoretically possible for the P1 and P4 elements to be the same, in which case P2 and P5 will also match, but I'm not sure about P3 and P6

P7 tells you that the error was C0000005 - which breaks down as "C" = critical fault ("8" would be "not so critical"), next 3 digits "000" says it is a "system" thing, not an Access thing. Next four "0005" tells you it is a memory fault. Can't tell from the dump which of two possible faults is involved, but it is either a reference to a memory location that is non-existent or an attempt to write to a write-locked memory location. This is in the class of "unrecoverable" errors (which is what is meant by the "C" in lead-off position.) I.e. your code can NEVER repair this class of fault because it is a hardware condition, not a software condition. Even though it might be caused by software doing something that leads to the "whoops" situation.

P8 is the 64-bit address (probably virtual address) of the faulting instruction.

In your earlier example, you had a COMBASE.DLL fault. In the second one, you had a CLR.DLL fault.

COMBASE.DLL is an important part of the MS Office COM structure - the thing that helps map data structures into the Component Object Model (COM) that is the basis of VBA automation. CLR.DLL is a component most often used in .NET apps.

I'm going to guess that somewhere on that crashing machine, you have an application dump file that probably took about 15 seconds to build and format for diagnostic purposes. Or perhaps more than one such dump file. I have seen this kind of behavior but it is a real bear to trace it out. In essence, like other Office products and several browsers, if you have an app crash, the app tries to restore you to the last place you were when the crash occurred. So that behavior is actually trivial to explain. It is a restoration attempt after a crash.

The hard part is how you are getting EITHER of those two items (COMBASE and CLR) to crash like that. Usually, when a deep .DLL crash occurs, it is not something that you can easily cause to happen. It doesn't help that you say this happens on multiple app files. And it REALLY doesn't help that you have this behavior during shutdown. I'm going to go out on a limb here to ask if you are at any time opening some type of application object in these DBs, and if so, which one or which ones? If this was always the same app, I might have advice for localizing the problem. From what you say, though, it is not isolated to a single app. Which means I don't have anywhere near enough to give more specific debugging advice.

I did some web searches. Here are a couple of results.

In this thread, the CLR.DLL crash may involve a hotfix. I don't know that it applies to your system, though. You would have to pursue it by following the thread to see where it leads.

app crashing due clr.dll fault module

social.technet.microsoft.com

In this thread, the COMBASE.DLL crash with similar characteristics (C0000005) is noted, but there is no hint of a fix. All I can tell you is that this is not a unique problem. That is probably cold comfort.

https://answers.microsoft.com/en-us/windows/forum/all/combasedll-error/dd83e63b-f4e9-4b99-aa37-c80600d2e0ac

I recommend you do some web searches for "COMBASE.DLL crash" and "CLR.DLL crash" to see if you can find other cases, in hopes that you can find someone that found a fix for this.

Now, an observation: In the past, when I have encountered C0000005 crashes, they were USUALLY caused by faulty subroutine calls that failed to provide a value for a pointer (object) variable, so instead the call was for address 0 - which is actually illegal in both MS-DOS and Windows tasks. It is illegal precisely BECAUSE that is how Microsoft catches faulty calls. The "moral equivalent" of this kind of call would be if something set some object variable to NOTHING and then tried to use the object variable in a call anyway.

 

[OldDBGuy]

First of all, my apologies! I was busy for the last several days and have not had time to respond. So, please bare with me.

Arnelgp, - I turned off DEP for everything (had to disable secure boot first) and the problem still occurred.

THE_DOC_MAN Thanks you SOOooo much for your very thoughtful reply. I have googled both the clr.dll crash and the combase.dll crash and so far nothing jumps out at me as related to my specific issue. Additionally, I ran the Mem86.exe suite of extended memory tests (booting from USB) on my new PC and after almost 4 hours it reported that all passed with no issues detected.

So, I wanted to report that I can open an MS Access database with the shift key held down (no code running, no forms open, etc.) then open a code window, and delete a white space (blank line) and then click on debug-compile and then close the database. And, VIOLA, the problem appears! (MS Access re-opens after about 10-15 seconds with either a CLR.DLL or a COMBASE.DLL crash in the event log.) However, although I'm almost 100% certain that this has happened in the past, I cannot get it to do so in the last few hours of PC use. And, I do not want to assert this as 100% accurate info until I can CONFIRM (old man's memory needs to be re-confirmed sometimes. ) !

The crashes are still occurring, but not as often as they were and therefore I'm finding it a bit harder to reproduce. I do know that it is not specific to any one database and I will confirm (as soon as I possibly can) that no code needs to be running and no forms need to be open for it to take place But, I have many appointments away from the PC over the next few days, so it may be awhile before I have more to report.

Again, thank you both VERY MUCH for your input so far, and please stay tuned.

PS: I never had this issue with 32 bit Office. In fact, I can run all of the same DBs on the 32 bit office machine with no issues whatsoever!
And, on the new PC they run just fine. I can decompile-recompile, compact-repair, launch - run - use the databases at will. The faux crash only happens when I click the red-x to close a database. Just FYI...

 

[The_Doc_Man]

I never had this issue with 32 bit Office. In fact, I can run all of the same DBs on the 32 bit office machine with no issues whatsoever!

Whoops! Now I have to ask a question: Since this runs correctly on 32-bit Access on a 32-bit machine, are you running the 32-bit version of Access on your 64-bit system OR is this a 64-bit Access running a 32-bit DB?

Where this question is going is, are you aware of the need to put some code in your subroutines and API declarations to handle the different kinds of pointers? Does "PtrSafe" have any meaning for you?

If not, you need to look at the implied problem of address incompatibility for 32-bit vs 64-bit Access.

If, on the other hand, you actually DO know about that, then I just read your response incorrectly and hastily jumped to confusions.

 

[OldDBGuy]

OK, Let me clarify! I do know all about 32 bit versus 64 bit (PtrSafe, LongPtr, etc.). And, I have no 32 bit "machines" (boat anchors) in my stable. I do however have a 64 bit Window 10 Pro machine that has 32 bit Office installed and that is the PC that does not exhibit the issue.

I also have another (3rd) PC running Windows 11 Pro that has 64 bit Office installed, and on that PC I have been able to find a small spattering of Event 1001 ID's in the log that are very similar to the ones on my "Main" PC. However, it happens very rarely on that PC. My "Main PC" is a brand new Dell that has not yet been updated to Windows 11 Pro and is therefore still running Windows 10 Pro. I want to keep it there for a while to stay 100% compatible with the Natural Gas company that currently contracts my software company to create/enhance/maintain an important portion of their billing system.

So, the issue only occurs on the 64 bit "Office" Installations. And, it takes place so rarely on the Windows 11 Pro PC that I would have never considered posting to this forum had that been my only experience. And, the fact that I do see a FEW of these events on that machine makes me suspect that there may be an issue of some sort with the 64 bit version of office that contributes heavily to this problem.

It's my new Dell that exhibits this behavior quite often that led me to search for answers. The Event 1001 App Crashes in the Log on this new PC are indeed Plentiful...! And, as I stated in my last post I will keep my eyes on the situation in an attempt to gather more clues over the next week or so.

Hope that helps and - Thanks Again!

 

[OldDBGuy]

OK. Just verified the following:
Open one of my Access Applications with the shift key held down (this is my unlocked development copy). So, no code running, no forms open, etc.. Now, open a module, make a quick edit, do a debug-compile from the ribbon menu and then close the database.

Count to 12 or so and up pops MS Access (thinking that it crashed) to the open a database page.

Event Log shows: (same as before)
Fault bucket 1374643201473705203, type 4
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: MSACCESS.EXE
P2: 16.0.14701.20262
P3: 61ba84b9
P4: clr.dll
P5: 4.8.4420.0
P6: 6109cbc8
P7: c0000005
P8: 00000000001186f2
P9:
P10:

 

[Gasman]

Try a sfc /scanow in a admin command window

 

[The_Doc_Man]

I do however have a 64 bit Window 10 Pro machine that has 32 bit Office installed and that is the PC that does not exhibit the issue.

So, the issue only occurs on the 64 bit "Office" Installations.

If you can swing it, switch all of the machines running Office 64-bit to instead run Office 32-bit. Unless you have folks who have million-row spreadsheets (because Excel 64-bit can do that), you don't need 64-bit versions and in fact won't notice the difference in performance after jumping to 32-bit versions. This is clearly a "bitness" issue even if you can't easily point to where and how it kicks in.

But... check your references on a 64-bit Office system, compare them to 32-bit Office system, and see if any of the 64-bit references are missing or broken or something equally unkind.

 

[OldDBGuy]

The company that I am currently contracted to just updated their PCs to 64 bit Office (thinking that someday soon this would be the best/only option). That is the only reason that I switched to 64 bit on my new PC. So, I cannot switch back right away, but I will try to do so as an experiment in the near future. If that resolves it, I will ask the boss to switch his machines back as well. Interesting that I just ran SFC /SCANNOW with admin privileges and the problem is now worse than ever. It even happened as I was opening a database. The database opened, but so did the blank MS Access screen!

 

[OldDBGuy]

OK here's the Latest:
I searched through the event log on my 64 bit Windows 10 Pro PC that has 32 bit office installed. And, I did indeed find Event ID 1001 with MS Access App Crash reporting both CLR.DLL and COMBASE.dll. with the c0000005 value. There are a few of these over the past few days/weeks that I occasionally used the machine. However, MS Access NEVER pops back open on this PC after one of those events have been logged. Likewise, it NEVER pops back open on my secondary PC (Windows 11 Pro with 64 bit Office) even though I can find several of these events logged there as well.

So, it would seem that the event does get logged as an issue on both 64 bit and 32 but Office and on different PCs. However, only my new Dell has MS Access popping back open all of the time. I don't know if that helps or not, but as I said before, everything runs well on this new PC and I can code, re-compile, compact/repair etc. and all of my custom database apps preform perfectly. It's only when I close a database that MS Access sometimes (way too often) re-launches.

So, for what it's worth. (Any other ideas would be appreciated.)

 

[arnelgp]

have you tried importing the objects of the troubled db to a new db?

 

[The_Doc_Man]

Event ID 1001 is a "fatal bugcheck" event in which something crashed. Remember when I analyzed the crash dump and explained about "C" at the left end of the condition code? Critical system errors can create this kind of log.

When this "12 to 15 second delay" occurs - is anything else active at that moment? I.e. does the mouse work? Can you switch views with Alt/TAB? Can you do anything EXCEPT wait for the restarting event? Because after further research, you have what APPEARS to be a fatal SYSTEM bugcheck. At first, I thought your delay was caused by the system taking a crash dump of the process - but that 15 second delay is too long. Access isn't that big to take that long to dump.

If your system really IS "whacked" at that point, temporarily unresponsive but it comes back, you might be taking what is called a "soft crash" because Access didn't crash... WINDOWS did. If your system actually IS momentarily dead, let me also ask: When you first reboot the system after it has been down for some reason, does that reboot take about the same amount of time as the delay you have reported before Access restarts spontaneously?

A "Fatal Bugcheck" is a case where the system has detected an impossibility, a fatal inconsistency in some system data structure, and the O/S cannot be allowed to continue because it appears to have been compromised by this bug, whatever it is. When you see that event 1001, is there a secondary event code listed? I have to admit it has been a while since I had to trace down one of those boogers and it isn't easy. But usually, there is the fatal bugcheck and there is a secondary code that could be looked up online to determine the real error.

Here is an article on event 1001 cases. It offers some tests and solutions, but understand that Windows is a HUGE operating system (in fact, it is a f**king pig wallowing at the memory trough) and there are LOTS of places where things can go wrong.

https://www.technipages.com/fix-windows-error-reporting-event-id-1001

You are starting to verge into territory where you might need to talk to Microsoft. Your experiment of opening Access with the SHIFT key to bypass stuff so that no code is running gives you grounds to explain to MS what happens when you open the VBA code, delete a white-space line, do your save/close operation, and watch it generate the event. In such a case, there is no doubt that it would not be your code causing this oddness. IF your company decides that it has to stay with Office 64-bit even though switching to Office 32-bit would fix the problem, then understand that you have to first get MS a purchase order for X hours of consultation time. (That's their service model.) Note that they probably WOULD tell you that your solution would be to switch back to 32-bit Office anyway because they have been known to take the "easy way out" on short-term service contracts.

 

[OldDBGuy]

Hey THE_DOC_MAN... Did you notice in my previous post that I do indeed have those same events in the log for the 32 bit office machine as well as the Windows 11 (64 bit) Office machine, but - I NEVER see MS Access re-Launch on those two PCs? Also, during that 12 - 15 seconds my PC is perfectly useable. I can open a browser or an excel file, etc. and then suddenly MS Access will pop open again. I thought at first that I did not see those events on the other two PCs, but I learned a bit more about searching the event log and by golly they are there! But those PC do not annoy me by re-launching MS Access after I close it. Just FYI. I will research using the link you provided however. THANKS!