Upgrade to Labwindows 9.1.1 (sp1) on a windows 2000 machine causes issues with msvcr90.dll and the NI Test and Measurement Suite

[Test_Engxx]

We have a site license for LabWindows, and just started upgrading PC's from 9.1 to 9.1.1

This appeared to work on several machines, but issues quickly became apparent.

XP machines appear to have no issues, but the 2 Windows 2000 machines both exhibit the same problems.

(Windows 2000 SP4)

Symptoms:

1)  Test applications run from an exe file before the upgrade now produce an error message when run.

The error message is 'The Dynamic Link Library MSVCR90.DLL could not be found in...'  The same error

appears when the application is run from the development environment.  I am 'fairly' certain the exe files

were built with the CVI 9.1.0 version.

2)  The NI Measurement & Automation Explorer now produces an error when you run it and select Devices and Interfaces.

The error message is 'There was a problem connecting to the database'.  Resman will not find any of the VXI equipment

in the test station.

Things tried:

1)  It appears that the .dll required was installed, but not put in the system32 directory.  I found a post at

this site that appears to explain http://support.microsoft.com/kb/326922  I copied the dll's to the folder with

the test executable, and was able to get past the error.  Is this the 'suggested' work around for windows 2000?

2)  I tried uninstalling 9.1.1 and reinstalling 9.1.0 but did not get rid of either issue above.  Is there something

in the registry that needs tweeked?  Other suggestions to get 9.1.0 to work?  (Test station is down.... )

3)  I think I have seen the MAX issue before, but I don't recall the fix.  I think it has version 4.3 of MAX installed.

Questions:

1)  Has anyone else seen this with LabWindows 9.1.1?

2)  Do I need all of the VC90 .dll files in the WinXsX folders on the PC to be copied to the exe directory?

There are several different folders. 

3)  Am I just going to uncover more problems when/if I get past these?  It appears

the service pack must have updated a lot of behind the scenes stuff as well as just

LabWindows.  Any chance of a release from NI which would fix these issues

on Windows 2000? (SP1 Patch?)

Any Suggestions?

[Wolfgang]

Hi,

the NI Web site claims that CVI2009SP1 is not compatible with Windows 2000:

supported operating systems: Windows 7; Windows Server 2003 R2 (32-bit); Windows XP x86; Windows Vista; Windows Server 2008 R2 (64-bit)

[Test_Engxx]

I will check the website, but the documentation that came with SP1 suggests it is compatible.

The Readme.htm and the ReleaseNotes.pdf included with the service pack state the following:

Minimum System Requirements

To run LabWindows/CVI 2009 SP1, you must have the following items:

• Personal computer using a Pentium 1GHz or higher microprocessor
• Microsoft operating systems:
  • Windows 7 (32-bit and 64-bit)
  • Windows Vista (32-bit and 64-bit)
  • Windows XP (32-bit)
  • Windows 2000 Service Pack 3 or later
  Note  LabWindows/CVI 2009 is the last major release to support Windows 2000.
• 1024 × 768 resolution (or higher) video adapter
• Minimum of 128 MB of RAM, 512 MB recommended
• 1.1 GB free hard disk space for full installation, which includes the Interface to Win32 Application Programmatic Interface
  
  Note  Installing the Documentation from MSDN Library requires additional disk space.
• Microsoft-compatible mouse

We have Windows 2000 SP4 installed.

[Test_Engxx]

I started digging into the MAX database issue.  Here is what I have found.

http://digital.ni.com/public.nsf/allkb/B9107A7F281F9B408625720B0078E5A8

This had several suggestions, and I have tried some of them. 

Firewall settings should't apply since it was working before the SP1 upgrade.

The NI Configuration Manager Service is not starting.

I attempted the repair action from add/remove programs.  It appeared to be succesfull, I.E. no errors during the repair.  It did not solve the issue.

The service will not start, even when done manually from the services menu.  (Attached screen capture)  I am not sure if I should attempt the

procedure for repairing a corrupt database or not.  I am still having trouble with how SP1 could have broken MAX.   

The document lists a rare PCI-7041 driver combination, but I don't see how the service pack would have touched any of the things listed.

I am stumped.

[Raj_V]

Have you had a chance to try this out?

http://digital.ni.com/public.nsf/allkb/0819391CA91B3EB38625731D00024649?OpenDocument

[Test_Engxx]

I tried to follow the instructions in the document you mentioned.  One of the first steps was to navigate to nidevldu in the services, and to start that service if it was not running already.  It was not running, and I tried to start the service.  I received the following error message:

Windows could not start the nidevldu on the local computer.  For more information, review the event log.  If this is a non-microsoft service, contact the service vendor, and refer to service-specific error code -1.

[Michael_W.]

Hello,

Are you an administrator on the machine?  It is possible you are being blocked from starting the service if you aren't an admin.

[Test_Engxx]

I am logging into the local machine as admin, and then logging into our network as myself.  This is sufficient to provide me with admin rights.

[Test_Engxx]

We have a second test station that is almost identical to one of the two pc's having problems after SP1 was installed.  This pc is running Windows XP and LabWindows 9.1 without the service pack.  We took an image of that machine, and installed it on a pc that isn't working.  I expected it to be a bulletproof solution, but now we have other issues.

MAX does now allow me to view the hardware configuration.

Resman still errors out.

InitVXIlibrary ()  returns a -1, and my test application does not manage to initialize any of the instrumentation.

I was able to control at least one of the instruments with the vendor soft front panel.  This makes me think that Resman is mostly successfull, but doesn't really give me a clue why the Init returns -1.

One interesting note is that the system I am working on shows two VXI systems in Max, which both display the insrumentation in the VXI rack.  The pc we cloned only shows one.

I did find one knowledgebase article about the -1 return that suggested repairing something. 

http://digital.ni.com/public.nsf/allkb/3470C41C514FBCE486256D200069DE1A

It did not appear to fix the issue.

[Test_Engxx]

Update:

I have found that if I right click on the VXI system in MAX and select run resman, it appears to complete without error.  I was also able to verify that If I remove cards from the chassis they do indeed disapear from the resources displayed.  I think MAX and resman are working okay.  I will attach a couple screenshots from MAX that show the two different VXI systems detected.  It appears that MAX is not detecting one of the systems, but is displaying it anyway.  From the list of resources, I can tell that it is from the test system we ghosted.  There is nothing in slot 12 of the system that is down, but the resource list for the first VXI sytem in MAX shows slot 12 being populated.  Another interesting note, although it may mean nothing, is that MAX does not display the model number for at least one device that showed up in the 'other' resource list.

Our IT department is stumped, and so am I.  I don't see why the ghost image didn't work.  Similar PC's on almost identical test stations, but the InitVXIlibrary () still returns -1. 

Do I need to delete the VXI system that isn't actually there?

Any suggestions?