Visual Studio 2008 ContextSwitchDeadlock 与 log4net 和 NHibernate

发布于 2024-09-02 01:59:38 字数 1228 浏览 2 评论 0原文

我在这里面临一个非常奇怪的错误,我不确定我是否遵循正确的路径来解决它,甚至不确定如何解决它。

这是我面临的问题:我开始调试一个使用 log4net、NHibernate 和 LINQ to NHibernate 的 WPF 应用程序,当我尝试从数据库获取实体时,我的应用程序和有时 VS 挂起很长时间,之后此时会打开一个异常对话框,显示一条消息,其中包含有关 ContextSwitchDeadlock MDA 的以下信息:

CLR 在 60 秒内无法从 COM 上下文 0x34fc1a0 转换到 COM 上下文 0x34fc258。拥有目标上下文/单元的线程很可能执行非泵送等待或处理非常长时间运行的操作而不泵送 Windows 消息。这种情况通常会对性能产生负面影响,甚至可能导致应用程序变得无响应或内存使用量随着时间的推移不断累积。为了避免这种情况

我将代码文件复制到一个新项目并删除了旧项目,以查看是否可以使此消息消失,认为这与我的配置有关。我开始一次添加一些东西来看看是什么导致了它,当我包含 log4net 配置代码时,错误再次出现。首先,我通过 AssemblyInfo 包含它,后来在应用程序启动时通过代码配置包含它,并且完全没有任何改变:(

所以,这是我的发现:

  • 它只发生在我使用 log4net 时。
  • 它发生在 NHibernate 从数据库加载实体时( 我不知道这个错误的根源是什么。它仅在 Visual Studio 中进行调试时发生,

我尝试按照下页的“启用和禁用 MDA”部分中的步骤操作。 href="http://msdn.microsoft.com/en-us/library/d21c150d.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/d21c150d.aspx< /a>,但这也不起作用,VS 仍然挂起,并且内存使用量增加,

当我正常运行程序时,这些都不会发生,所以我很确定这不是死锁情况,正如这个问题所表明的那样: contextswitchdeadlock (我也尝试过那里发布的解决方案)。

因此,我决定禁用 log4net。并在部署我的应用程序时再次启用它。

我发布这个问题是为了了解其他人是否遇到过这个错误,或者是否有人对如何解决它有一些建议。最后,它可能会帮助其他面临同样问题的人。

I'm facing an extremely weird bug here and I'm not really sure If I'm following the right path to solving it or even how to solve it.

Here is the problem I'm facing: I start debugging a WPF application which uses log4net, NHibernate and LINQ to NHibernate, and when I try to get an Entity from the database my application and sometimes VS hang for a lot of time, and after a while an exception dialog opens showing a message containing the following information on a ContextSwitchDeadlock MDA:

The CLR has been unable to transition from COM context 0x34fc1a0 to COM context 0x34fc258 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this

I copied the code files to a new project and deleted the old project to see If I could make this message disappear, thinking it had something to do with my configuration. I started adding few things at a time to see what was causing it, and when I included log4net configuration code the bug appeared again. First I included it through AssemblyInfo and later trough code configuration on application startup, and absolutely nothing changed at all :(

So, here are my findings:

  • It only happens when I'm using log4net.
  • It happens when NHibernate loads an Entity from database (lazy loading).

I don't know what might be the source of this bug. It only happens when debugging in Visual Studio. I've tried following the steps on the "Enabling and Disabling MDAs" section of the following page: http://msdn.microsoft.com/en-us/library/d21c150d.aspx, but that doesn't work either, VS still hangs and it's memory usage increases.

When I run the program normally none of this happens, so I'm pretty sure this is not a deadlock situation, as this question suggests: contextswitchdeadlock (I've also tried the solutions posted there).

Because of that, I've decided to disable log4net and enable it again when deploying my app.

I'm posting this question to find out if somebody else has faced this bug or if somebody has some suggestions on how to solve it. Finally, it might help somebody else facing this very same problem.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

橘虞初梦 2024-09-09 01:59:38

使用 DebugAppender 时,会加载数据库中的所有实体,并将其所有数据写入调试输出。这导致了 ContextSwitchDeadlock MDA,因为它运行时间超过 60 秒。

禁用 DebugAppender 解决了我的问题。

感谢 Mauricio Scheffer 提供的小费。

When using the DebugAppender all the entities in the databases are loaded and all its data written to the debug output. That was causing the ContextSwitchDeadlock MDA since it tookmore than 60 seconds to run.

Disabling the DebugAppender solved my problem.

Thanks to Mauricio Scheffer for the tip.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文