如何调试和解决“DisconnectedContext”问题碰撞？
我有一个 GUI 应用程序，它连接到传感器、收集数据并使用 BackgroundWorker 线程在后台处理数据。
就目前情况而言，我正在使用 ProgressChanged 将数据发布到 GUI，这似乎一开始就运行良好。此后我提高了数据速率并发现了一个问题；如果软件运行几分钟，处理器使用量似乎会增加，直到我机器上的两个内核都达到接近 100%，此时，我收到一条错误，内容如下：
托管调试助手“DisconnectedContext”检测到“myapp.exe”中存在问题。附加信息：上下文 0xe2ba0 已断开连接。从当前上下文（上下文 0xe2d10）中释放接口。这可能会导致损坏或数据丢失。
我在网上读过一些资料，这些资料表明，如果 GUI 应用程序无法足够快地传送消息，就会发生这种情况。我注意到，如果我快速调整窗口大小（即加载更多消息），我可以更快地引发相同的崩溃，这支持我认为的理论吗？
所以这里的问题是：
- 是否有人同意我关于消息泵的假设？
- 是否还有其他解释？
- 有什么方法可以证明这一点（也许可以看看队列中的消息数量）？
- 这些糟糕的代码味道是否表明我的处理方式是错误的？
如有任何建议，我们将不胜感激。
I have a GUI app which connects to a sensor, gathers data and processes it in the background using BackgroundWorker threads.
As it stands I'm posting data to the GUI using the ProgressChanged which seemed to be working well to begin with. I've since upped the data rates and have discovered a problem; if the software is left to run for a few minutes, the amount of processor usage appears to ramp up until it reaches near 100% on both cores on my machine and at that point, I get an error which reads:
Managed Debugging Assistant 'DisconnectedContext' has detected a problem in 'myapp.exe'. Additional Information: Context 0xe2ba0 is disconnected. Releasing the interfaces from the current context (context 0xe2d10). This may cause corruption or data loss.
I've read some stuff around the web which suggests that this can happen if a GUI app is unable to pump messages fast enough. I've noticed I can provoke the same crash to happen faster if I resize the window rapidly (i.e. pump a load more messages) which supports the theory I think?
So the questions here are:
- Whether anyone agrees with my hypothesis about message pumping?
- Whether there's another explanation?
- Is there some way I can prove it (peek the number of messages in the queue maybe)?
- Are these all bad code smells that suggest I'm going about this the wrong way?
Any advice would be very gratefully received.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这听起来像是一个非常具体的问题，我认为这就是为什么还没有人回答的原因，但我认为我可以帮助解决问题#3。
Spy++ 应该能够看到消息去你的窗户。我认为您可以使用它来观察消息泵送到您的 GUI 并进行调整大小测试。如果您看到尝试处理的消息大量增加，则可能会证实您的假设。
顺便说一句，我读到您也许可以将主线程单元从 STAThread 更改为 MTAThread 以使此 MDA 消失。
也许您可以修改您的应用程序，将传感器读数吐出到文件中或以不同的机制将它们排队，而不是不断更新 GUI。
HTH。
This kind of sounds like a very specific problem and I think that's why no one has answered yet but I think I can help on question #3.
Spy++ should be able to see the messages going to your window. I think you could use it to watch the messages pump to your GUI and do your resizing test. If you saw a large increase of messages trying to be processed it might confirm your hypothesis.
As an aside, I've read that you might be able to change the main thread apartment from STAThread to MTAThread to make this MDA go away.
Perphaps you could modify your app to spit the sensor readings out to a file or queue them up in a different mechanism instead of updating the GUI constantly.
HTH.