Unhandled 'System.ComponentModel.Win32Exception' when using AvalonDock 2.0

Question

I'm using AvalonDock 2.0, and when ever I open a dock container, while on debugging mode the application crash (it works fine when running without debugging). I get the below exception:

An unhandled exception of type 'System.ComponentModel.Win32Exception' occurred in WindowsBase.dll

Additional information: The operation completed successfully

I came across this answer, which suggest to uncheck the boxes from the Exception Settings. The wired thing is that it worked the first time used it. but it doesn't any more. I've tried on other machines it doesn't work either. any suggestions to how to fix this.
Avalon code(exception thrown at line 5)

protected override IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled) {
            if (msg == Win32Helper.WM_WINDOWPOSCHANGING) {
                if (_internalHost_ContentRendered) {
                    // the below line throw the exception
                    Win32Helper.SetWindowPos(_internalHwndSource.Handle, Win32Helper.HWND_TOP, 0, 0, 0, 0, Win32Helper.SetWindowPosFlags.IgnoreMove | Win32Helper.SetWindowPosFlags.IgnoreResize);
                }
            }
            return base.WndProc(hwnd, msg, wParam, lParam, ref handled);
        }

Wescott

This is just bone-headed coding on the part of the library designer. They are throwing a Win32Exception with an error code that indicates success, probably ERROR_SUCCESS. The exception constructor is translating that error code to a message, which is "The operation completed successfully" — i.e., no error occurred. File a bug report with the library's maintainers. – Eulaheulalee

@CodyGray yes, that's right, but is there a way to stop catching the exception from the application side. as per the answer I've referenced in my question. the solution worked at first but it doesn't anymore. and I couldn't figure out why. – Wescott

The exception message that you posted here does not indicate that this is a first-chance exception. It is also unlikely that that would fix the problem anyway. It would require that there was a catch block somewhere in the library code that caught the exception and handled it. I'm not sure what you do to handle an exception that indicates success. – Eulaheulalee

@CodyGray it don't seem that they're using catch block anywhere, I downloaded the source code and run it on my machine which gives the exact same error that I get. I've updated my question to show the code where the exception occurs. -don't know if it would help- – Wescott

I assume you're running a 64-bit version of Windows? That would explain why the exception is silently swallowed when it is thrown inside of a window procedure. The design decisions in this library just keep getting worse. I can't even figure out why that line is throwing. The only thing that makes sense is that they have incorrectly annotated the P/Invoke signature for SetWindowPos with PreserveSig set to false. Which is causing a return value indicating success to be confused with a return value indicating failure. Did I mention you should file a bug report with the library's maintainers? – Eulaheulalee

@CodyGray you did mention it ;) appreciate your help thanks – Wescott

Well, I looked at the code, and it does not appear that they are doing that. The signature for SetWindowPos is here, and it just returns a bool indicating success or failure (which is correct). So I have no idea how that line you showed is throwing an exception. There must be something else going on. – Eulaheulalee

@CodyGray I'm trying to debug the code, and the method throws the exception after it got called like 30 times. I will try to contact them. meanwhile I guess I have to live with this. anyway thanks for your help :) – Wescott

@IBRA: I confirm your observation. The exception is thrown on the 31st call, every time. Odd. – Franciscka

Answer 1

Apparently there's an issue is filed, but with no response till this moment.

So as a workaround I have handled any unhandled exceptions using Application.DispatcherUnhandledException from App.xaml.cs.
Please check this answer for more details.
Code:

protected override void OnStartup(StartupEventArgs e) {
     base.OnStartup(e);
     this.DispatcherUnhandledException += AppGlobalDispatcherUnhandledException;
}

private void AppGlobalDispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e) {
     e.Handled = true;
}

Wescott

When running from within VS2015 in Debug or Release mode on Windows 10, the application will not terminate on shutdown when applying this solution. One needs to click the debug-stop button to finally terminate the app. Any ideas? – Momentarily

Answer 2

For anyone else landing on this page, I was able to get rid of the problem with the following setting turned off:

Tools > Options > Debugging > General > Enable UI Debugging Tools for XAML

Propitiate

Answer 3

My quick hack is that I disabled the UpdateWindowPos() in the LayoutAutoHideWindowControl class during debug config.

    internal void Show(LayoutAnchorControl anchor)
    {
        if (_model != null)
            throw new InvalidOperationException();

        _anchor = anchor;
        _model = anchor.Model as LayoutAnchorable;
        _side = (anchor.Model.Parent.Parent as LayoutAnchorSide).Side;
        _manager = _model.Root.Manager;
        CreateInternalGrid();

        _model.PropertyChanged += new System.ComponentModel.PropertyChangedEventHandler(_model_PropertyChanged);

        Visibility = System.Windows.Visibility.Visible;
        InvalidateMeasure();
#if !DEBUG
        UpdateWindowPos();
#endif
        Trace.WriteLine("LayoutAutoHideWindowControl.Show()");
    }

To my current experience, this results only in the disability to drag&drop of minimized dockable containers.

Pleat

or just #if !DEBUG (and omit the #ELSE) – Franciscka