0

When our application exits normally, on a 64 bit platform there is no exception. On a 32bit platform we get this very unhelpful exception that shows as a system error on Windows XP:

InvalidOperationException: Handle is not initialized.
    at System.WeakReference.set_Target(Object value)
    at System.Windows.Threading.Dispatcher.FromThread(Thread thread)
    at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
    at MS.Win32.UnsafeNativeMethods.IntDestroyWindow(HandleRef hWnd)
    at MS.Win32.HwndWrapper.DestroyWindow(Object args)
    at MS.Win32.HwndWrapper.Dispose(Boolean disposing, Boolean isHwndBeingDestroyed)
    at MS.Win32.HwndWrapper.Finalize()

We were able to determine this is a problem with an exception being thrown during finalization. Through brute force and a bit of luck, we were able to address some of the problem so that if the user opens and closes the application without loading any files it shuts down cleanly. As soon as the user opens a file, does work and closes the application, the exception shows up on shutdown--but only on 32bit machines.

The InvalidOperationException is thrown both after the application exits and the Application.Exit event is handled. The problem is a matter of scale. I've been trying to brute force my way through cleaning up and fixing finalizer and dispose method problems. The process has also introduced a few bugs due to misunderstanding which object was parent and child. I need to find out what classes are throwing the exception during finalization (most likely a null pointer exception) and which are not.

Berin Loritsch
  • 11,400
  • 4
  • 30
  • 57
  • Is there an inner exception in the InvalidOperationException? Do you have stack trace info (ie: can you reproduce in debug?) – Reed Copsey Jun 18 '13 at 17:12
  • No inner exception, no place to put a break point. It happens in debug, and that's how I got the information I did. You have the full stack trace I have to work with. That's the problem with finalizers. – Berin Loritsch Jun 18 '13 at 17:14
  • 1
    It is a stack trace from hell, it could only occur if the window is owned by the thread that runs this code. That indicates that your app is *creating* a window on the finalizer thread and, later, is trying to destroy it again. This can't come to a good end of course. Hard to imagine how this could happen, if you don't have finalizers of your own then getting help from Microsoft Support seems warranted. – Hans Passant Jun 18 '13 at 18:03
  • I only have a couple classes that create windows (thankfully), and those have been vetted. I'll double-check. Hmm, I wonder if there is a secondary window like the one that is created for drop down controls. – Berin Loritsch Jun 18 '13 at 18:26

0 Answers0