Thinking about this, I remember something that MAY be related. But it might not be that helpful.
Windows talks about "processes" as places to get things done. For Windows, in order for you to run code, that code must be in the context of a process. I.e. Code doesn't run in a software vacuum. All of the things you do are somehow recorded in the memory associated with/allocated to that process. In Task Manager, there is a Processes tab that lets you see all of the processes defined on your system.
When you terminate a process, part of that termination involves returning resources to their respective resource pools. During this termination, you will have user memory, display "resources", and some object-related data structures in system memory or other "flavors" of memory based on how and from where they were assigned. An important step is to get rid of all open I/O channels because they will hold links to data structures such as "handles" - which are often device-driver-related or file-related or network-socket-related.
The termination code enters what is called an "I/O rundown" to terminate all activity through each handle in turn. BUT... if certain operations are still under way, when you try to terminate handle activity to a cooperating process, that process CAN say "No" if for some reason it would lead to inconsistent system-level data. If you have already closed the display and keyboard channels - which usually DO close without a problem - it then becomes impossible to notify you that your terminating process isn't terminating. It gets hung in a failed I/O rundown with no way to advise you of that painful situation.
It is possible that a hung process will refuse to terminate even after a manual "kill" with Task Manager or with the CMD prompt commands mentioned earlier in this thread. The only way to clear such processes is to reboot. In such cases, you might see a notice on screen during the system shutdown that Windows is waiting for task X to terminate, and you might even see it ask for permission to force termination. If you see one of those and the process was one you THOUGHT you had already killed, it was probably hung in rundown.
Therefore, as a matter of conjecture rather than certainty, I would suggest that some patch has left open a path for Access to refuse termination due to a reluctant I/O channel (as identified by its handle). This refusal MIGHT appear in the system event log as seen through Event Viewer, though that is by no means a certainty.
I said earlier that my memory here might not be helpful. That is because if it IS a failed I/O rundown case, in extreme cases like this, there is nothing you can do short of a reboot. However, if the rundown failure was simply bad timing that led to something timing out, a later manual kill might work. But usually, when you get a process hung like this, it can no longer execute further self-cleanup because it enters that "rundown" state and at that point, it will no longer execute code. It is in an "involuntary" wait state that only Windows can release.
It MIGHT be possible to use Task Manager >> Processes to identify a hung process and to determine its internal process ID. You could then open up Resource manager (from Task Manager >> Performance, bottom of the screen) to see if you can identify any resources being held by that process. It MIGHT give you insight as to which connection failed. But I wouldn't hold my breath on that one.
