C# WPF应用程序中的自定义tracelistener冻结GUI

完全重写这个问题，因为我现在有更多关于正在发生什么的信息

我有一个customtracelistener，它重写writeline方法，向自定义observablecollection添加字符串。此集合类将所有通知事件分派到UI线程，以允许其他线程更新它，并且仍然允许WPF数据绑定

我有一个usercontrol，其中包括一个listbox。listbox将跟踪侦听器中的observablecollection绑定到它的itemssource

在应用程序启动时，我设置了windows/usercontrols/viewmodels，并显示了窗口。然后，我启动了一个工作线程，该线程运行应用程序所需的一些后端进程。如果后台线程在UI线程完成所有用户控件设置和数据绑定之前执行Trace.WriteLine，则我的应用程序会死锁

我已经能够通过在UI线程中添加睡眠和其他随机长时间运行的任务和/或延迟启动工作线程来给UI线程时间来完成，从而在某种程度上合理地证明这种竞争条件

---

我现在想实现的解决方案是创建一个

AppSetupCompleted

方法，该方法启动所有后端进程的工作线程，并以后台优先级将其发送给调度程序。从理论上讲，这是否应该延迟工作线程，直到WPF控件和viewmodels的所有绑定都成功设置为止？

听起来像是死锁或活锁。。。假设死锁（应用程序冻结时cpu不足），将调试器连接到应用程序并将其中断。查看线程的调用堆栈（UI和从中调用Trace.WriteLine的UI）以查看它们的锁定位置。

---

如果您无法找出阻塞的原因，请将调用堆栈添加到您的问题中，这可能有助于我们回答您的问题。

打开捕获所有抛出的异常，看看会发生什么。请原谅我对此类内容不熟悉，但我如何才能获取各种线程的调用堆栈。通过单步执行代码，我发现工作线程没有阻塞，并且通过了Trace.WriteLine调用。只是GUI线程锁定了。你的回答明确地为我指明了正确的方向。竞争条件似乎与UI线程在observablecollection上进行初始枚举有关，而其他线程正在修改它。正确的解决方案可能是重写ObservaleCollection以使其实际上是线程安全的，但是我不确定在不完全重新实现它的情况下是否能够做到这一点。通过为后台任务创建AppSetupCompleted方法，立即解决了问题。然后我用后台优先级调用begininvoke并创建一个线程来运行它。