LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

32 bit LabView 2011 Executable crashes running on Windows 7 64-bit

Hi there,

 

I have encountered a problem with a 32-bit Labview 2011 executable running on a Windows 7 64-bit system. The Labview application calls a 32-bit dll function that tries to create some directories and files on the hdd. The function call works but during the generation of the directories the application just hangs. If I run the executable under the Windows XP Mode (Windows Virtual PC) everything works fine.

 

Another curious thing also is that running the vi directly from the development system on the Windows 7 64-bit system without having generated an executable works fine as well.

 

As I don't have access to a 32-bit Windows 7 PC I have not yet tested the executable on that operating system.  

 

Anyway, as the dll is the same for both setups I wonder if either the runtime engine (32-bit LVRTE2011std) or the application builder might cause this problem. Or maybe there is something wrong with my development system?

 

I have attached an very simplified test version of the application to this post.

 

Any help on this topic would be greatly appreciated. Thanks!

Lars 

 

 

 

 

0 Kudos
Message 1 of 7
(3,426 Views)

....me again,

 

I have probably found the reason for the problem: it seems the semantics of the find function in the CString class has changed and the dll code that worked in the past doesn't work anymore (at least on Windows 7). 

 

This however leaves me still wondering why running the vi and the dll from the development system works??? If someone has an idea please let me know.

 

Regards

Lars 

0 Kudos
Message 2 of 7
(3,423 Views)

Hi Larsky,

 

with the modification you made, does your application now run as executable and from within the development system?

 

Best regards,

 

Benjamin

0 Kudos
Message 3 of 7
(3,377 Views)

Hi benni_,

 

with the modification to the find function call the vi runs as executable as well as from within the development system. I have taken some very wild guesses that maybe the development system wrapps some funtion calls differently to the runtime engine, but I am way out of my knowledge concerning this topic. Therefore everything I can contribute is only wild speculation. I still hope that some of the experts have an idea why the executable behaves different to the vi though both call the same dll function.

 

Regards

Lars

 

0 Kudos
Message 4 of 7
(3,371 Views)

Hi Larsky,

 

1) Could you clarify in which way the executable behaves differently as opposed to the VI? From your preceding post it sounds like everything is working as you expect it to work (function call works in development system and as executable).

 

2) To have a look at your VIs it is furthermore necessary that you provide cifX32DLL.dll since it is necessary for the function call.

 

Best regards,

 

Benjamin

 

0 Kudos
Message 5 of 7
(3,352 Views)

Hello Banjamin,

 

thank you for your response:)  

 

The test vi calls a function that initialises some underlying threads and starts up a state machine implemented in visual c++. During the initialisation the dll function tries to create an ErrorLog directory and some logfiles (within the vi / executable directory). For debug reasons I have implemented some beeps to see where exactly the function call stops. Starting the vi all seven beeps can be heard and the directory as well as the log files are created. Starting the executable only two beeps can be heard and the application just freezes. Two beeps indicate that the function is not able to generate the directory while parsing the input string for backslashes and creating the appropriate directories.

 

I have attached the missing cifX32dll.dll - sorry I missed the dependency:( - and also the executable generated with my development system.

 

Thanks for your interest in this problem and best regards

Lars 

Download All
0 Kudos
Message 6 of 7
(3,344 Views)

....just one add-on:

 

with the changes to the dll, both vi and executable now work fine...

 

Regards

Lars 

0 Kudos
Message 7 of 7
(3,341 Views)