VB.Net 3.5 MDI 应用程序 - MDIChild 窗体在使用 N 内存后停止打开

发布于 2024-09-08 11:47:02 字数 865 浏览 4 评论 0原文

我希望有人能够提供帮助!

我们有一个相当大的 VB.Net MDI 应用程序,它是从 VB6 转换而来的。当它第一次运行时没有打开 MDIChild 表单时,它使用大约 35,000K。随着越来越多的表单被打开(但没有关闭),内存使用量(根据任务管理器)逐渐增加到每个表单大约 4,000K。 (我知道TM只显示为应用程序分配的内存,而不是实际使用的内存。)

问题是,当分配的内存达到某个点时,该点根据目标机器上的可用内存而有所不同,在关闭一个或多个打开的表单之前,无法打开更多表单。可以打开的表单数量的“限制”似乎取决于机器的可用内存。

例如: - 在整机只有512M的虚拟机上,出现这种情况时,大约有7-8个表格,分配的内存约为80,000K。 - 在我们的终端服务器机器上,它有 3GB 内存,并且还运行各种其他急需的应用程序,它停止在大约 20 多个表单和大约 100,000 - 105,000K 的内存分配。

我尝试使用 perfmon 来查看是否存在泄漏,这表明使用情况稳定。

但是,即使我关闭表单,第一个关闭的表单分配的内存也只会下降约 3000K,然后每个关闭的表单都会下降 100K。如果我再添加一些表格,内存就会增加,如果我关闭一些相同的 -3000K、-100K 内存减少模式,则会再次发生。

有人以前遇到过这个吗?任何人都可以帮忙,因为这看起来有点像一个表演障碍!我期待您的回复。

顺便说一句,原始的 VB6 版本没有这个问题,如果您关闭每个表单,它的内存分配也会返回到开始时的状态,而不是分配逐渐增加,因为应用程序释放的内存少于分配的内存。

编辑:我刚刚在开发中遇到了同样的错误。看来 UserControl 中抛出了 WIN32Exception。错误是“创建窗口句柄时出错”。

感谢和亲切的问候, 杜安。

I hope someone may be able to help!

We have a pretty large VB.Net MDI application that has been converted from VB6. When it is first run up with no MDIChild forms opened it uses about 35,000K. As more and more forms are opened (but not closed) the memory usage (according to Task Manager) creeps up at approximately 4,000K per form. (I am aware that T.M. only shows allocated memory for the application, and not the actual memory used.)

The issue is that when the allocated memory reaches a certain point, which is different depending upon what the available memory is on the target machine, no more forms can be opened until one or more of the open forms are closed. The "limit" of the ammount of forms that can be opened seems to depend upon the available memory of the machine.

For example:
- On a virtual machine with only 512M for the whole machine it appears to be about 7-8 forms and the allocated memory is around 80,000K when this happens.
- On our terminal server machine which has 3GB and is also running various other thirsty applications it stops at around 20+ forms and a memory allocation of about 100,000 - 105,000K.

I have tried using perfmon to see if there is a leak and that is indicating steady usage.

However, even if I close the forms the allocated memory only drops by about 3000K for the first form closed and then 100K for each form closed after. If I then add a few more forms the memeory increases, and if I then close some the same -3000K, -100K meomry reduction pattern happens again.

Has any one come accross this before? Can any one please help as this is looking like a bit of a show stopper! I look forward to your replies.

Incidentally the original VB6 version does not have this issue and also will return it's memory allocation to that it started with if you close each form rather than the allocation gradually creeping up because teh app releases less than it is allocated.

EDIT: I have just managed to get the same error while in dev. It appears that a WIN32Exception is being thrown in a UserControl. The error is "Error creating window handle."

Thanks and kind regards,
Duane.

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

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

发布评论

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

评论(2

离旧人 2024-09-15 11:47:02

您的应用程序只是消耗 Windows 施加的句柄配额。默认情况下,它是 10,000 个句柄,尝试创建另一个窗口将失败,并显示“创建窗口句柄时出错”。

也许对于 VM 或 TS 安装来说这些限制较低,不确定。上限相当大,远离它应该不会有任何问题。在任务管理器中,使用“查看”+“选择列”并勾选“USER 对象”、“GDI 对象”和“句柄”。这些列中的任何一个无限制增长都是代码中存在错误的明确标志,例如未处理表单或控件。消耗更多内存是此泄漏的副作用。

Your app is simply consuming the quota of handles that Windows imposes. By default it is 10,000 handles, trying to create another window will fail with "Error creating window handle".

Maybe those limits are lower for a VM or TS install, not sure. The upper limit is rather enormous and you should never have any trouble staying far away from it. In Task Manager, use View + Select Columns and tick USER objects, GDI object and Handles. Any of these columns growing without bound is a sure sign of a bug in your code, like not disposing forms or controls. Consuming more memory is a side-effect of this leak.

月下凄凉 2024-09-15 11:47:02

事实证明,在释放 USER 对象之前,我们需要显式处理自定义 UserControl 中的每个单独控件。

It turns out that we needed to explicitly Dispose of each individual control in our custom UserControls before the USER Objects would be released.

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