03-27-2008 01:02 PM
03-31-2008 02:07 PM
03-31-2008 02:16 PM - edited 03-31-2008 02:16 PM
03-31-2008 02:48 PM
04-01-2008 01:59 PM
04-09-2008 09:24 AM
04-10-2008 09:42 AM
05-20-2010 09:53 AM
Hi,
I've just fallen across virtually the same problem as this.
I'm running LabVIEW 2009 Platform (updated in April from the original installation) on Windows 7 (fully updated) and my compiled application won't load on XP machines either. The error message I get refers to entry point _ftol2_sse in msvcrt.dllan, just like yours, the front panel doesn't load and appears with a broken run arrow and a list of VIs it can't find. I've tried recompiling and loading on two different XP based PCs but with identical results. Therer are no errors generated in either the compile or the loader build.
The application is one I wrote last year and has been running successfully on PCs with various o/s. Yesterday I made a small change to one of the VIs, re-built the application and loader, and now I get this error. I'm wondering if the LabVIEW upgrade I installed has caused this, 'cos I can't see why the small change I made would cause it.
So, has this error been resolved or is it still a problem for you?
Regards
Tom Russell
05-20-2010 10:26 AM
> As for calling other code, we are calling a DLL from an instrument driver, but that DLL functions fine on the XP boxes.
> I'm at a bit of a loss as to what to try next.
I think this is key. Microsoft has been changing the recommended practice for installing things like the Visual C runtimes. What you are supposed to do today is ship a merge module that will install the VCRT in a SXS ("side by side") installation. (The old way was to throw it into system32, which is why system32 was just a mess.) I suspect your instrument driver can't find a version of MSVCR.dll/MSVCRT.dll that it needs.
It is still legal to drop a copy of the required runtimes in the same directory as the dll. Find out what version is require and drop a copy from the Redist folder of MS Visual Studio to the dll installation directory. (You can use Dependency Walker to see what the dll is looking for.)
05-20-2010 10:29 AM