2013-02-07 173 views
10

问题:Visual Studio 2010的挂在跟踪点

每当我试图打破或设置在调试器跟踪点,我们的应用程序和Visual Studio完全冻结。分离调试器后,应用程序继续。

此问题可能与WPF有关。我们已将我们的WinForm应用程序迁移到WPF。从那以后就会出现这个问题但我不能找到导致问题的代码的特定部分。我已经回滚了数百次提交,但没有成功。

它也可能与UI线程有关。如果断点设置在远离UI逻辑的地方,那么应用程序不会冻结,或者不会像UI线程中那样经常冻结。

[编辑:] 我使用的是Windows 7 64位与Visual Studio 2010

[更新:]

当Visual Studio挂起,和我尝试显示断点之前分离,消息“无法从一个或多个进程分离,所有未完成的func-evals尚未完成”。但是我已经禁用了调试选项中的所有func评估。 我认为我的问题是由func_evaluation导致的,无法完成或运行到超时。

有没有办法看到func_evaluation visual studio挂在哪里?

例子:

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 
} 

我已经尝试过:(没有成功)

  • 启用/禁用主机进程
  • 试图调试x86和x64处理
  • 推出visual studio with/SafeMode
  • NGEN更新
  • 禁用“财产评估和其他隐函数调用”在调试选项
  • 禁用符号服务器
  • 禁用符号加载
  • 删除WPF字体缓存
  • 标记几个UI与“DebuggerDisplay元素( “无表达一些文本”)”

Ticket Microsoft Connect

可能相关的问题:

因为我们的应用程序使用.NET远程与另一个进程进行沟通,我的问题我是作为here类似的东西。我已经将所有的注册事件都放到了自己的任务中,但没有成功。

从调试的Visual Studio 调试器输出:

我附上一个调试器Visual Studio和已观察到一些例外,(80010005)

,但我不知道wheter它们是相关的我的问题或不:

(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) 

谢谢你的任何想法或暗示

Manuel

+0

只是一个小点。如果您使用的是WPF,请使用'System.Windows.Threading.DispatcherTimer'(WPF计时器)而不是一般的C#计时器。不知道如果这能解决你的问题。 – sircodesalot

+0

感谢您的提示。但是在这种情况下,操作不应该在UI线程上执行。此操作应该在单独的线程上运行,因为它只更新数据上下文(需要一段时间)并触发属性更改的事件。 –

+0

哪个版本的Visual Studio? – OmegaMan

回答

1

谢谢你的提示。最后,我安装了VS 2012,调试器现在正常运行。看来在Visual Studio 2010调试器中确实存在一个错误/性能问题。

1

我越看越这个,我越怀疑它是因为你没有使用WPF计时器。如果您尝试使用常规的Timer类而不是WPF Dispatcher计时器,则可能会尝试更新非ui线程上的UI - 这可能会成为问题的原因(因为DataContext是UI在技术上)。

此处了解详情:

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

+0

不,我认为从非UI线程更新数据上下文是正确的。 –

+0

对,但是当你说:if(null!= DataContext)时,它看起来像是实际触及view.DataContext属性,而不仅仅是datacontext本身。试着把这条线路看出来,看看会发生什么。 – sircodesalot

+0

或者尝试使用调度计时器,看看是否没有解决问题。您的代码可以保持几乎相同,只需将计时器的名称更改为System.Windows.Threading.DispatcherTimer即可。如果结果是这样,那么你仍然可以在另一个线程上执行代码,当你想对UI对象进行最后的修改时,你只需要使用'Invoke'(即将执行移回到主线程) 。 – sircodesalot