8

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!

Saw
  • 6,199
  • 11
  • 53
  • 104
  • You could always try one of the code profiling tools like Red Gate ANTS (I think they still do a free trial). That will at least give you where the code spent time - it might not uncover potential deadlocks (it could be long running tasks or deadlocks amongst other things) – Charleh Jan 02 '13 at 17:42
  • Tried it for days, I didn't got any useful information! tried debug-diag and other generic windows debugging tools, but didn't got the spicific point where my application hangs, I am pretty sure, that it is because of some bad XAML, I need tools for seeing the point where is the dispatcher hangs in XAML. – Saw Jan 02 '13 at 17:46
  • Does this happen on more than one machine? – Charleh Jan 02 '13 at 17:53
  • Yes, in many machines with many and many configurations! – Saw Jan 02 '13 at 17:58
  • I'm not sure SO can help. Normally I'd want to see some code; however it's really going to boil down to the nature of your application and what it does in response to the windows layout changes. If I had to guess I'd say there is some event that has a recursion issue. – NotMe Jan 02 '13 at 20:27
  • Better use some logging in your application. Which will help you, where your application is hanged. – Kishore Kumar Jan 02 '13 at 21:32
  • Do you have a version of your code base that used to work? Can you rollback back and reapply all the changes that have been made one at a time until it breaks again? – AlSki Jan 02 '13 at 21:44
  • Also don't forget that DataContexts will be populated during the Xaml creation so it might not just be a pure xaml change... – AlSki Jan 02 '13 at 21:46
  • @AlSki it is very very hard, I have limited the suspected changes in one month in source control, but there are hundreds of checkins! :( and I can't do the compression! – Saw Jan 05 '13 at 12:42
  • are you using any resources to create report? – D J Jan 05 '13 at 16:34
  • The hang happen if I created any instance of ReportViewer without doing anything with it!!! – Saw Jan 05 '13 at 16:58
  • are you using the [WinForms ReportViewer](http://msdn.microsoft.com/en-us/library/microsoft.reporting.winforms.reportviewer%28v=vs.100%29.aspx)? – Jake Berger Jan 07 '13 at 01:30
  • 3
    Post the callstacks of your threads when it is hung. Make sure to include calls to external code. – AndrewS Jan 10 '13 at 02:00
  • Try to raise your application process priority to High and see if it still hangs. – Alex Jan 10 '13 at 13:00

4 Answers4

9

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

Community
  • 1
  • 1
Mohammad
  • 1,930
  • 1
  • 21
  • 31
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.

Michał Kuliński
  • 1,928
  • 3
  • 27
  • 51
TomTom
  • 61,059
  • 10
  • 88
  • 148
  • I know that, I have done this as I've mentioned in my answer, the problem is that I am worried about the main reason that combined with the reportviewer and causing the hang, The hang may be raised in another circumstances and because a component other than ReportViwer! I need to know the main reason. or a way to find the main reason in my application, and I will state it here here if I found it. – Saw Jan 05 '13 at 13:27
  • The main reason is still the same - STA threading is mandatory. Every component may show this behavior when you ignore the fundamental building block of any windows UI in he last 30 years. – TomTom Jan 05 '13 at 14:04
  • I know that I have a mistake in some point, I need to know it, the hang behavior was not here when creating a reportviewer in another thread, but now, for unknown reason (I want to know) the program is hanging when doing it, this is my question. – Saw Jan 05 '13 at 15:54
0

After pausing in the VS debugger, open the Threads window on the Debug/Windows menu. Select them all and freeze them (from the context menu). Then double click on each thread to see where it is stuck. In addition, right click on the call stack and show external code.

Brannon
  • 5,324
  • 4
  • 35
  • 83
  • Didn't give me the point that causing the hang, the main thread is in sleep, join, but didn't know where! – Saw Jan 05 '13 at 12:48
0

there are several tricks I like to use on such occations:

I have this answer already in How can I debug an internal error in the .NET Runtime?

but this should cover your problem as well it logs every action until CLR collapses

IntelliTraceEvents And Call Information is an amazing trick to find extacly what happened before crush occured

Tools->Debugging->General->Enable .Net Framework Debugging

+

Tools->IntelliTace-> IntelliTraceEvents And Call Information

+

Tools->IntelliTace-> Set StorIntelliTace Recordings in this directory

and choose a directory

should allow you to step INTO .net code and trace every single function call. I tried it on a small sample project and it works

after each debug session it suppose to create a recording of the debug session. it the set directory even if CLR dies if im not mistaken

this should allow you to get to the extact call before CLR collapsed.

Asecond trick

that might be used in production is this awesome framework called PostSharp:

notice this tutorial:

http://www.sharpcrafters.com/solutions/logging

after you use postsharp as described.

you can for every single function in your system when it was entered when it was termineted and if an exception was throwen log all variables.

and do all this using a few dozen lines of code.

Community
  • 1
  • 1
Nahum
  • 6,959
  • 12
  • 48
  • 69