LabWindows/CVI locks up under Windows XP when a menu item is selected in my application

[Ambient2002]

I am having problems where my distributed exec locks-up under Windows XP any time a menu item is selected.

[Chris Matthews]

We have seen this a few times due to some changes made in CVI 6.0 to conform to the latest Windows style menus. Usually, it is due to the program relying on GetUserEvent instead of regular event processing. Is this what your program is using?

Best Regards,

Chris Matthews
National Instruments

[Ambient2002]

Yes indeed. It is a common problem with XP. The menu freezes when selected and the program must be rebooted. I have only seen it with XP, and updating the video drivers to the latest and greatest does not help.
Example menu call:

void Config_menu(int Menubar, int MenuItem, void *callbackData, int Panel)
{
//Some stuff done here
}

[Chris Morison]

I am also experiencing this problem, but only on one of 3 almost identical WinXP laptops.

Any menu or menu ring (including right-click on a table) will cause the freeze, using either GetUserEvent or regualr event processing.

Even the demo project menus.prj causes the problem.

I've tried changing all menu effects, hardware graphics acceleration and removing the virus scanner, all to no avail.

Cheers,

Chris Morison

[Chris Morison]

Hang on, I think I've fixed it!

I ran msconfig.exe and did a diagnostic startup, after which the menu's worked fine. Then I enabled each part of the selective startup and rebooted until they froze again: Load System Services was the culprit. I then enabled half of the services in a binary search sequence until I found the offending service: Plug and Play service.

This service can be removed from startup and/or started manually from the Services panel (Start->Run->services.msc). Boot up without it and my menus will work fine. Enabling it manually and the menus will still work. They will only not work if the Plug and Play service is enabled during boot-up.

Quite why this service is causing problems on this machine is a mystery. It's r
unning on the other two XP laptops which have no problems.

Chris.

[Ambient2002]

Chris,

You wrote:

...ran msconfig.exe and did a diagnostic startup, after which the menu's worked fine....

I had a customer do this and this locked up his computer solid, he had to login to safe mode to correct this issue.

LabWindows/CVI is the only application that causes this menu lock-up. I have about 20 customers with the same problem. I am using the latest version of LabWindows/CVI.

[Erwin Timmerman]

There's more trouble with CVI and XP.

I have trouble with using the windows SDK multi threading functions (CreateThread() etc) in XP with CVI 6. The programs will crash unexpectedly, hang waiting for threads to finish which are already finished etc. The exact same programs run absolutely fine on the exact same computer (dual boot) on W2K.

I have posted this incompatibility with a test program earlier:
http://forums.ni.com/ni/board/message?board.id=180&message.id=10956#M10956
The problem hasn't been solved yet, to my knowledge at least, and the fact there are more problems with CVI/XP might suggest these are all related. Which in my case would be a good thing, as NI points to MS as their SDK not working correctly (the NI thread pool didn't cause a crash). When more problems arise with CVI/XP the need to solve things will become greater because slowly but surely CVI is moving into a position where it cannot be used anymore as a serious compiler for computers running XP. Be it MS or NI who caused the incompatibility, it needs to be fixed eventually...

Maybe your solution will work for the threading problem as well (I'll certainly try it), but it remains a work around for both problems, and a pretty tough one at that. Of course it isn't an option to ask all your clients to perform this action to be able to run your program. For a single program in a single lab on a computer you administer yourself it might work, but *clients* will look for a more professional programmer pretty soon when you tell them your program only works when there's some serious hacking done first.

Your find might be a good starting point for NI to find the source of the problem though. Good work!

Erwin Timmerman