LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DOTNET (.net) palette items crash LabVIEW

Solved!
Go to solution

I am trying to rebuild a development system that suffered a disk crash. This is a fresh install of Windows XP/SP3 with all the latest patches. The rebuild process includes installing older versions of LabVIEW development environment. When I get to LV v7.0, v7.1 or v7.1.1  I find that I can create a new blank VI and then try to drop from the .NET palette, any one of the first three "Node" palette items (Constructor, Property or Invoke Node) onto the block diagram and as soon as it hits the blank panel, LabVIEW crashes.  I get the "Do you want to involve Microsoft with this crash" window and that's where the attached information comes from but otherwise there is no other indication about what caused the crash.  The system has all the latest versions of the various .NET Runtimes.  Similar well established XP/SP3 systems also with v7.x don't have this problem. On them a configuration window pops up when the Node part is dropped on the diagram. On this rebuilt system there is no hint of the configuration window, just the crash.

 

Has anyone else seen this?  

Does anyone have any idea how to troubleshoot or fix it?

 

Installed .NET Runtimes:
1.1.4322.2470
2.0.50727.3623
3.0.4506.3636
4.0.30319.235

 

 

Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 1000
Date:  7/27/2011
Time:  3:00:25 PM
User:  N/A
Computer: BEVO
Description:
Faulting application labview.exe, version 7.1.0.4000, stamp 406b53af, faulting module labview.exe, version 7.1.0.4000, stamp 406b53af, debug? 0, fault address 0x00001296.

0 Kudos
Message 1 of 9
(3,444 Views)

I did have a couple of instances where installing a newer version of .NET screwed up a previous installation. Especially when dealing with the myriad number of service packs and fixes. I know this will be a lot of work, but I'd sugges completely removing ALL .NET frameworks (there's a .NET Framework Cleanup Tool available that you can use as a last resort if you have problems uninstalling the frameworks). Then check if LabVIEW still crashes when you try to access a .NET node (you should at least get an error message about needing to have .NET installed). Then install the frameworks one at a time and check if LabVIEW works or crashes.

Message 2 of 9
(3,422 Views)

 

Well that's a good thought and I appreciate the link to the cleanup tool but I can say after a day of installing and uninstalling various combinations of DOTNET that that's not the fix I need. I did discover, as you suggested, that LabVIEW would not crash when all DOTNET versions were uninstalled. It instead gave me a message saying that DOTNET was required for the various functions I was dropping onto the block diagram to work.  DOTNET v4 also produced the same results, no crash but it also would not work with the functions. DOTNET v1.1 by itself would cause the crash. DOTNET v2.0 by itself would cause the crash. DOTNET v3.x seems to always come with v2.0 so it too would cause the crash.

 

 My suspicions at this point are that v7.x versions of LabVIEW don't like being installed onto modern-day WinXP systems with all the updates in place. If I had it to over again I'd just get the baseline XP working and add LV to that and then add all the XP updates and service packs but that would be painful to do again at this point.

 

FWIW, another indication that it’s the NI software that's being cantankerous is that I cannot seem to get any version of MAX to give me a list of the software on the machine. I’ve exhausted all of NI’s suggestions to fix that including twice pulling all the NI software off the machine and reinstalling different bits of it but it has been to no avail.

0 Kudos
Message 3 of 9
(3,408 Views)
Solution
Accepted by topic author WNM

Keep in mind that LabVIEW 7.1.1 only "officially" supported up to .NET 1.1. For .NET 2.0 you need to get the 7.1.1f2 patch, and support for .NET 2.0 was sketchy at best.

Message 4 of 9
(3,398 Views)

I did not know (or had forgotten) about that patch. Thank you!

That fixed the crashing problem! 

 

Patch is found here: http://joule.ni.com/nidu/cds/view/p/id/674/lang/en

0 Kudos
Message 5 of 9
(3,394 Views)

As a followup to the comment about MAX not working (and to leave myself a bread crumb trail that I might be able to find should I ever have to repeat this) I have discovered how to fix my MAX problem. 

 

I knew that the MAX problem was related to the "NI Configuration Manager" (CM) service and its failure to run. The "NI Device Loader" and "NI PXI Resource Manager" services also would not run but on their service properties dependencies tab, the CM service was listed so it's not too surprising that they had failed.

 

Looking at the General tab for the CM service I see that the executable behind the service is "C:\Program Files\National Instruments\MAX\nimxs.exe" so I copy that string to my clipboard.   Next I start up SysInternals Process Monitor ( http://technet.microsoft.com/en-us/sysinternals/bb896645 ) and setup the "Filter" so that it will display only entries whose "Image Path" "is" "C:\Program Files\National Instruments\MAX\nimxs.exe" and then I try to start the CM service.  After the startup process stumbles, this is what I see down at the bottom of the monitor log file:

 

 CM failure.jpg

 

It seems that the process was doing a fairly through search for a "nirpc.dll" file but not finding it and finally quiting.

 

A search of my system with my favorite search tool (   Everything  ) turned up several copies of nirpc.dll stashed away in version-numbered folders below "C:\Program Files\National Instruments\RT Images\NI-RPC\ x.x.x \nirpc.dll".  I picked out the most recent one and dropped a copy into my system32 folder and retried starting the CM service and it worked!

 

Now my MAX (4.5.0f0) gives me a list of the software on the system. 

 

Doing a search of the NI website for nirpc.dll turns up mention of the fact that it has been known to not install properly. This is just another instance of that.

Message 6 of 9
(3,381 Views)

Wow. Sherlock Holmes would have been proud. Smiley Wink

0 Kudos
Message 7 of 9
(3,373 Views)

Hi Warren,

 

The DLLs in the RT Images directory are intended to be deployed to a LabVIEW Real-Time target running Phar Lap ETS, and they aren't guaranteed (or even expected) to work on Windows. However, It sounds like you already went through the hassle of uninstalling and reinstalling all of the NI software, so short of finding the actual NI-RPC MSI on your installation media and uninstalling/reinstalling (or repairing) it, I don't have much else to suggest.

 

Brad

---
Brad Keryan
NI R&D
0 Kudos
Message 8 of 9
(3,364 Views)

Thanks for the heads-up about the pedigree of that file Brad. I still can access most of the files on the old "crashed"** system so I can pull the nirpl.dll file out of the old system32 directory and drop it into the new one. Hopefully it work will work at least as well as the wrong file did.

 

** Actually one day the ATX supply started putting out 4.5V instead of 5.0 and that hosed a bunch of the OS files on the disk but disk is physically fine. Only the system disk seemed to object to the low voltage.

0 Kudos
Message 9 of 9
(3,354 Views)