Crash with old software made with LabWindows 6.0

[Franck_Dub]

Hello,
We have ported an application made ​​in 2004 with LabWindows / CVI 6.0 and running on a PC under Windows 2000 on a PC more recent with Windows XP SP3.
The unmodified application is blocked several times (frozen screen on a button interface still down) with one of two microprocessors 100% occupied.
I had installed and activated LabWindows / CVI 8.5.1 on this machine XP, while the first machine Windows 2000 contains LabWindows / CVI 6.0
So I recompiled the application with LabWindows / CVI 8.5.1 and also converted the files using the UIR via text format files (TUI), and these phenomena still blocking after stimulation of interface objects.
Are this type of problem known and what to do in this case?
FYI, the application also uses a FieldPoint Module classic dating from 2004 as well, and to interface with Windows XP I installed the CD Field Point Explorer 6.0.1
It says no error message related to the module inputs / outputs and read digital inputs and correct encoder, for example.
Thank you to tell me one way forward, because even in debug mode the application crashes, and when I did a "break execution" I find myself always on call "RunUserInterface ()".
I don't know how to understand the problem in the Windows XP environment.
Obviously we have produced with other software LabWindows / CVI 8.5.1 and running Windows XP SP3 with no worries.
Thank you in advance for your ideas and tips.
Franck Dubreuil

[D_Biel]

Hi Franck,

It is hard to say whether this is related to a known issue or not at this point. I wouldn't say upgrade issues such as this are common, but they do happen from time to time. We will need to get some more details about the problem. Below are some suggested troubleshooting steps:

• Try to characterize when this occurs. Is it sporadically? When using certain controls?
• Does it ever return to normal after freezing up, or do you have to terminate execution?
• If it occurs in certain callbacks, try placing breakpoints there to trace the code back to the RunUserInterface function and look for anything that may be causing issues (like creating a thread).
• Try to reduce the application to as small as possible so that most of the variables are eliminated from the problem. Once you have that, you can more easily test it or post it here for us to test on our systems. Also, sometimes in the process of reducing the code you can discover what the problem is. 
• Log info to a file. In each of your callbacks, you can log messages at the beginning and end of the function and then you can determine where the hang might be occuring.
• Take a look at the SetSleepPolicy function. If your program is setting this to Do not sleep or Sleep Some, it may cause your processor to jump to 100%. Maybe the effect of this is different enough in Windows XP compared to 2000.
• Is the application hanging or crashing? If it is crashing, is there any error information or a location?

[Franck_Dub]

First thanks for your help !

- It is not sporadically, I can freeze the software after 1 or 2 minutes, but on the other hand it can happen on different buttons, maybe it is just a question of time,

- It does not come back after freezing up, it seems that the software is always hanging, no crash with Windows message, I must always terminate the software,

- I will try to set different value for the SetSleepPolicy, that's an interesting idea,

- Reducing the software is quite complicate and long, also with messages in the Callback, anyway it will be perhaps necessary ...

- I'm searching for the FP Explorer we installed in 2004 with the head FP 1601, currently with the new XP machine I have installed a more recent version V6.0.1,

So I will do some tests today around those ideas, and try to find the FP Explorer version we have installed at the beginning,

Best regards,

Franck

[Romain_Duval]

Hi Franck,

Did u finally resolve your issue?

I found one of our old support (2005) the problematic was kind of similar to yours:

"In my application, I click on the command button and when I release it, it does not pop back up again. My application uses a timer callback to do some time consuming operation. To make sure the UI stays responsive, I have a loop with ProcessSystemEvents() to make sure I process all the messages as they come. The toggle button does not have this problem. Why is ProcessSystemEvents() not handling all the messages?"

The answer was:

"This behavior occurs because of the way the LabWindow/CVI UI library is designed. First, some information about the command button. When the user clicks on a command button, CVI starts up an internal tracking loop. The sole purpose of this tracking loop is to detect mouse up and mouse move events so that the command button can be updated. The tracking loop is itself a nested loop inside the main CVI event loop. This information is true for other components that have their own tracking loops, like menus.

If during this tracking loop a callback (such as timer tick is sent to the user) occurs, the tracking loop remains active but inoperable while the thread is in this callback, even if a mouse up happens in the meanwhile, and even if the callback is calling ProcessSystemEvents. As a matter of fact, ProcessSystemEvents has a far more restricted behavior when called from inside a tracking loop. For example, messages are not dispatched to their windows, so that events are not "lost" as far as the waiting tracking loop is concerned (this way, those events are merely queued up and delayed until the thread returns to the tracking loop).

What might be happening is that you might have received a callback that was handled by the command button tracking loop and the callback has not returned. Since ProcessSystemEvents() has restricted behavior when called from inside the tracking loop, messages are not dispatched to their windows, and the UI might look like it's hung. The tracking loop cannot end unless it receives the mouse up event for the button and it cannot process any mouse click messages because the callback has not returned. The messages finally start getting dispatched when the callback returns and the mouse up event for the command button is finally processed.

To avoid such issues, ensure that you minimize the amount of time spent in callbacks, especially in the UI thread. For time-consuming tasks, prefer spawning additional threads rather than using ProcessSystemEvents() in a loop to handle dispatching messages. You could use the asynchronous timer instead of the UI timer if you need callbacks to occur at specific intervals."

Hope this can help.

[Franck_Dub]

Thanks for your search,

It may be the explanation of our behaviour, it really looks like, but also have another idea.

Yesterday I found up which version of FP Explorer we had installed on the old system (v3.0.1) and also LabWindows/CVI 6.0 !!

So I tried to uninstall both FP Explorer 6.0.1 and LabWindows/CVI 8.5.1 and install FP Eplorer 3.0.1 and LabWindows/CVI 6.0

Our software works now fine with Windows XP SP3 with these old versions.

So our feeling turns around compatibility issue between old and recent version of LabWindows/CVI and FP Eplorer.

It may also be the way the software was written with the "RunUserInterface()" call, but I think we will stop searching for now.

When I uninstalled LabWindows/CVI 8.5.1 and installed 6.0, I did not see first but some DLL from LabWindows 8.5.1 stayed in

Windows\System32 (cvirt.dll, cvirte.dll, ...) and the software was still crashing with the old FP Explorer 3.0.1

After removing all these CVI DLL and replacing them with LabWindows 6.0 DLL, the crash desappeared !!

Our goal was just to change hardware and OS Windows with same software, without any modification till 2008, so I would say

it is OK this way, and we always can install an old LabWindows 6.0 in a XP PC if we want to modify this software.

Your opinion about this bad compatibility behaviour ?

Best reagrds,

Franck