Menu disappearing and Windows menus dying

[Glen]

I have a bug which seems to corrupt the operating system.

The application
==========
I have a VB.NET MDI application which has complex menus, including:
* A main menu with run-time items that can change during the application's lifetime
* Various different MDI child forms, that also have run-time built menus
* a MDIChild list under a "Windows" main menu item.
* a toolbar.

However, I have NO objects that inherit from the menuitem, or anything "non-standard" like this.

The problem
=========
I open the application, open a couple of MDI child forms, and then move the mouse back and forward across the menus at the top for a few minutes (this is simply a quick way to reproduce the problem - no, I am not mad!). After a short (but unpredictable) time of time, the menus disappear!
At this point, it becomes impossible to launch ANY other application in Windows (including Word, and the clock in the Icon Tray). I just get a system "Beep". I also can't access the menus and toolbars of some other applications that may be open at the same time (eg. Internet explorer!). Once I close my application everything is OK again.
If I attempt to continue using my application (via non-menu operations) things get worse - to the point where Task manager can't be opened, my application won't close, and the only solution is to turn off the computer.

Solution?
======
I have included a v. small VB.NET application (source) that emulates the menu part of my application, and exhibits the same bizzare but unpredictable characteristics.

My questions are:

* Has anybody come across the same problem? Your advice would be much appreciated.

* Can anybody see any problems with the code?

I suspect there is a bug in the Framework for this to occur, but I am hoping that it is something I have done.

Thanks for taking time to help me.

Glen.

 

[Nerseus]

I'm sorry I don't have .NET on my current machine (I'll test tomorrow), but I'll try to offer a few general items.

First, does this happen with any other applications, such running the mouse back and forth over the menus of Word, Excel, Outlook, IE, etc.? I had this happen once about 5 years ago and it turned out to be bad memory (though all memory "checker" programs reported it as Ok).

Also, do you have any other developer machines you can try this on (besides us in the forum)? Especially if it's the same type of machine (like a coworker that has the same model of computer as you).

If not that, does it do with a more standard window and menus? Have you tried a single non-MDI form with a set of menu items that stays static - essentially no code on your part. I apologize if that's what your sample is - I'm too lazy to look at the code in Notepad right now

I've never seen the problem you're describing and I do have an MDI application that has menus built dynamically at runtime and change over the course of the application. I don't use standard menus though, but a 3rd party control. I've not seen the problem you're describing though.

-Nerseus

 

[Glen]

Thanks for your interest, Nerseus.

In answer to your questions:

I haven't tried it with other applications, so I may give that a go next. What I have noticed is that it almost always crashes as I move over the "Window" menu item (which contains a MDI Child List).

Also, doing this is only the quickest way to reproduce the problem. The menus disappear sometimes when a new Child form is "loaded" - what happens is that the menu disappears, and the child doesn't load, and the app must be "end task"ed. This only occurs once or twice a day when using the application a fair amount.

This has occurred on a number of machines, in Win 2000 and Win XP Prof, on Laptops and Desktops. We don't have any other operating systems.

We have not tried it on any simplier menu programs - we would have to create one specifically for this test since we don't have any other software with menus. However, the same thing happens with our "real" software and the "test" one I have posted here.

I hope this helps - I am struggling with this one!
Thanks,
Glen.