9

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)
Jason Aller
  • 3,541
  • 28
  • 38
  • 38
Manuel Amstutz
  • 1,311
  • 13
  • 33
  • Just a small point. If you're using WPF, use `System.Windows.Threading.DispatcherTimer` (the WPF timer) not the general C# timer. Dunno if that will fix your issue though. – sircodesalot Feb 07 '13 at 15:58
  • Thanks for the hint. But in this case the operation should not be executed on the UI thread. This operation should run on a seperate thread, because it does only update the data context (takes a while) and fires the property changed event. – Manuel Amstutz Feb 07 '13 at 16:03
  • Which version of Visual Studio? – ΩmegaMan Feb 07 '13 at 16:12
  • VisualStudio 2010 Win7 64bit – Manuel Amstutz Feb 07 '13 at 16:25

3 Answers3

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

Community
  • 1
  • 1
sircodesalot
  • 11,231
  • 8
  • 50
  • 83
  • No I think it is correct to update the data context from a non UI thread. – Manuel Amstutz Feb 07 '13 at 16:08
  • Right, but when you say: `if (null != DataContext)`, it looks like you're actually hitting the view.DataContext property, and not just the datacontext itself. Try taking that line out and see what happens. – sircodesalot Feb 07 '13 at 16:10
  • Or try even just using a dispatchter timer and see if that doesn't fix the issue. Your code can stay almost identical, just change the name of the timer to System.Windows.Threading.DispatcherTimer. If that ends up being the case, then you can still execute code on another thread, you'll just have to use `Invoke` when you want to make the final changes to the UI object (i.e move execution back to the main thread). – sircodesalot Feb 07 '13 at 16:13
  • I have tried it with the dispatcher timer. Unfortunately without success. The debugger still freezes. I also commented out all code inside the timer handler. There is only a trace point which only prints some text and visual studio still freezes – Manuel Amstutz Feb 07 '13 at 16:35
1

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

Smaug
  • 2,625
  • 5
  • 28
  • 44
1

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.

Manuel Amstutz
  • 1,311
  • 13
  • 33