Executable freezes with/near Open VI Reference and Start Asynchronous Call

[Ray.R]

I developed code that works fine in development.  I created an executable and the application freezes when attempting to spawn a dynamically called re-entrant VI.

It "appears" to freeze in the vi shown below..  I say appear because I inserted a bunch of debug string captures and it seems that this is where the issue occurs.  THe debug captures each and every step, so the most common location of the freeze is when Open VI Reference is called.  However, there are instances when the freeze occurs elsewhere.

There is a single re-entrant VI which is obviously called measurementDaemon.vi.  It is used to read values from cDAQ modules.  A similar approach with similar cDAQ chassis / modules worked fine.

The reentrancy was initially set as Preallocated, but since this weird bug, I am now trying Shared clone.  Both settings work fine in the development code, using the exact same steps to where the code calls the measurementDaemon.vi.  

Since I no longer have access to the customer's cDAQ chassis, simulated devices were created in NI MAX.  Again, this works fine in the development code. 

When the code freezes, it does not reach measurementDaemon.vi.  The trace shows that it passes the appropriate path & filename to the Open VI Reference.  As a matter of fact, it can open 2 or 3 or 4 clones before the freeze.  Yes... it opens the very same re-entrant VI a few times before freezing.  The calling VI uses a for loop indexed by the number of cDAQ modules that are in the chassis.  The same information as the development code is used with the executable.  Up to this point, the code is fine.  

There are no errors caught by the debug data.  Nothing to point to some sort of issue.  The executable just takes a nap...  I meant a NOP... (trying some humor).

The simulated module which seems to be most affected by the issue is the NI 9214.  

The measurementDaemon.vi simply reads values using DAQmx functions and sends the data using a queue (with index) to a results process VI.  The executable does not get that far, but this is a common code which has worked fine, and works fine with the development code.

Any ideas on what could be causing issues?

[Ray.R]

Development is done on a windoze machine, so yes... it was rebooted...

[TomOrr0W]

I doubt it will have an effect on your issue, but you could use 0x80 instead of 0xC0 for the Option flags.  C0 would only be useful if you are opening all the measurementDaemon clones with the same reference - It creates many unnecessary clones of the vi otherwise.

[Ray.R · Accepted solution]

Thanks Tom for the information.

I created a virtual machine and installed the application.  It runs fine.  So I have an unexplained mystery...  I will investigate further, but I am glad that it is running fine.  

[LucianM]

Could it be that the daemon VIs are using the UI thread/root loop to such extent that the Open VI Reference function doesn't get the chance to execute? I would try to modify the daemon VI to do nothing (just waiting) to see if that makes a difference.

[Ray.R]

Hi Lucian,

From what I can see in the debug logs, it does reach up to the Open VI Reference.  But on some occasion, it gets past that.  So I may be looking in the wrong area...  It may just be a coincidence that it mostly freezes immediately after passing the correct path to the Open VI Reference.  

So far, it works on two virtual machines and one 1 PC at the customer site.  

It remains a mystery.