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

[LongTom]

Thanks Rob; I tried this but it didn't solve my problem. Dependency walker showed I needed to copy 24 .dlls (21 were API-MS-WIN-CORE-xxxxx-L1-1-0.DLL where xxxxx varies, msvcrt.dlll, kernelbase.dll and ntdll.dll) from my Win 7 system32 into the XP PC's .exe folder, which seems a bit excessive. However, I tried it, but the boot still failed to build the front panel as explained earlier. The Win 7 msvcrt does export the correct function name, so the problem has moved on, but not got as far as a fix.

Looking at the XP .exe folder with dependency walker showed the problem lay with kernelbase.dll using the wrong (older) version of ntdll.dll, i.e. not the one I'd installed in the .exe folder. Maybe it was using a version already in memory, I don't know, and I can't figure out how to make it use the version in the folder rather than the older one. If there's a way of doing this, please let me know.

Regards

Tom Russell

[Rob_Calhoun]

Sorry, I did not mean to imply that you should move files from Vista to XP. It is not a good idea to move system files from Vista to XP. The various C runtime files have "official" ways of being installed and it is important that they be followed. Generally this is with a merge module.

Is this "just" a LabView EXE? (i.e. no external DLLs...for some reason I though this was all about an external dll.) Are you having LabView build an installer? The LV installer will install the LVRT plus any dependencies that the LVRT itself needs to run. 

[LongTom]

Yes, this is a LabVIEW project that is compiled as an exe using the LabVIEW application builder which is also used to create the installer.

I've been using Windows 7 for a while (after upgrading from Vista!) and this is the first time I've had a problem building this app. The app's been in use for about a year and has installed on several PCs (XP based) in the UK and Europe, and I've also recompiled it using my Win 7 PC.

In April I upgraded my LabVIEW (2009 Professional Development System) to SP1, and just recently had to make a small change to the initialisation of the app which required a new compilation and installer build. That's where the problem began. I wonder if installing SP1 has caused this problem, 'cos that's what it looks like. The app runs ok on a Win 7 PC but not on the two XP I tried.

In the project installer spec I've selected NT2000 as the oldest o/s to support, but this doesn't seem to have worked. I can see _ftol2_sse exported in the Win 7 version of msvcrt.dll but not in the XP version. I don't purposely generate any dlls, just leave it to the compiler to sort out what it needs from the o/s.

Regards

Tom Russell

[LongTom]

An update on yesterday's message: I copied the LabVIEW project to an XP based PC, rebuilt the exe and installer, and it now runs ok on the XP based PCs it failed on last time.

This means that I can release the  software to our customers, but it's a big pain to have to do it in this roundabout way. I think NI needs to look at their application builder because it does seem to have a problem.

Tom Russell

[civilzhang]

Solution to the problem is to compile the app. in "Release Mode".

Details can be obtained here:

http://www.blackwasp.co.uk/DebugRelease.aspx

[rolfk]

---

LongTom wrote:

An update on yesterday's message: I copied the LabVIEW project to an XP based PC, rebuilt the exe and installer, and it now runs ok on the XP based PCs it failed on last time.

This means that I can release the  software to our customers, but it's a big pain to have to do it in this roundabout way. I think NI needs to look at their application builder because it does seem to have a problem.

Tom Russell

---

I think you mentioned in one of the earlier messages that LabVIEW complained about not being able to find some VIs when it loaded the app. The name of these VIs might be rather useful in debugging this issue further. Somehow these VIs make use of external code that tries to link to the wrong functions (or undocumented functions).

kernelbase.dll is certainly not an XP DLL. ntdll.dll is just about the lowest level DLL in Windows XP before it goes into the undiscovered depths of windows kernel system calls. And of course NEVER copy system DLLs from one system to another even if it is seemingly the same Windows version. That can really cause troubles.

 

---

Solution to the problem is to compile the app. in "Release Mode".

Details can be obtained here:

http://www.blackwasp.co.uk/DebugRelease.aspx

---

While this might be a problem for a possible external DLL called from LabVIEW this couldn't be an issue with LabVIEW itself. LabVIEW releases are always compiled as release version and the debuggedness of VIs you use in your LabVIEW app has no influence on if they will link to debug or release system libraries.

---

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.

---

Microsoft has made a real mess of the Visual C runtime libraries. They started out with a mess, giving each Visual C version a new runtime version, breaking backwards compatiblity every time, to remedy this all around Visual C 6.0 when they made it so that msvcr.dll was the actual entry point DLL that linked to whatever runtime version was required for a specific API (of course you still had to make sure to install the actual version that your app was using by installing the redistributibles that come with Visual C) and consequently broke it afterwards again.

For instance if you use a DLL compiled in Visual C version X in an application compiled in Visual C version Y you better make sure that you do not pass C runtime objects (file descriptors, etc) from one version to the other, since that will in the best case simply fail with  errors and in the worst case access objects that are completely different from what you think you access.