LabView Vista Executable error on xp (sprintf_s in msvcrt.dll?)

[AvnerG]

Has anyone here had any success using compiled LabView executables, compiled with Vista, on XP boxes?

We currently have only one developer here with Vista. Anything he builds on his machine cannot run on *any* of the XP boxes I've tried. The program, before even showing a front panel, gives an error box. The box is titled: "<progname>: <progname>.exe - Entry Point Not Found", and the text says "The procedure entry point sprintf_s could not be located in the dynamic link library msvcrd.dll.".

I could not find any mention of this error anywhere else on this site, so could it be something strange with my co-worker's setup?? Any ideas?

Cheers,
Avner Ginsburg

[Eriquito]

Hi Avner,

I have built an EXE on Vista and run it on XP with no problems.  Do you have any other XP machines you could try it on?  Also, do you have the SP2 update installed on your XP machine?

Another thing to try is to just create a very simple program on your Vista machine (in my case, I simply had an empty while loop with a stop button) to try to isolate if there is some specific function you are using in your code that is causing this error to occur.

[Eriquito]

Message Edited by El_Eriquito on 03-31-2008 02:16 PM

[AvnerG]

Hi!

First, I doubt it's an XP issue. It happens on every XP box we try, old or new. All are SP2, of course!

Second, I finally bugged my coworker with the app builder, and he built a simple app for me (as you described), and it worked.

Sadly, that means it's something that we're using in the project. When I say sadly, it's because our project has about 600 VI's, and there's pretty much no time for us to try to narrow it down as to what we're using, that might be causing the problem. At least not without a hint or two.

Question: have all labview utilities and library tools also been checked for vista compatibility in compiled form? Does the error message itself give any clue?

Cheers,
Avner Ginsburg

[Eriquito]

Hi Avner,

The message seems to indicate that the LabVIEW executable cannot find the sprintf_s function in the MS Visual C library.  I did some research, and found that his function has to do with writing a string to a buffer.

The first question to ask is, are you calling any external code (especially .NET code) from your project?  You may want to verify that you have the .NET framework installed on your system.

I found an external site that explains how to restore the original dll from your XP CD-ROM, however if you are experiencing this problem in multiple computers, I doubt that will fix your problem.

We do test all of our products as thoroughly as possible before releasing them, however no software is ever "bug free," and it is possible that there is an issue with LabVIEW on Vista.

If we can narrow down exactly what is causing the problem, we may be able to find a workaround.  I recommend creating a debuggable executable;  that way, you can observe execution highlighting of the block diagram and see exactly where the program is crashing.

If you are able to create a simple application that reproduces the problem and post it here, I will report it to R&D so it can be fixed in a future release and do my best to find a workaround.

Of course, you could always just transfer the files to an XP machine before compiling them, if all else fails.

[AvnerG]

Well, I did not have much luck yet. I finally got my coworker with the first vista machine here, to rebuild the app with debugging on. The problem is that the error pops up before the front panel is even displayed. After clicking okay on the error, the front panel eventually comes up, but with a broken run button showing that it cannot execute.

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.

We are, of course, currently using my machine to build the app, because it is still XP, but our company is soon going to replace all of our development machines with Vista boxes (while of course NOT updating the XP boxes running our tests). So we have to solve this issue somehow.

Cheers, and thanks,
Avner Ginsburg

[Eriquito]

If the EXE built on your XP box works fine on the Vista machines, that leads me to believe there are no incompatibilities between Vista and the DLL you are calling.

So this brings us back to square one.  Can you create a simple project reproducing the error and post it here (along with whatever instrument driver files and other dependencies you are using)?  If you do, I will build the app on both our Vista and XP test machines and, if I see the same behavior, we may be able to find a workaround.

[LongTom]

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

[Rob_Calhoun]

> 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.)

[Rob_Calhoun]

Another thing to check: msvcrd.dll would be the debug version of msvcr.dll. MS doesn't want you to redistribute the debug version. Did the driver developer release a dll compiled in debug mode?