Tips for race conditions in EXE?

[dgholstein]

I have a VI that runs well on my machine under the LV development environment.  When I compile to an EXE and install to a production machine, it randomly crashes with no real trace information available, it appears to crash in one of my DLLs, seemingly because I've already closed a TCP/IP/database connection.

Of course, putting pop-up messages is a pain and hides the actual problem.

Is there a way to identify the node identified in the crash (hex format) to the node in the block diagram?

   ...Dan

Message Edited by dgholstein on 05-17-2007 08:16 AM

[MRedRaider]

Dan:

What version of LabVIEW are you using?...LabVIEW 8 introduced debugging in executables!

Quote NI Support  "try searching the LabVIEW Help for 'debugging applications' "

[dgholstein]

Using 7.0.

   ...Dan

[DFGray]

Are your DLLs thread safe?  If not, you can either run them in the UI thread or put locks on the calls using semaphores or something similar.

What OS are you using?  If it is a Windows variant, you can try embedding calls to the Windows kernel to display debug strings.  You can view these easily with DebugView from Microsoft SysInternals.  Use the call library node to call the Windows kernel32.dll to post the strings.  Here is a LV8.2 screenshot of the setup.  We have found this technique very useful for debugging race conditions, since it does not slow down the code much.  Wrap the DLL call in a subVI and drop them around where you think the problem is.

Message Edited by DFGray on 05-18-2007 08:00 AM

[MRedRaider]

Thanks for the info, I will take a peek at it later today.

[MRedRaider]

Sorry. Please ignore my last post... wrong thread... too many forum windows open!

[dgholstein]

DFGray;

Thanks for the tip, that's a gem.

   ...Dan