Windows消息泵和outofmemory异常之间有什么关系? [英] What is the relation between windows message pump and outofmemory exception?

查看:81
本文介绍了Windows消息泵和outofmemory异常之间有什么关系?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您好,



我想了解我目前面临的一个问题。



我使用Winforms创建了一个C#应用程序。我有一个长时间运行的操作(几分钟)。

当我启动此操作直接在GUI层中的一个控件(例如,onButtonTestClicked())中测试它时,窗口是按照我的预期冻结,应用程序在内存中增长并增长到2千兆(!),导致这个OutOfMemory异常。

然而,当我在onButtonTestClicked()的新线程中启动我的长操作时,它只使用了200兆。

我怀疑这个问题与Windows消息抽取有关:当应用程序被冻结时,它无法按预期消息。但是所有内存空间的链接是什么?



你能解释一下原因吗?我很好奇。



谢谢!



我尝试过:



好​​吧,我在互联网上找不到多少东西。以下是一些文档:关于消息和消息队列( Windows) [ ^ ]



调试时,我收到以下错误消息:

CLR无法从COM上下文0x1a0b88转换到COM上下文0x1a0cf8 60秒。拥有目标上下文/公寓的线程很可能是在非抽空等待或处理非常长时间运行的操作而不抽取Windows消息。这种情况通常会对性能产生负面影响,甚至可能导致应用程序变得无响应或内存使用量随时间不断累积。为了避免这个问题,所有单线程单元(STA)线程都应该使用抽取等待原语(例如CoWaitForMultipleHandles)并在长时间运行操作期间定期泵送消息。

解决方案

< blockquote class =quote>

Quote:

windows message pump和outofmemory exception之间的关系是什么?



之间没有关系他们。或者关系是你的代码。

你的应用程序停止消息泵是你的应用程序忙于分配内存的第二个影响,但是没有看到你的代码,很难分辨。


不要阻止gui这么长 - 用户将在发布模式下获得应用程序无响应消息。所以使用线程。而你的第二个问题似乎来自你的调试 - 当你在时间关键函数中设置断点时(例如,SQL-Access超时)你会看到超时发生。


Hello,

I'd like to understand a problem I'm currently facing.

I created a C# application using Winforms. I have a long running operation (several minutes).
When I launched this operation to test it directly in one of my control in the GUI layer (say, "onButtonTestClicked()"), the windows was frozen as I expected, and the application grew and grew up to 2 giga in memory(!), causing this OutOfMemory exception.
However, when I launched my long operation in a new thread from onButtonTestClicked(), it used only up to 200 mega.
I suspect this issue is linked to Windows message pumping: when the app is frozen, it can't pump messages as it should. But what is the link with all that memory space taken?

Could you explain why? I'm quite curious about it.

Thanks !

What I have tried:

Well, I didn't find much on the internet. Here is some piece of documentation: About Messages and Message Queues (Windows)[^]

When debugging, I have this error message:
The CLR has been unable to transition from COM context 0x1a0b88 to COM context 0x1a0cf8 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 problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

解决方案

Quote:

What is the relation between windows message pump and outofmemory exception?


There is no relation between them. Or the relation is your code.
Your app stopping the messages pump is a secondary effect of your app being busy allocating memory, but without seeing your code, it is difficult to tell.


Don't block the gui for so Long - users will get the "application not responding" message in release mode. So use threads. And your second problem seems to come from your Debugging - when you set a breakpoint in a time-critical function (there is a timeout for SQL-Access e.g.) you will see the timeout occur.


这篇关于Windows消息泵和outofmemory异常之间有什么关系?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆