By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,041 Members | 1,018 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,041 IT Pros & Developers. It's quick & easy.

Menu Items Leaking

P: n/a
I have an MDI form with a single child form. I have found a couple of
circumstances that appear to cause the framework to leak Int32s, MenuItems,
MenuItemCollections and sometimes TRACKMOUSEEVENTs. This happens if I
disable/enable a menuitem, add a new menuitem programatically or click on an
entry in the mdiList menu. I am disposing the main menu in the child form
as well as in the main mdi form, so that's not the issue.

I have seen http://support.microsoft.com/default...b;en-us;817723
which appears to be either the same or a closely related issue, but
Microsoft says that this bug was fixed in v1.1 of the .NET Framework (which
is what I'm using).

Using the .NET Memory Profiler from SciTech it appears that these leaked
objects are being held in the allCreatedMenuItems hashtable in MenuItem. I
can hack around this problem by using reflection to access and clear that
hashtable in the MDI Dispose, but my company isn't comfortable with this
solution. They would prefer either a Microsoft based or recommended
solution.

Is this a know bug in the framework and is there a hotfix for it that anyone
knows of? Any suggestions?

Thanks,
Rich

Nov 20 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a

"Rich B." <ri******@hotmail.com> wrote in message
news:ug**************@TK2MSFTNGP12.phx.gbl...
I have an MDI form with a single child form.


Do you ever open more than one instance of the child form? If not, why use
MDI at all?
Nov 20 '05 #2

P: n/a
My client has asked me to determine why their production.Net MDI app is
leaking memory. I narrowed it down to the menu items. I have created a
very simple MDI app with a single child form to recreate the leak. I could
bring up more than one instance of the child form if I desired and probably
leak even more memory, but it wasn't necessary to reproduce this leak.

-Rich

"Jeff Johnson [MVP: VB]" <i.***@enough.spam> wrote in message
news:OX**************@TK2MSFTNGP09.phx.gbl...

"Rich B." <ri******@hotmail.com> wrote in message
news:ug**************@TK2MSFTNGP12.phx.gbl...
I have an MDI form with a single child form.


Do you ever open more than one instance of the child form? If not, why use
MDI at all?

Nov 20 '05 #3

P: n/a
Hi Rich,

Normally there should not be any reason to dispose a mnu item, because the
form inplements idisposable, every thing should be handled by the framework.

I never have seen this problem in this newsgroup (what says nothing maybe
however doing a search in google on this did as well give not any problem)

I know it is no answer, just an opinion, to help you going on in searching
for the problem.

Cor
I have an MDI form with a single child form. I have found a couple of
circumstances that appear to cause the framework to leak Int32s, MenuItems, MenuItemCollections and sometimes TRACKMOUSEEVENTs. This happens if I
disable/enable a menuitem, add a new menuitem programatically or click on an entry in the mdiList menu. I am disposing the main menu in the child form
as well as in the main mdi form, so that's not the issue.

I have seen http://support.microsoft.com/default...b;en-us;817723
which appears to be either the same or a closely related issue, but
Microsoft says that this bug was fixed in v1.1 of the .NET Framework (which is what I'm using).

Using the .NET Memory Profiler from SciTech it appears that these leaked
objects are being held in the allCreatedMenuItems hashtable in MenuItem. I can hack around this problem by using reflection to access and clear that
hashtable in the MDI Dispose, but my company isn't comfortable with this
solution. They would prefer either a Microsoft based or recommended
solution.

Is this a know bug in the framework and is there a hotfix for it that anyone knows of? Any suggestions?

Thanks,
Rich

Nov 20 '05 #4

P: n/a
"Rich B." <ri******@hotmail.com> wrote in message
news:ug**************@TK2MSFTNGP12.phx.gbl...
I have seen http://support.microsoft.com/default...b;en-us;817723
which appears to be either the same or a closely related issue, but
Microsoft says that this bug was fixed in v1.1 of the .NET Framework (which is what I'm using).


That particular link doesn't mention it as fixed in 1.1. Did you learn of
this another way?

Best Regards,

Andy
Nov 20 '05 #5

P: n/a
"Rich B." <ri******@hotmail.com> wrote in message
news:ug**************@TK2MSFTNGP12.phx.gbl...
I have seen http://support.microsoft.com/default...b;en-us;817723
which appears to be either the same or a closely related issue, but
Microsoft says that this bug was fixed in v1.1 of the .NET Framework (which is what I'm using).


That particular link doesn't mention it as fixed in 1.1. Did you learn of
this another way?

Best Regards,

Andy
Nov 20 '05 #6

P: n/a
The first thing we did was contact Microsoft to see if the fix from 817723
was incorporated into Framework v1.1. They said it was, so that hotfix
wasn't necessary if you're using v1.1.

I opened a case with Microsoft and they solved it for us. It turns out that
they didn't completely fix all menu item leaks for MDI forms in v1.1. They
just finished up a new hotfix 7/23/04 to fix the remaining menu leaks for
MDI forms. I believe they're still testing it and completing the
knowledgebase article before releasing it.

-Rich
"Andy Becker" <x@x.com> wrote in message
news:uX**************@TK2MSFTNGP10.phx.gbl...
"Rich B." <ri******@hotmail.com> wrote in message
news:ug**************@TK2MSFTNGP12.phx.gbl...
I have seen http://support.microsoft.com/default...b;en-us;817723 which appears to be either the same or a closely related issue, but
Microsoft says that this bug was fixed in v1.1 of the .NET Framework

(which
is what I'm using).


That particular link doesn't mention it as fixed in 1.1. Did you learn of
this another way?

Best Regards,

Andy

Nov 20 '05 #7

P: n/a
Rich,

Thanks for sharing this information with us?
(And now this is in the Google newsgroup search as well).

Cor
The first thing we did was contact Microsoft to see if the fix from 817723
was incorporated into Framework v1.1. They said it was, so that hotfix
wasn't necessary if you're using v1.1.

I opened a case with Microsoft and they solved it for us. It turns out that they didn't completely fix all menu item leaks for MDI forms in v1.1. They just finished up a new hotfix 7/23/04 to fix the remaining menu leaks for
MDI forms. I believe they're still testing it and completing the
knowledgebase article before releasing it.

-Rich

Nov 20 '05 #8

P: n/a
The first thing we did was contact Microsoft to see if the fix from 817723
was incorporated into Framework v1.1. They said it was, so that hotfix
wasn't necessary if you're using v1.1.

I opened a case with Microsoft and they solved it for us. It turns out that
they didn't completely fix all menu item leaks for MDI forms in v1.1. They
just finished up a new hotfix 7/23/04 to fix the remaining menu leaks for
MDI forms. I believe they're still testing it and completing the
knowledgebase article before releasing it.

-Rich
"Andy Becker" <x@x.com> wrote in message
news:uX**************@TK2MSFTNGP10.phx.gbl...
"Rich B." <ri******@hotmail.com> wrote in message
news:ug**************@TK2MSFTNGP12.phx.gbl...
I have seen http://support.microsoft.com/default...b;en-us;817723 which appears to be either the same or a closely related issue, but
Microsoft says that this bug was fixed in v1.1 of the .NET Framework

(which
is what I'm using).


That particular link doesn't mention it as fixed in 1.1. Did you learn of
this another way?

Best Regards,

Andy

Nov 20 '05 #9

P: n/a
Rich,

Thanks for sharing this information with us?
(And now this is in the Google newsgroup search as well).

Cor
The first thing we did was contact Microsoft to see if the fix from 817723
was incorporated into Framework v1.1. They said it was, so that hotfix
wasn't necessary if you're using v1.1.

I opened a case with Microsoft and they solved it for us. It turns out that they didn't completely fix all menu item leaks for MDI forms in v1.1. They just finished up a new hotfix 7/23/04 to fix the remaining menu leaks for
MDI forms. I believe they're still testing it and completing the
knowledgebase article before releasing it.

-Rich

Nov 20 '05 #10

P: n/a
Cor,
I tested the latest hotfix and it is still necessary to Dispose the main
menu in the MDI and each child form or menu items and other objects still
remain after destroying all forms. It looks like you don't have to Dispose
the menu items - just the MainMenus. They are not garbage collected because
a hashtable in the framework still has a strong reference to them. If you
refer back to
http://support.microsoft.com/default...b;en-us;817723 , Microsoft
explains the reason for this is (and it is still true with their new 7/23/04
hotfix) and gives the code to add to the Dispose:

"Because absolute ownership of menus cannot be determined in Microsoft
Visual Studio .NET, this hotfix will not address certain scenarios that are
resolved by the addition of this code. For example, menus may be shared
between forms. Therefore, the form does not dispose of the menu
automatically. This disposal code is necessary for any subforms. The same
applies for any top-level forms that close without exiting the application.
"

I've read that there are other controls like the MainMenu that aren't part
of the components container that also have to be manually Disposed or they
hang around after the form is destroyed. They live outside of the form that
you think they live on, so they aren't Disposed with the form.

-Rich

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:O$**************@TK2MSFTNGP10.phx.gbl...
Hi Rich,

Normally there should not be any reason to dispose a mnu item, because the
form inplements idisposable, every thing should be handled by the framework.
I never have seen this problem in this newsgroup (what says nothing maybe
however doing a search in google on this did as well give not any problem)

I know it is no answer, just an opinion, to help you going on in searching
for the problem.

Cor
I have an MDI form with a single child form. I have found a couple of
circumstances that appear to cause the framework to leak Int32s, MenuItems,
MenuItemCollections and sometimes TRACKMOUSEEVENTs. This happens if I
disable/enable a menuitem, add a new menuitem programatically or click on an
entry in the mdiList menu. I am disposing the main menu in the child

form as well as in the main mdi form, so that's not the issue.

I have seen http://support.microsoft.com/default...b;en-us;817723 which appears to be either the same or a closely related issue, but
Microsoft says that this bug was fixed in v1.1 of the .NET Framework

(which
is what I'm using).

Using the .NET Memory Profiler from SciTech it appears that these leaked
objects are being held in the allCreatedMenuItems hashtable in MenuItem.

I
can hack around this problem by using reflection to access and clear that hashtable in the MDI Dispose, but my company isn't comfortable with this
solution. They would prefer either a Microsoft based or recommended
solution.

Is this a know bug in the framework and is there a hotfix for it that

anyone
knows of? Any suggestions?

Thanks,
Rich


Nov 20 '05 #11

P: n/a
Cor,
I tested the latest hotfix and it is still necessary to Dispose the main
menu in the MDI and each child form or menu items and other objects still
remain after destroying all forms. It looks like you don't have to Dispose
the menu items - just the MainMenus. They are not garbage collected because
a hashtable in the framework still has a strong reference to them. If you
refer back to
http://support.microsoft.com/default...b;en-us;817723 , Microsoft
explains the reason for this is (and it is still true with their new 7/23/04
hotfix) and gives the code to add to the Dispose:

"Because absolute ownership of menus cannot be determined in Microsoft
Visual Studio .NET, this hotfix will not address certain scenarios that are
resolved by the addition of this code. For example, menus may be shared
between forms. Therefore, the form does not dispose of the menu
automatically. This disposal code is necessary for any subforms. The same
applies for any top-level forms that close without exiting the application.
"

I've read that there are other controls like the MainMenu that aren't part
of the components container that also have to be manually Disposed or they
hang around after the form is destroyed. They live outside of the form that
you think they live on, so they aren't Disposed with the form.

-Rich

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:O$**************@TK2MSFTNGP10.phx.gbl...
Hi Rich,

Normally there should not be any reason to dispose a mnu item, because the
form inplements idisposable, every thing should be handled by the framework.
I never have seen this problem in this newsgroup (what says nothing maybe
however doing a search in google on this did as well give not any problem)

I know it is no answer, just an opinion, to help you going on in searching
for the problem.

Cor
I have an MDI form with a single child form. I have found a couple of
circumstances that appear to cause the framework to leak Int32s, MenuItems,
MenuItemCollections and sometimes TRACKMOUSEEVENTs. This happens if I
disable/enable a menuitem, add a new menuitem programatically or click on an
entry in the mdiList menu. I am disposing the main menu in the child

form as well as in the main mdi form, so that's not the issue.

I have seen http://support.microsoft.com/default...b;en-us;817723 which appears to be either the same or a closely related issue, but
Microsoft says that this bug was fixed in v1.1 of the .NET Framework

(which
is what I'm using).

Using the .NET Memory Profiler from SciTech it appears that these leaked
objects are being held in the allCreatedMenuItems hashtable in MenuItem.

I
can hack around this problem by using reflection to access and clear that hashtable in the MDI Dispose, but my company isn't comfortable with this
solution. They would prefer either a Microsoft based or recommended
solution.

Is this a know bug in the framework and is there a hotfix for it that

anyone
knows of? Any suggestions?

Thanks,
Rich


Nov 20 '05 #12

P: n/a
Thanks again Rich,

This becomes an important tread for Google.

:-)

Cor
Cor,
I tested the latest hotfix and it is still necessary to Dispose the main
menu in the MDI and each child form or menu items and other objects still
remain after destroying all forms. It looks like you don't have to Dispose the menu items - just the MainMenus. They are not garbage collected because a hashtable in the framework still has a strong reference to them. If you
refer back to
http://support.microsoft.com/default...b;en-us;817723 , Microsoft
explains the reason for this is (and it is still true with their new 7/23/04 hotfix) and gives the code to add to the Dispose:

"Because absolute ownership of menus cannot be determined in Microsoft
Visual Studio .NET, this hotfix will not address certain scenarios that are resolved by the addition of this code. For example, menus may be shared
between forms. Therefore, the form does not dispose of the menu
automatically. This disposal code is necessary for any subforms. The same
applies for any top-level forms that close without exiting the application. "

I've read that there are other controls like the MainMenu that aren't part
of the components container that also have to be manually Disposed or they
hang around after the form is destroyed. They live outside of the form that you think they live on, so they aren't Disposed with the form.

-Rich

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:O$**************@TK2MSFTNGP10.phx.gbl...
Hi Rich,

Normally there should not be any reason to dispose a mnu item, because the
form inplements idisposable, every thing should be handled by the

framework.

I never have seen this problem in this newsgroup (what says nothing maybe however doing a search in google on this did as well give not any problem)
I know it is no answer, just an opinion, to help you going on in searching for the problem.

Cor
I have an MDI form with a single child form. I have found a couple of
circumstances that appear to cause the framework to leak Int32s,

MenuItems,
MenuItemCollections and sometimes TRACKMOUSEEVENTs. This happens if I
disable/enable a menuitem, add a new menuitem programatically or click on
an
entry in the mdiList menu. I am disposing the main menu in the child

form as well as in the main mdi form, so that's not the issue.

I have seen http://support.microsoft.com/default...b;en-us;817723 which appears to be either the same or a closely related issue, but
Microsoft says that this bug was fixed in v1.1 of the .NET Framework

(which
is what I'm using).

Using the .NET Memory Profiler from SciTech it appears that these leaked objects are being held in the allCreatedMenuItems hashtable in MenuItem. I
can hack around this problem by using reflection to access and clear that hashtable in the MDI Dispose, but my company isn't comfortable with

this solution. They would prefer either a Microsoft based or recommended
solution.

Is this a know bug in the framework and is there a hotfix for it that

anyone
knows of? Any suggestions?

Thanks,
Rich



Nov 20 '05 #13

P: n/a
Thanks again Rich,

This becomes an important tread for Google.

:-)

Cor
Cor,
I tested the latest hotfix and it is still necessary to Dispose the main
menu in the MDI and each child form or menu items and other objects still
remain after destroying all forms. It looks like you don't have to Dispose the menu items - just the MainMenus. They are not garbage collected because a hashtable in the framework still has a strong reference to them. If you
refer back to
http://support.microsoft.com/default...b;en-us;817723 , Microsoft
explains the reason for this is (and it is still true with their new 7/23/04 hotfix) and gives the code to add to the Dispose:

"Because absolute ownership of menus cannot be determined in Microsoft
Visual Studio .NET, this hotfix will not address certain scenarios that are resolved by the addition of this code. For example, menus may be shared
between forms. Therefore, the form does not dispose of the menu
automatically. This disposal code is necessary for any subforms. The same
applies for any top-level forms that close without exiting the application. "

I've read that there are other controls like the MainMenu that aren't part
of the components container that also have to be manually Disposed or they
hang around after the form is destroyed. They live outside of the form that you think they live on, so they aren't Disposed with the form.

-Rich

"Cor Ligthert" <no**********@planet.nl> wrote in message
news:O$**************@TK2MSFTNGP10.phx.gbl...
Hi Rich,

Normally there should not be any reason to dispose a mnu item, because the
form inplements idisposable, every thing should be handled by the

framework.

I never have seen this problem in this newsgroup (what says nothing maybe however doing a search in google on this did as well give not any problem)
I know it is no answer, just an opinion, to help you going on in searching for the problem.

Cor
I have an MDI form with a single child form. I have found a couple of
circumstances that appear to cause the framework to leak Int32s,

MenuItems,
MenuItemCollections and sometimes TRACKMOUSEEVENTs. This happens if I
disable/enable a menuitem, add a new menuitem programatically or click on
an
entry in the mdiList menu. I am disposing the main menu in the child

form as well as in the main mdi form, so that's not the issue.

I have seen http://support.microsoft.com/default...b;en-us;817723 which appears to be either the same or a closely related issue, but
Microsoft says that this bug was fixed in v1.1 of the .NET Framework

(which
is what I'm using).

Using the .NET Memory Profiler from SciTech it appears that these leaked objects are being held in the allCreatedMenuItems hashtable in MenuItem. I
can hack around this problem by using reflection to access and clear that hashtable in the MDI Dispose, but my company isn't comfortable with

this solution. They would prefer either a Microsoft based or recommended
solution.

Is this a know bug in the framework and is there a hotfix for it that

anyone
knows of? Any suggestions?

Thanks,
Rich



Nov 20 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.