LabVIEW 2009 crashes at startup with the presence of a certain CRT version on the system

[anotherStefan]

When installing our LabVIEW integration package on a system running LabVIEW 2009 LabVIEW will crash at startup afterwards. Using 'dependency walker' reveals, that 'nicont.dll' causes this crash because of a side-by-side configuration problem. After some debugging I found out that on this particular system installing a certain version of the Microsoft CRT will stop LabVIEW from functioning. My fix now is to recompile our code with a newer version of VS. I now ship a VS9 version of the runtime and everything is working as expected.

 
However I guess the real problem lies within the LabVIEW installer. I guess a needed version of the CRT is not installed by LabVIEW. It still works because due to some policy files on the machine it gots defaulted to a compatible version at startup. However when I install the following 2 merge modules on the target system LabVIEW does no longer work:

 
Microsoft_VC80_CRT_x86.msm (file version inside: 8.0.50727.762)

policy_8_0_Microsoft_VC80_CRT_x86.msm (file version inside: 8.0.50727.4053)

 
Renaming the *.policy file in the SxS dir on the target system gets LabVIEW back to run, but of course other SW needing this file does not run then

 
I was using XP, 32 bit SP 3

I can provide additional information if needed. Is this a known problem? Is there a fixed version of LabVIEW already?

Message Edited by anotherStefan on 02-05-2010 05:44 AM

[jtagg]

Hi Stefan,

so if I understand correctly, this only happens since LabVIEW 2009. Is this correct?

I will see if I can find any further information on this subject.

regards,

[anotherStefan]

Thanks for the answer. Well to be perfectly honest: I have no idea since which LabVIEW version this could be an issue. These things are always extremely difficult to tackle as the presence of something completely different that 'by accident' comes along with a correct version of the CRT migth bring the whole system back to life. I guess what needs to be done is to check which version of the runtime the nicont.dll or any of it dependencies has been linked with and then check if this version is installed by the LabVIEW installer in the correct way(thus in the sxs folder under %WINDOWS% e.g. by using the official M$ merge modules. Sometimes a compiler update (SP or a KB update via 'automatic update') might cause these effects as even if only a simple Windows patch is installed this sometimes comes along with a different version of the CRT merge modules in %PROGRAMS_DIR%\common files\merge modules

[jtagg]

Yes, this kind of stuff is indeed difficult to tackle.

I would like to send this information to our R&D group, but for that to be effective, could you create an installer that will reproduce the behaviour for us? It would need to be as simple as possible (without anything unneeded for the error) for us to effectively find and fix the error.

A detailed step list on how to make the error happen would be helpful in that regard.

Thanks!

regards,

[anotherStefan]

Sure! I tried to attach the installer causing the problem to this message. However I failed miserably(BAD GATEWAY from the upstream server). Where can I upload the installer to or what do I need to do?

It will install some other stuff as well (A bunch of VIs, a DLL and an OCX(this needs the CRT I have trouble with)and the CRT and MFC runtimes I mentioned. An updated version of the installer can be obtain here(however it does no longer show the issue): http://www.matrix-vision.com/functions/count.php?url=products/hardware/family/SC/mvBlueFOX/LabVIEW_a... The only difference between the two packages is, that the OCX in the attached file has been build using VS2005SP1 and in the package the link points to I did use VS2008. Apart from that I changed the 2 merge modules from Microsoft (CRT and MFC)

[jtagg]

Hi Stefan,

sorry for the delay. You can post your files to our ftp server:

ftp://ftp.ni.com/incoming

Please put all your stuff in a zipfile called 867056.zip.

I'll forward this to those concerned.

Regards,