Placing .NET Constructor Locks up LabVIEW 7.0

[Brad99]

I've recently found that placing the .NET constructor causes LabVIEW to lockup and use 100% CPU.

I've tried installing and uninstalling both versions 1 and 2 of the .NET framework but this doesn't solve the problem.

I've tried deleting the adddnrefs.llb file and this doesn't solve the problem.

Any other suggestions (besides re-installing LabVIEW)?

I'm using LabVIEW 7.0 on 2000SP4.

Thanks for any suggestings

[Chris_Cilino]

Brad99,

The description of your problem seems to resemble a while loop without a wait in it ( consumes all CPU cycles, slows down computer). Are there any while loops in your program that have no waits? I was able to use the constructor without any problems in 7.0 so if a non throttled while loop isn't the problem, go ahead and post a small piece of code that demos the problem. Thanks!

Chris C

[Brad99]

Sorry, I should have been more clear. The freeze occurs when I place the constructor from my palette onto the block diagram, not when I run the code. In fact I can't run any code with this constructor because LabVIEW always freezes when I try to place it.

I have found that if I uninstall all versions of the .NET framework I can place the constructor but get an error message about needing to install .NET. Therefore it appears to be a problem with LabVIEW querying the .NET framework and locking up.

[AnalogKid2DigitalMan]

I think there was a patch to .NET framework 1 available at MSN. You may want to try patching after a fresh install of 1.

Also I think only LV 7.1 can handle .NET framework 2 after downloading a patch for LV.

It's been a while, but I think the above is accurate

[Brad99]

Thanks for the suggestion, unfortunately I have still had no luck.

I uninstalled all versions of the .NET framework and then installed only version 1.1 (build 1.1.4322 to be exact). LabVIEW still crashed when placing the .NET consctructor. Then I installed SP1 (from NDP1.1sp1-KB867460-X86.exe), which I think is the patch you were referring to, and LabVIEW still crashed.

As I am using LabVIEW V7.0, I think that installing .NET version 2 is not an option.

Any other ideas greatly appreciated.

[AnalogKid2DigitalMan]

Brad99:

I went and looked at my .NET, it is version 1.1 with a Hotfix (KB886903), see here.

http://www.microsoft.com/downloads/details.aspx?familyid=8EC6FB8A-29EB-49CF-9DBC-1A0DC2273FF9&displa...

That's about all I can suggest. Maybe Brian Tyler will come to the rescue (he is the .NET guru of NI)

[Brad99]

Thanks for the link, I installed the hotfix you mentioned and LabVIEW still freezes.

I wonder if the problem could be because I have a .NET Assembly Reference to a private assembly that is either no longer present, or is corrupt. Unfortunately I cannot view my current private .NET references because .... LabVIEW freezes when I go to tools -> Advanced -> .NET Assembly References. Perhaps if I could clear the private references my problem would go away, but I haven't been sucessful in locating where LabVIEW stores them. Does anyone know where LabVIEW stores the list of private .NET references?

[Chris_Cilino]

Hey Brad,

Not sure if this well help but check out opening the DotNet assembly reference window freezes labview. Also, it looks like installing a beta of .net frameworks 2 could cause the problem. However, if you uninstaller of the .net framework, it doesn't seem to do a good job of cleaning up after itself. Have you ever installed .net frameworks 2?

Chris C

[Brad99]

Hey it works!

For the record, here's what I did:
 - uninstalled all versions of .NET framework (I had previously installed a beta of V2)
 - rebooted machine
 - removed the %WINDIR%\assembly directory
 - removed the %WINDIR%\Microsoft.NET directory

Thanks for all the great help.

[Lycangeek]

Sorry I'm late in replying, but I've been on vacation

Glad to see that everything got sorted out, makes my job easier 🙂

Just for the record, the .NET 2.0/LV problem seems to be restricted to LV 7.1, in which case you need to install the LV 7.1.1f2 patch to get it to work. Versions past that (i.e. LV 8, 8.01, etc) have been tested w/ .NET 2.0 and should have no problems.