This article provides a quick comparison between C++/CLI and C#. It’s meant for those who know C# (and possibly C++) and will explain which C++/CLI language construct correspond with which in C#. (I don’t know Visual Basic so I can’t add infos about this here.)
Note: This is not a complete reference but rather quick reference for those features that are (in my opinion) the most unclear.
So, I’m working on my WPF application and everything runs fine, but when I close it, I get this error message (together with this doesn’t-say-me-anything stacktrace):
[System.ComponentModel.Win32Exception] {"Invalid window handle"}
WindowsBase.dll!MS.Win32.HwndWrapper.DestroyWindow(object args) + 0x11a bytes
WindowsBase.dll!MS.Win32.HwndWrapper.Dispose(bool disposing, bool isHwndBeingDestroyed) + 0x8c bytes
WindowsBase.dll!MS.Win32.HwndWrapper.Dispose() + 0x14 bytes
PresentationCore.dll!System.Windows.Interop.HwndSource.Dispose(bool disposing) + 0x1f6 bytes
PresentationCore.dll!System.Windows.Interop.HwndSource.WeakEventDispatcherShutdown.OnShutdownFinished(object sender, System.EventArgs e) + 0x33 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.ShutdownImplInSecurityContext(object state) + 0x49 bytes
mscorlib.dll!System.Threading.ExecutionContext.runTryCode(object userData) + 0x51 bytes
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6a bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool ignoreSyncCtx) + 0x7e bytes
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x2c bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.ShutdownImpl() + 0x72 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame frame) + 0xe1 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame frame) + 0x49 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.Run() + 0x4c bytes
PresentationFramework.dll!System.Windows.Application.RunDispatcher(object ignore) + 0x17 bytes
PresentationFramework.dll!System.Windows.Application.RunInternal(System.Windows.Window window) + 0x6f bytes
PresentationFramework.dll!System.Windows.Application.Run(System.Windows.Window window) + 0x26 bytes
PresentationFramework.dll!System.Windows.Application.Run() + 0x1b bytes
GuideDock.exe!GuideDock.App.Main() + 0x94 bytes
mscoreei.dll!__CorExeMain@0() + 0x38 bytes
mscoree.dll!748c7f16()
[Frames below may be incorrect and/or missing, no symbols loaded for mscoree.dll]
mscoree.dll!748c4de3()
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
This problem seemed to appear only randomly until I figured it out today. The problem can be reproduce by this XAML/C# code (together with a WPF window):
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); this.m_touchCanvas.MouseLeave += (s, e) => CrashAppOnClose(); } private void CrashAppOnClose() { Window wnd = Window.GetWindow(this.m_touchCanvas); // This line throws a Win32Exception with "Ivalid window handle". wnd.PointToScreen(new Point()); } } |
Now, when the user closes the window (without using the mouse; eg. with Alt+F4) while the mouse is still in the window, the call to wnd.PointToScreen() (line 11) results in the Win32Exception above. Unfortunately, the doesn’t seem to be any way to check whether this exception will be thrown – I already tried Window.IsLoaded as suggested here with no luck.
What’s more annoying is that the call to PointToScreen() does not appear in the stacktrace. I can’t even imaging how this is possible. That’s why it took me ages to figure this one out.
Btw: I’d like to send a bug report to Microsoft but they haven’t got my account working in three months.
Updates:
Win32Exception can’t be caught in a try ... catch block. Both PointToScreen() and the point where the exception is thrown are on the same thread.I’ve managed to create a bug report for this problem.
Solution/Workaround:
Given the 32-bit error message – which reads “This Visual is not connected to a PresentationSource.” – I found a way to circumvent this problem. You need to use PresentationSource.FromVisual like this:
private void CrashAppOnClose() { Window wnd = Window.GetWindow(this.m_touchCanvas); if (PresentationSource.FromVisual(wnd) != null) { wnd.PointToScreen(new Point()); } }
Today I tried the software I’ve been writing on another computer – and it immediately crashed. I got this error message:
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly ‘TrackerInterface-Mixed-Full.dll’ or one of its dependencies. The specified module could not be found.
Here, it tells me that my DLL “TrackerInterface-Mixed-Full.dll” could not be loaded. The first thing I thought was that the application couldn’t locate this DLL – because of the FileNotFoundException. Unfortunately this wasn’t the problem.
So I figured “or one of its dependencies” was the real problem. However, the error message doesn’t tell you what dependency (DLL) is actually missing – even when debugging.
So, I did some searching and found the Assembly Binding Log Viewer (or “Fusion Log Viewer”) which comes with Visual Studio. Unfortunately it didn’t do what I needed. It seems that this is actually more for .NET assemblies rather than native DLLs. (You need to run it with Adminstrator rights; otherwise it won’t work. Just in case you’ll ever need it.)
After some more searching I found a tool called Dependency Walker. And that’s exactly what did the trick. So I opened “TrackerInterface-Mixed-Full.dll” with it and got the following result:
Here you have my “TrackerInterface-Mixed-Full.dll” at the top of the tree and its dependencies listed below it. For one, you can see immediately that the file “QTCORED4.DLL” is missing. But you can also see that one dependency (“MAPPARSERD1.DLL”) is missing some dependencies as well. (Fortunately, Dependency Walker automatically expands all dependencies that again have missing dependencies.)
I hope this helps in case you’re running into this problem yourself.
Note: The part “The specified module could not be found.” of the error message indicates some missing DLLs. There can be other reasons for getting a “Could not load file or assembly ‘Assembly.dll’ or one of its dependencies.” which then have other texts after this one.
Note 2: This only seems to happen when using native DLLs from .NET applications/assemblies.