Hang in unknown location in a very complex WPF application when windows layout changed because of creating ReportViewr in another thread

Question

I have a WPF application with a very complex XAMLs, I need a way to know the point that my application hang on, when I try to pause the execution, the application seems to not be hanging, the pointer will be on this line:

System.Windows.Application myApp;
.
.
.
.
myApp.Run(); // <== this line

This is happening when I change the layout of the task bar or when windows explorer crashed (the task bar is hidden), if I do those changes in a heavy repetition, the application will never recover, but when a small change done, the application will recover after minutes, I need to know the cause of this issue, I doubt in the complex XAMLs of my application, but I need a way to know the page or the component, or the whatever the source of this hang.

* EDIT *

I need a tool or a way to know what is the XAML that consuming the dispatcher time!

* EDIT *

I have got the exact reason of the hang, it is because of creating an instance of ReportViewer in another thread, When I removed the creation of the instance, It worked perfectly, the strange thing, that this mistake is existed in my application long time ago, but the hang has raised recently, I mean: my application will hang when you insert one of these codes in any location of my application:

        new Action(() =>
        {
            ReportViewer rv = new ReportViewer();
        }).BeginInvoke(null, null);

OR

        new Action(() =>
        {
            ReportViewer rv = new ReportViewer();
            rv.Dispose();
        }).BeginInvoke(null, null);

OR

        new Action(() =>
        {
            ReportViewer rv = new ReportViewer();
            rv.LocalReport.ReleaseSandboxAppDomain();
            rv.Dispose();
        }).BeginInvoke(null, null);

My questions:

1- What is the relation between changing the layout of windows (Resizing the task bar or moving it) and the report viewer which is not added to any visual tree, why this cause my application to hang??

2- How I can determine the location of the hang?

3- Some times the application will recover in few minutes (3-5), but some times the hang still for hours and the application will not recover, Why?

4- How I can I determine the component or configuration that caused my application to hang in this circumstances?

By the way, this is a very useful for the others if solved, We have spent very huge time to detect it, but didn't got the exact reason combined with the ReportViewer that causing the hang!

Answer 1

I will try to answer your questions as completely as I can:

The ReportViewer control is a Windows Forms control and Windows Forms has an issue that could cause, in the appropriate circumstances, the UI thread to lock and thus the application to hang.

When a WM_SETTINGCHANGED message is posted by Windows, the event System.Win32.SystemEvents.UserPreferenceChanged gets fired. Some of Windows Forms controls including ReportViewer listen to this event to update themselves when a system setting changes.

The UserPreferenceChanged event and in contrast to other regular events will call each handler using the SynchronzationContext of the subscribing thread. So if the ReportViewer was created on a thread other than the main UI thread (Dispatcher thread in WPF) the event firing code will try to do an invoke and wait the invoke to be finished which will never happen on that other thread thus freezing the UI.

To determine the location of the hang you can easily disable the option Enable Just my code in Visual Studio -> Tools -> Options -> Debugging and when the hang occurs just attach the VS debugger to your hung application this will show you that the application is hung inside UserPreferenceChanged event handling on a WaitOne call.

You can read more about this hang in these articles:

http://www.ikriv.com/dev/dotnet/MysteriousHang.html

Windows Forms Form hanging after calling show from another thread

Answer 2

Simple - do not create the ReportViewer in another thread. All elements tying into one UI hierarchy MUST come from the UI thread.

In the creating action, invoke back to the UI thread to do the actual creation in the UI thread.