LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

GPF when displaying and discarding panels on a fast computer running XP

CVI 6.0
Windows XP prof
Celeron 2 GHz (or something like that)

I've developed an application on an Athlon 800 MHz in W2k. The application runs fine there.

However, when transferring the application to the above mentioned computer (which is the computer the application should be run on) I noticed GPF's popping up at very peculiar places.

First I noticed the place where the GPF turns up is a

Messagepanel = LoadPanel....
DisplayPanel(MessagePanel);
function();
DiscardPanel(MessagePanel);

It happened when the panel was loaded and then immediately discarded. (It was a "please wait" panel, however, sometimes the wait time of function() is zero and the function calls the DiscardPanel and returns immediately). Checking whether MessagePanel was >0 before discarding it didn't help either.

I suspect the panel is discarded before it is displayed by the system... ?!

This suspicion is strenthened by the following code.
The application handles batch measurements. Since the entering of parameters for these measurements can be quite boring, I did my best to automate it as much as possible. This means the user can press "enter" all the time until the batch measurement overview pops up.
The below routine has 3 buttons. "OK", "Cancel" and the default selected button "Huh?" This Huh button is to make sure that the user can keep on pressing "enter" without automatically selecting "OK" or "Cancel". As long as "huh" is selected the message pops up again.

do Status = GenericMessagePopup ("Confirm Batch Measurement",
DisplayMessage, "OK", "Cancel", "Huh?", 0, 0, 0, VAL_GENERIC_POPUP_BTN3, VAL_GENERIC_POPUP_NO_CTRL, VAL_GENERIC_POPUP_BTN2);
while (Status == VAL_GENERIC_POPUP_BTN3);

However, when keeping the "enter" button pressed during this loop (which means the message pops up continuously at very high speed) the GPF happens too at some point, and not always the same point... sometimes it takes 3 seconds of flashing popups before the GPF happens, sometimes 20 seconds.

It happens in debug mode and in release mode, but on the W2k developing system everything works fine.

Is this a bug in CVI, or XP, or both?
0 Kudos
Message 1 of 5
(3,706 Views)
When writing the attached test program to recreate the fault outside of the large application it was occurring in, I found out that the GPF only happens when the display/discard combination is done *within a seperate thread*.

The test program works like this:
Left click "start" and a panel with "hi there" on it wil start flashing until you press the SHIFT-key. No problem there.

Then, *right-click* the start key, and the same will happen, but this time the flashing routine is done within a function that is called with CreateThread(). On my fast XP system a GPF within seconds, on my slower w2k machine no problem at all (except the fact that the createthread() option flashes a *lot* slower than the non-threaded version).

I hope this helps to recreate the
problem somewhere else as well.

Greetings,

Erwin Timmerman
0 Kudos
Message 2 of 5
(3,706 Views)
Actually attaching the zip file would help.... 🙂
0 Kudos
Message 3 of 5
(3,706 Views)
Dear Mr. Timmerman,

I have investigated your problem. I was able to reproduce the error messages you described on a 2.66 GHz Windows XP machine. On a 800 MHz Windows XP machine it worked fine though so it seems not to be related to XP but to the speed of the procesor where the program is running on. I am in close contact with our R&D department to try and find out what is happening here and what we can do about it. I want to thank you for this submition and the test program which helps a lot to find a solution. I will keep you updated through out this forum thread.

Best regards,

RikP
Application Engineering
National Instruments
Rik Prins, CLA, CLED
Software Development Engineer
0 Kudos
Message 4 of 5
(3,706 Views)
New facts:

I've installed W2k on the exact same computer where the problem occurred with XP. Running the crash-program on this OS DOESN'T GENERATE A CRASH!

So whatever the problem is, it is also related to XP, or at least the Windows installation settings (because the exact installation settings or used drivers probably differs between the XP and 2000 install).
The crash combination is:
XP, CVI 6.0 with its Windows SDK.

I don't expect a solution, but it is good to know the problem exists, maybe put it in a knowledge base or something, that CreateThread isn't functioning reliable with CVI and XP in some circumstances. More users will encounter this in the future I think if they are not warned. Had I known this then I would h
ave used the CVI thread pool in the first place, now I can go and rewrite the whole thing.
0 Kudos
Message 5 of 5
(3,706 Views)