Windows 7 Debugging Issues

[Double_D]

I have moved a CVI application from an XP machine to a Windows 7 machine.  The release executable seems to run fine.  I run into strange behavior when I run the program in the debugger, however.  This is a multithreaded application and I saw none of these problems on the XP box.  One of the first tasks of the program is to display a login panel for the user.  This panel is created and displayed exactly one time in the code.  When I use the debugger, however, I get two separate panels displayed at different times.  A similar thing happens with the Standard I/O window.  If a communication error occurs when attempting to open a communication link to a piece of hardware, for example, a message is written to this window (I also have to restore this window from the minimized taskbar version manually to see it, which is another new feature).  I put breakpoints on the lines in the code where the login panel was created and displayed and where the comm error message was written and noticed that the panel and error message were displayed prior to the breakpoint being reached.  I then selected the "break on first statement" option in the debugger to see what happened.  As soon as I run the code, the panel and I/O window appear.  If I continue in the debugger, the "real" login panel is eventually displayed.  At this point, I have not been able to successfully run this program in the debugger, even though the program hasn't changed since it ran fine on the XP box.  I'm running Windows 7 32-bit and CVI 9.0. 

[Perry_S]

Hi Double_D,

What type of processors do you have on the two machines? Could you post a simple example that recreates your issue? That would help me trouble shoot it better. Thanks.

Regards,

Perry S.

[Double_D]

The processor is an Intel Core2 Quad Q9400.  I will try to create a small program to duplicate the error, but I'm not sure if that will be successful.  The existing program is a few thousand lines of code, so I might not be able to duplicate the exact circumstances which cause the issue to occur in a very small subset of that code. 

[Double_D]

I haven't been able to get a small program to behave in the same manner as the existing program does.  After trying various tweaks to the code, I no longer have the situation where the code runs independent of the debugger.  The problem I am currently having is, hopefully, a little more straightforward.  I have attached a file containing the main program and a few of the functions that are most relevant to the problem.  The program schedules three separate functions to run in the thread pool, in addition to main.  One of these functions, gui_interface, calls the function gui_cb_first_pannel to load and/or display various panels.  The login panel should be displayed after this function runs, but it is not.  I stepped through the code and the LoadPanel function ran with no errors.  Remember that this program ran fine under Windows XP, but has never run successfully under Windows 7.  Any thoughts as to what may be causing this problem?  Would it be worthwhile to reinstall CVI, as I have seen all sorts of weird problems.  Thanks.

[Perry_S]

Hi Double_D,

If I understand correctly, your issue is that your .uir file is not loading correctly or does it not load at all? Also could you narrow down your code to where you are just calling your login uir file and see if it can be called. Here is a tutorial that I found that discuss how to use CVI to have multithreaded applications. Please take a look at it and make sure that you are following it correctly. Here is a another tutorial that should help you debug your multithreaded program.

Regards,

Perry S.

[carlox]

Double_D, what kind of processor runs the XP box ?

[Double_D]

Carlo,  the XP box was an older Dell with a single-core Pentium 4.  

Perry, the .uir file loads with no errors reported by the program.  It is not displayed, however.  I'll take a look at the paper on multicore debugging.  Have there been issues with CVI on multicore processors?

[carlox]

That's what I suspected.

No, there are not issues (AFAIK) with CVI on multicore processors, but there is subtle global issue with multicore / multithreaded that programmers often overlook.

On single-threaded processors, there is no real concurrency between threads.

Threads are executed sequentially by scheduler, and when one runs, others are stopped..

This behaviour can mask some design flaws, with poor (or missing!) protection for concurrent access to variables, resources and so on.

Please note that the assuption that the program "works" on the XP machine does not mean that the program has not problems.

It still has, and sometime it will show, may be in a minor and unnoticed way.

If you have some random glitches... here is (one of) the causes!

On multithreaded or multicore CPUs the concurrency is real, and the problems show up real soon.

As a collateral effect, any assumption on execution order of threads is wrong.

[Double_D]

It sounds like this might be the issue.  I do see strange and inconsistent behavior.  It appears that threads quit responding.  Sometimes it is the comm thread, other times it is the gui thread.  One thing I was wondering about was the way the code uses RunUserInterface.  This function is called in a couple of different threads.  Is this standard practice or could this cause problems with a multithreaded app on a multcore machine?

If this is indeed the issue, do you have any suggestions on tracking down the problem(s)?  This program has several thousand lines of code.  The app note on debugging multicore applications was targeted for real-time systems.  Is it possible to even use the Real-Time Execution Trace Toolkit on a non-RT application?

[carlox]

You're right: the inconsistent behavior is a typical symptom of erratic concurrent threads.

To be sincere, I have never seen code with more of a single RunUserInterface. It's surely not a standard practice, or at least, a common one.

Having no experience of problems due to this architecture.

The only suggestion that can be given is to carefully analyze the problem, identifying all the assumptions done about temporal sequence of events. Events may come in totally unrelated order.

It can be a nightmare, but it's the only way.

As far as I know and according to the product fact sheet http://www.ni.com/pdf/products/us/lv_execution_trace_toolkit.pdf the Real-Time Execution Trace Toolkit is for RT systems only.

Anyway, as a last resort (and for experimenting a bit) you could be able to force your process to use a single processor (cores should appear as separate processors to operating system).

Look for SetThreadIdealProcessor or SetProcessAffinityMask() in the CVI help (these are Win32 API functions). I never did it, so I cannot help. 

If you restrict the process to use a single core, the dramatic problems should magically disappear.

In all the previous discussion I assume that the problems you experienced are not related to timing issues.

The quad core system is surely significantly faster than the older PC, then all the software related timings should be checked.