Visual Studio 2010 hangs on trace point

Question

The Problem:
Whenever I try to break or set a Trace-point in the debugger, our application and visual studio freezes completely. After detaching the debugger the application continues.

This problem is probably related to WPF. We have migrated our WinForm application to WPF. Since then this problem occurs. But I'm not able to find the specific part of the code which causes the problem. I have already rolled back hundreds of commits but without success.

It might also be related to the UI thread. If the breakpoint is set somewhere away from the UI logic the application will not freeze or it will not freeze as often as it does somewhere in the UI Thread.

[Edit:]
I use Windows 7. 64bit with Visual Studio 2010

[Update:]
When Visual studio hangs, and i try to detach before the breakpoint is displayed, the Message "Unable to detach from one or more processes. All outstanding func-evals have not completed". But i have disabled all func evaluation in the debugging options. I think my problem is caused by a func_evaluation which can not complete or which runs into a timeout.

Is there a way to see on which func_evaluation visual studio is hanging?

Example:

class SomeUiViewPresenterExample
{
   private Timer m_Timer;

public void Init()
{
    m_Timer = new Timer();
    m_Timer.Elapsed += ElapsedFoo();
    m_Timer.AutoReset = false;
    m_Timer.Interval = 200;
}

private void ElapsedFoo(object sender, ElapsedEventArgs elapsedEventArgs)
{
    // there is no code inside this method
    // On the next line a trace point with "---> ElapsedFoo called" will freeze the debugger
}

What I have already tried: (without success)

• enable / disable the host process
• tried to debug x86 and x64 processes
• launched visual studio with /SafeMode
• NGEN update
• disabled "property evaluation and other implicit function calls" in Debugging options
• disabled symbol servers
• disabled symbol loading
• deleted WPF font cache
• Marked several UI elements with 'DebuggerDisplay("some text without expression")'

(Ticket Microsoft Connect)

Probably related problem:

Because our application uses .NET Remoting to communicate with another process, my problem my be something similar as here. I have placed all registrations to remoted events in a own Task, but without success.

Debugger Output from debugged visual studio:

I have attached a debugger to visual studio and have observed some exceptions,(80010005)

but I have no idea whether they are relevant for my problem or not:

(18d8.1708): C++ EH exception - code e06d7363 (first chance)
(18d8.1708): C++ EH exception - code e06d7363 (first chance)
..... // snip
(18d8.18dc): **Unknown exception - code 80010005 (first chance)
..... // 20 seconds freeze until breakpoint hit in IDE

(18d8.18dc): Unknown exception - code 80010005 (first chance)
(18d8.18dc): C++ EH exception - code e06d7363 (first chance)
ModLoad: 365f0000 36665000 C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Packages\Debugger\mcee.dll

// after continue execution debugger and debugged process freezes forever

(18d8.18dc): Unknown exception - code 80010005 (first chance)
ModLoad: 00000000`02b90000 00000000`02c1c000 C:\Windows\SysWOW64\UIAutomationCore.dll
(18d8.1a8c): CLR exception - code e0434352 (first chance)
(18d8.1a8c): CLR exception - code e0434352 (first chance)
(18d8.1a8c): CLR exception - code e0434352 (first chance)
(18d8.1a8c): CLR exception - code e0434352 (first chance)
(18d8.1a8c): CLR exception - code e0434352 (first chance)
(18d8.1a8c): CLR exception - code e0434352 (first chance)
(18d8.1a8c): CLR exception - code e0434352 (first chance)
(18d8.1a8c): CLR exception - code e0434352 (first chance)

Answer 1

The more I look at this, the more I suspect it's because you're not using the WPF timer. If you try to use the regular Timer class rather than the WPF Dispatcher timer, you run the risk of trying to update the UI on a non-ui thread - which could potentially be the cause of your problem (Since the DataContext is part of the UI technically).

More info here:

DispatcherTimer vs a regular Timer in WPF app for a task scheduler

Answer 2

You can use the windebug tool from this below url to better debugging and sort it out the solution

http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

Answer 3

Thanks for your hints. Finally I have installed VS 2012 and the debugger now behaves as normal. It seems there is really a bug / performance issue in the visual studio 2010 debugger.