labview 7.1.1 crash on right click of subvi

[bill_gilbert]

We've started having a problem on one computer, with a 3.4ghz, Intel dual core motherboard, win XP pro. When a subvi, usually homemade, and begun under an earlier version of labview, is right clicked in the diagram, we get a dialog stating that "Labview has encountered a problem and needs to close". No kidding. It goes away like somebody filed a paternity suit. We are using some Measurement Computing devices, and their vi's seem particularly prone to this. I read the earlier thread from 2005, which didn't offer much help. Have already installed updated Intel graphics drivers(seemed to fix for a while, but NOT), removed/reinstalled Labview,  tried Repair per Travis H. advice in aforementioned fourm thread:

ttp://forums.ni.com/ni/board/message?board.id=170&message.id=105471&query.id=402919#M105471

 Also tried setting computer to use single core in BIOS. Anybody got new ideas?? 

[Hillman]

Hi bill_gilbert,

Thanks for the post and I hope your well today!

It seems you have followed some pretty good advice so far.

Is it only this one subVI? 

Have you tried re-compiling the subVI under LabVIEW 7.1.1? Best way to do this is Shifht+Control+RunArrow, or alteratively delete a wire, replace the wire and save the vi.

Are you using a type def that was created in an older version of LabVIEW in this program?

I have also read about a very similar issue which was casued by an error in user.lib because of an icon in the Tools library. When deleting dir.mnu the problem is solved.

Please let me know what you think and if anything works,

Kind Regards,

James. 

[bill_gilbert]

Problem happens on many subvi's. This is after upgrade to 7.1.1 and mass compile of entire LV directory. Actually, problem first presented during summer when student was working in LV7.1 before installation of 7.1.1. Have not run into this on any other machine, which has me wondering if it's a conflict with some other software. Have one identical computer that has been in the closet since it's project died of infant mortality. plan to fire that up and see if I can duplicate problem.One guy on this project is a linux disciple and has installed some stuff that is not on any of the other machines. Also, one student worker, who seemed really sensible, downloaded and installed AOL messenger, which finally convinced us not to leave it running with admin privileges. 

[bill_gilbert]

I guess this does have something to do with the palettes, as I now see that I can right click forever until I right click in whitespace and bring up the userlib palette. After that I'm screwed. Also, while trying to move an llb file to the server, got a dialog stating that "the Executable version does not match the resource file. Please check your configuration" Found KB citation with instructions to fix that will try it.

[bill_gilbert · Accepted solution]

Problem solved. I moved the offending userlib to another machine, and duplicated the problem. Then copied dir.mnu file fronm the good user.lib to the bad user.lib, and problem went away. I think had tried to edit the one that was on the problem machine some long time ago. It showed another userlib icon within the userlib palette, which I thought was weird, but never occurred to me that this could bring down the whole system. All fixed now. Something about the user interface in that palette editor never made sense to me. I probably committed some sin and walked away. Proabably made no difference  until we upgraded to v7.1.

[Hillman]

Hi Bill,

Sorry I was unable to reply sooner - I was in 2 meetings 😞

I am glad that one of these peice of advicei gave regarding the dir.mnu in the userlib solved your problem.

And thanks for using the one of the new features in the forums!

Happy LabVIEWing.

Kind Regards,
James