MDoerner
commented
6 years ago Let me add my observetions on Excel.
On my system (Excel 2013 x86, Windows 10), Excel seems to shut down properly, but in reallity it does not. Under the debugger, I get multiple exception on shutdown, but Excel chooses to shutdown with code 0 anyway. Moreover, there are still reports by other users of getting the recovery message on shutdown.
What the VS2017 debugger is telling me
On shutdown, I observe two distinct kinds of exceptions while running under the VS2017 debugger in mixed-mode with break on exception crossing the unmanaged/managed boundary set.
Winforms interop exceptions
The first kind of execptions are received via Winforms.
Exception thrown: 'System.Runtime.InteropServices.ExternalException' in System.Windows.Forms.dll
An exception of type 'System.Runtime.InteropServices.ExternalException' occurred in System.Windows.Forms.dll and wasn't handled before a managed/native boundary
External exception
There are six of these identical exceptions, which should be the same number as that of our dockable windows. The exceptions happen after our add-in shutdown code has finished and before the dockable windows actually receive a WM_DESTROY.
Access violations after everything is gone
The second kind of exceptions I observe are around 29 access violations, on which the mixed-mode debugger cannot stop.
Exception thrown at 0x71FD60D2 (clr.dll) in excel.exe: 0xC0000005: Access violation reading location 0x1A22CDAC.
The Common Language Runtime cannot stop at this exception. Common causes include: incorrect COM interop marshalling and memory corruption. To investigate further use native-only debugging.There are five distinct memory addresses in the numerous exceptions, if I counted correctly.
These access violations happen right after our last DockableToolwindowPresenter has been finalized. (The finalizer only exists for debugging purposes.) At this point, the vbe7.dll, the vbeiu.dll and the VBE7INTL.DLL have already been unloaded for a while.
bclothier
WaynePhillipsEA
retailcoder
PowerWeb5
NOTE: This issue is meant to be an aggregation of other issues, to bring up to the date the current state of the persistent problem of getting a clean exit consistently everywhere. Apparently it is reported to occur on some machines, but not all.However, for those machines where it do happens, it seems to be fairly consistent. It is important to note that the issue may have had multiple causes and though we've made significant progress in reducing them. In fact, the current version of Rudderduck is much better behaved compared to previous versions where it was more apparent and crashed hard. Nonetheless we are still dealing with a silent zombie on the shutdown.
Problem
Whenever the following are true:
1) VBA host was opened 2) Rubberduck was loaded and has DockWindows attached. In testing, we used Code Explorer docked and visible.
Then whenever the user closes the application -- it does not matter how the user closes, whether the VBA window was closed previously, or not -- then application will zombify silently. There is no
There was a problem and Windows is trying to find a solution. Rather the application is left hidden and must be then killed via the task manager.Errors look similar to this:
Exception thrown at 0x75CABB49 (ole32.dll) in MSACCESS.EXE: 0xC0000005: Access violation reading location 0x0ACCFC34. occurredor
NOTE: See next section for comments; this may be atypical. NOTE 2: It's likely that
KernelBase.dllis noise because this is exception handling. This should be ignored.Exception thrown at 0x74E0C54F (KernelBase.dll) in MSACCESS.EXE: 0xE0434352 (parameters: 0x80004001, 0x00000000, 0x00000000, 0x00000000, 0x720D0000). occurredWhat has been already tried
We already created a MCVE to demonstrate and while the numbers of errors aren't the same, they are similar enough to be possibly helpful. The slimmed version can be found here.
This is NOT host-specific. Though the above examples were from Access, reports has been made for Excel and Word and likely other hosts and errors are originating from the DLLs that are loaded by those hosts.
At one point, we tried explicitly releasing the objects, as documented here. But in the end we commented out the code because it was actually doing more damage than help. Further research indicates that we should not wantonly call
Marshal.RelaseComObject, especially for objects we don't own.However, @MDoerner did investigate the possibility of adding
Marshal.ReleaseComObjectto theCommandBarControlswhich are in use on the toolbars and in the menus since we do create those. Those did not help eliminate the errors but did not increase it, either.As alluded already, in the earlier build, we did a massive refactor where we wrap all objects in an abstraction, which was meant to implement the
Release, but even without that, we at least ensure that all our access go through the abstraction so that we have a well-defined points where we instantiate and where we destroy the references to COM objects we do not own.We also tried to implement
IDisposable, as documented here but this did not help and actually caused problems.We did fix a very subtle bug with correctly unregistering the event sinks used with this and that.
In previous versions, whenever we had a debugger attached and
Nativemode is enabled, the program would have broke into the dissembly and waited on our response. However with the current version (2.1.1), the error does show up but only briefly; after few seconds, the debugger abruptly stops. We think it's because the .NET part has already shutdown, but we are getting access violation long after. If we change the debugger mode toNativeexclusively, we are able to make the program break indefinitely, allowing us to inspect the stack trace.@bclothier also had installed a hotfix which was totally unrelated to the issue but did share same symptoms to see whether it would rule out the possibility of a defective Windows DLL outside the usercode. This did change the errors on the shutdown, causing it to error in
KernelBase.dllrather thanole.dllbut did not ultimately fix it. Also, this was limited to Windows 7 and the error has been reported on other operating systems. That said, it was determined that the same error occurred even in Excel as well.Additional details
You can review the other issues in this project to get more background or specific subsets that may or may not be relevant to the issue at hand.
References
Listed are links that we've already read in attempt to help us understand and implement any fixes.
https://msdn.microsoft.com/en-us/library/office/aa159887%28v=office.11%29.aspx?f=255&MSPPError=-2147217396
https://blogs.msdn.microsoft.com/visualstudio/2010/03/01/marshal-releasecomobject-considered-dangerous/
https://blogs.msdn.microsoft.com/cbrumme/2003/04/16/releasecomobject/
https://blogs.msdn.microsoft.com/oldnewthing/20100813-00/?p=13153