Releasing hardware resources on LabVIEW crash

Hi all,
I am using PXI chassis with many DAQ cards, mux, ARINC,RS-422 etc.
It is a common problem that in the event of LabVIEW crash, the hardware resources are not released and the system should be restarted to access the resources again.
Scenario:
LV1 is the main LabVIEW program that opens the harware resources.
LV2 is a separate LabVIEW program (a utility) runs as a separate process.
Now if the LV1 opened few references to the hardware devices and shares these references to the LV2.
In the event of LV1 process crash, LV2 still runs; can the LV2 process close the open references?
Can LV2 process release the resources opened by LV1?

It really depends a little. Even XP was fairly good about releasing normal OS objects such as all kind of handles (files, synchronizationo objects, GDI objects, etc). But once kernel resources get involved things get a lot more trickier and I really doubt there is an universal way for an OS to make sure even such resources get properly closed on process termination without a very intensive, expensive and performance hungry bookkeeping. And I don't see the average user wanting to pay that price in performance all the time for the incidential case when the system crashes.
So in general it is safer to restart the OS after a crash even if the system seems to work fine, This is definitely true if your application has been involved in some way with directly invoking kernel drivers, which any application that interfaces to NI (and other manufacturers) hardware basically does. I'm not saying that NI couldn't possibly improve that in the user space part of those drivers somehow. However the effort for that could be pretty expensive and the perceived advantage would be small for most end users.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Similar Messages

Why does LabView crash when unloading my DLL (reentrant calls)?

I have written a DLL in Borland Delphi using multiple threads that exports several functions (stdcall). I am using LabVIEW 6i on a WinXP machine. All functions in the DLL work as expected and return correct values. Everything works fine if I set all Call Library Function Nodes to 'UI-Thread', but as soon as I set one Function Node to 'Reentrant', LabView crashes when I close the VI after it has been executed. I assume the error is caused by the DLL unloading mechanism of LabView. Other C++/Delphi programs using the DLL reentrantly work fine, this only occurs in LabView. In which thread does LabView call FreeLibrary/DLL_PROCESS_DETACH? Has anyone experienced similar problems?

I have never run into this situation myself, but I do know that calling a multi-threaded DLL or CIN from LabVIEW does depend upon the following criteria:
If your CIN/DLL doesn't have any global data storage (global variables, files on disk, etc.), AND it doesn't access any hardware (register-level programming) AND it doesn't call any functions/DLLs/Drivers that are thread-unsafe.
OR
Your CIN/DLL protects (with semaphores or mutex's) access to those global resources.
OR
Your DLL is only called from one, non-reentrant VI
OR
Your CIN is only called from one, non-reentrant VI AND you don't access any global resources from CINInit, CINAbort, CINDispose, etc. procedures.
Hopefully this information can help you out in some way.
J.R. Allen

No VISA Resources in Labview but all present in MAX

Hi,
I am unable to find any VISA resources from LabVIEW, however, all NI hardware is available and working in MAX. I have just installed a PCI-8433/2 as well as a NI PCI-8512 CAN/HS Card. As part of the installation I believe MAX was upgraded to version 4.6.2. I will attach the max configuration report for those who are interested. I am working with LabView 8.2. I also uninstalled an agilent GPIB card and as a result the NI-GPIB card is the sole controller and is GPIB0... instead of the agilent card.
I have had a similar problem before that was a result of a corrupted database, but I was unable to find this problem on the forums this time and I am not getting any errors. Just an empty VISA Resource control.
Any suggestions would be greatly appreciated.
Nate
MAX Configuration Report
12/27/2010 1:35:05 PM
MAX Summary
My System
Data Neighborhood
CAN Channels
NI-DAQmx Tasks
V1P1V2P2
V3P3
Devices and Interfaces
GPIB0 (PCI-GPIB)
Instrument0
Instrument1
Instrument2
Instrument3
Instrument4
Instrument5
Miscellaneous VISA Resources
GPIB0::INTFC
GPIB0::16::INSTR
GPIB0::2::INSTR
GPIB0::22::INSTR
GPIB0::7::INSTR
GPIB0::10::INSTR
GPIB0::27::INSTR
GPIB0::3::INSTR
Network Devices
NI-DAQmx Devices
NI USB-9481: "Dev2"
NI USB-9481: "Dev1"
NI-XNET Devices
NI PCI-8512 CAN/HS
CAN1
CAN2
PCI-8433/2
Port1
Port2
PXI System (Unidentified)
Serial & Parallel
COM1
COM6
COM9
LPT1
Scales
Software
IVI Compliance Package 3.3
LabVIEW 8.2
LabVIEW Run-Time 7.1
LabVIEW Run-Time 8.0.1
LabVIEW Run-Time 8.2.1
LabVIEW Run-Time 8.5.1
LabVIEW Run-Time 8.6.1
LabWindows/CVI Run-Time 9.0
Measurement & Automation Explorer 4.6.2
Measurement Studio for VS2005
DotNET
Common
NI LabVIEW SignalExpress 3.0
NI Spy 2.7.1
NI-488.2 2.46
NI-CAN 2.7
NI-DAQmx 8.7.2
NI-PAL 2.5.3
NI-Serial 3.6
NI-USI 1.0.2
NI-VISA 4.6.2
NiVisaServer.exe
NIvisaic.exe
NI-VISA Runtime 4.6.2
NI-XNET 1.1
IVI Drivers
Advanced
Instrument Driver Software Modules
Simulation Driver Software Modules
Simulation Driver Sessions
Driver Sessions
Logical Names
-Nate
Solved!
Go to Solution.

Now that IS odd.
Can you show a couple screen shots from MAX?
First expand the software tab and post a png of the screenshot (I'm not yet convinced you do not have SOME driver issue)
Next select MAX>TOOLS>NI VISA>VISA Options- Wait for the new screen then expand Mysystem General settings and select Aliases.
You could also try "Clear all aliases" from there and reboot.
Jeff

LabVIEW crashing when running NI-DSP VI on Windows XP

I am in the process of upgrading a software application from LabVIEW 3.1 on Windows 3.11 to LabVIEW 7.0 on Windows XP with NI-DAQ 7.2. The hardware has been replaced, the relevant hardware change here is from the AT-DSP2200 to the NI-4551.
The source code uses the NI-DSP libraries to control the DSP2200. I can't find any equivalent in the new LabVIEW (and have assumed that there is none, this is all covered in the MAXX now). The source code has been convereted to LabVIEW 7.
When the source code is opened on the Windows XP machine LabVIEW crashes. I've traced to cause of this crash to the NI-DSP code. Whenever I try to open any VI that contains the DSP code it crashes LabVIEW. I think the problem is the CNI call
inside the DSP library. When I try opening the source code on a computer that doesn't have the NI-4551 installed there are no problems.
What is the upgrade from NI-DSP to? Is there a direct mapping of NI-DSP functions to equivalent NI-DAQ ones? How is it that having the hardware plugged in causes a crash even though it shouldn't be accesssed until I run the VI?
Any help would be appreciated.
Thanks.

Hello EborLance,
The NI-4551 can use either NI-DAQ or NI-DSA as the driver. If you only have NI-DAQ installed, any program that uses the NI-DSA functions may be crashing.
There is no direct mapping of NI-DAQ functions to NI-DSA functions but you can download and install the NI-DSA driver from the website. Current DSA Drivers
Once you have installed the NI-DSA driver, you should see the functionality you were previously used to and your program should run.
Thanks,
C. Flip
National Instruments

LabVIEW crashes when I save changes to a particular VI.

LabVIEW crashes when it tries to compile a particular VI. I have managed to get it to work a couple of times by changing a few things and making some subVIs, but the problem keeps returning.
Is there some way to fix this or clean the VI of whatever corruption keeps occurring?
Thank you,
David R. Asher

I can think of address/hardware conflicts or something that LabVIEW cannot provide an error message. I would go with hardware/address conflicts.
Try renaming the file and executing it stand-alone. also try making it as a subvi and run the toplevel code.
Kudos always welcome for helpful posts

"Top level objects not released" warning when accessing LabVIEW adapter through API

I'm having a problem when using the TestStand API in LabVIEW: I'm trying to get the VI path for a TestStand test step, but I'm getting the "Top level objects not released properly" warning. It doesn't look like I'm forgetting to close something, but obviously I am. Snippet is below, and warning text follows. Anyone have any ideas?
I'm using LabVIEW 2010 and TestStand 2010.
This forum has been a huge help. Thanks to everyone!
-Joe
References to PropertyObjects were not released properly. Total number of objects: 418 Number of top-level objects: 7
Note: Some top-level objects may be included if they are referenced by an incorrectly released top-level object. For example, an unreleased SequenceContext object references a SequenceFile object.
The following top-level objects were not released:
Type Definitions [6 object(s) not released] Type Definition #1: Name: FlexGStepAdditions
Type Definition #2: Name: VIParameter
Type Definition #3: Name: VIParameterElement
Type Definition #4: Name: NI_LabVIEWParameterResult
Type Definition #5: Name: Expression
Type Definition #6: Name: Path
And the following uncategoried objects: LabVIEWModule (FlexGStepAdditions) Name: SData
Solved!
Go to Solution.

Yep, that worked. I thought that Variant To Data was just converting the module reference to the LabVIEWModule data type, but apparently I was wrong... This TS leak checker is sure making me learn about how to properly close references... I've been programming memory leaks for years!
I was also having problems with LabVIEW crashing after the VI ran, and fixing the order of the close references fixed that, too.
Working code is below.
Thanks a lot (again) Doug.
-Joe

Repeatable LabVIEW crashes on Mac

Confounded by this new problem.
Platform: Mac OSX 10.6.5 (this problem first cropped up while I was using 10.6.4 - I had previously no problems with 10.6.4)
LabVIEW 2010
I cannot suddenly open any instrument subVIs (subVIs created by me open fine) without crashing LabVIEW. It does not matter when the VI was created. I just cannot open the subVIs. I was able to, only last week (and before that).
Solved!
Go to Solution.

Same here, update from 10.6.4 to 10.6.5 and then every time I open a VI a try to create a VISA resource name control LabVIEW crashes. Both LV 2009 and 2010 exhibit the same behavior.
By looking at the crash log, it seems that nipal has some problems when loading libSystem.B.dylib.
I'll try to reinstall VISA and be back to you about the result.
Ch
(BTW, look at the funny way the editor interprets the crash log by replacing ": D" with smiley)
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x91362176 __kill + 10
1 libSystem.B.dylib 0x91362168 kill$UNIX2003 + 32
2 libSystem.B.dylib 0x913f489d raise + 26
3 libSystem.B.dylib 0x9140a9bc abort + 93
4 com.ni.framework.nipalu 0x2679d7df _palPrintToLog + 1547
5 com.ni.framework.nipalu 0x267a8fc3 0x2671f000 + 565187
6 dyld 0x8fe0ed6d ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 235
7 dyld 0x8fe0d31e ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 246
8 dyld 0x8fe0d2c2 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 154
9 dyld 0x8fe0d3d1 ImageLoader::runInitializers(ImageLoader::LinkContext const&) + 61
10 dyld 0x8fe0200b dyld::runInitializers(ImageLoader*) + 34
11 dyld 0x8fe0b299 dlopen + 558
12 libSystem.B.dylib 0x913078a8 dlopen + 66
13 com.apple.CoreFoundation 0x96f8413a _CFBundleDlfcnLoadFramework + 218
14 com.apple.CoreFoundation 0x96f49b13 _CFBundleLoadExecutableAndReturnError + 1523
15 com.apple.CoreFoundation 0x96f49511 CFBundleLoadExecutable + 33
16 com.apple.CoreFoundation 0x96f4a189 CFBundleGetFunctionPointerForName + 57
17 com.ni.framework.VISA 0x2409cf9c visaLibSymbol + 68
18 com.ni.framework.VISA 0x2409d4a9 visaLibFree + 1267
19 com.ni.framework.VISA 0x240a1247 viFlush + 2194
20 com.ni.framework.VISA 0x240b484e viOpenDefaultRM + 1262
21 com.ni.framework.VisaCtrl 0x1cff5080 GetIOControlNames + 2570
22 com.ni.framework.VisaCtrl 0x1cff46f8 GetIOControlNames + 130
23 com.ni.labview 0x0086267e TagDriverNameProvider::GetIOControlNames(unsigned long, unsigned char const*, _LStrArray***, LvVariantArray***, LvVariant const*, long, void*) + 98
24 com.ni.labview 0x0000fc22 TargetTagNames(LVContext*, unsigned char const*, _LStrArray***, LvVariantArray***, LvVariant const*, long, void*) + 94
25 com.ni.labview 0x0000e886 TargetAsyncTags::UpdateAsyncTargetTags(LVContext*, unsigned char const*, LvVariant const*, long, long) + 348
26 com.ni.labview 0x0000ed82 UpdateAsyncTargetTags(ObjectHeap*, BasicObject*, long) + 146
27 com.ni.labview 0x00f643a9 AsynchUpdateIOControlNames(ObjectHeap*, BasicObject*, long) + 107
28 com.ni.labview 0x00f64520 AsynchUpdateIOControlNameLists(ObjectHeap*, BasicObject*) + 22
29 com.ni.labview 0x00b4cae8 StdTag:raw(void const*, BasicObject*, long) + 170
30 com.ni.labview 0x00b272e2 StdRefNum:raw(void const*, BasicObject*, long) + 266
31 com.ni.labview 0x00a556b8 Pane:raw(void const*, BasicObject*, long) + 618
32 com.ni.labview 0x00b58530 SuperCluster:raw(void const*, BasicObject*, long) + 100
33 com.ni.labview 0x0078ac5c DrawWithoutBackup(ObjectHeap*) + 82
34 com.ni.labview 0x0145835b VIDraw(WEvent*, ObjectHeap*, void (*)(void*), void*) + 2223
35 com.ni.labview 0x01463826 VIWinProcCore(WEvent*, ObjectHeap*) + 12200
36 com.ni.labview 0x0146682a VIWinProc(WEvent*, long) + 448
37 com.ni.labview 0x00cf6f46 InternalEventProc(WEvent*) + 32
38 com.ni.labview 0x00cfd52a WSendEvent + 296
39 com.ni.labview 0x00cf9699 TopLevelUpdate(Wind_t**) + 193
40 com.ni.labview 0x00cfb02d WUpdate + 71
41 com.ni.labview 0x000092bc OSEventProcessor_MacUI::HandleEvent(EventRecord*) + 372
42 com.ni.labview 0x000093e7 OSEventProcessor_MacUI::HandleEvent(bool, long*) + 53
43 com.ni.labview 0x00c69033 MainLoop_Default::Run() + 75
44 com.ni.labview 0x0000c6c6 MGMain(long, char**) + 272
45 com.ni.labview 0x0000cb10 CommonMacMain + 364
46 com.ni.labview 0x00002102 _start + 216
47 com.ni.labview 0x00002029 start + 41

LabVIEW crashed while loading Sensor Mapping Express VI

Dear all,
I've just installed LV8.6 evaluation with all the toolkits available in the DVD. I have two problems now, one major and one minor:
1. Whenever I tried to use the Sensor Mapping Express VI, LabVIEW crashed with the pop-up window saying that "LabVIEW 8.6 Development System has stopped working". When I expanded Window's error pop-up, the message as can be found below. The same error occurs whenever I tried to load the sensor mapping demo I downloaded from the Developer Zone. I'm using Dell Inspiron 640m, by the way. When I tried with another Dell laptop (Dell Vostro), everything was alright.What I've done so far is to uninstall all NI's softwares inside this laptop, defrag, clean the registry and then reinstall LV 8.6 again but to no avail.
Error message:
Problem signature:
Problem Event Name:    APPCRASH
Application Name:    LabVIEW.exe
Application Version:    8.6.0.4001
Application Timestamp:    4862fd60
Fault Module Name:    ig4dev32.dll
Fault Module Version:    7.14.10.1147
Fault Module Timestamp:    457ef11c
Exception Code:    c0000005
Exception Offset:    000063b2
OS Version:    6.0.6001.2.1.0.768.2
Locale ID:    17417
Additional Information 1:    da97
Additional Information 2:    7a880e72b9f1636f81b04947e06e5c6a
Additional Information 3:    09b4
Additional Information 4:    56e138085db0c350e7bf46ba31a7691f
My computer specs are:
OS: Windows Vista Home Basic
RAM: 1.5 Gb
Harddisk: 10Gb free (after LV is installed)
Processor speed: 1.6 GHz Dual Core
Anti Virus: Kaspersky Internet Security
2. This is minor but still an annoyance. Whenever I tried to load my newly installed LabVIEW 8.6, it takes about 10-15 minutes before I got the Getting Started window. This includes the 5 minutes waiting period before I got the window stating how many days left for evaluation. This wasn't the case when I used LabVIEW 8.5.1 (even when every toolkits and modules are installed). Why so long?
I've asked the local NI engineers but they are also clueless.

Hi Lan,
Thanks for your post and I hope your well today.
1) You specs seem okay.
Minimum
Recommended
Processor
Pentium III/Celeron 866 MHz or equivalent
Pentium 4/M or equivalent
RAM
256 MB
1 GB
Screen Resolution
1024 x 768 pixels
1024 x 768 pixels
Operating System
Windows Vista/XP/2000
Windows Vista/XP
Disk Space
1.6 GB
1.6 GB (Note -- Includes default drivers from NI Device Drivers CD)
There has been some record of issues with the Sensor Mapping Express VI.
Does it crash when you place it down on the block diagram? Or when you click to move it? Or when you run it? Does this happen when you load a model into it?
However, as it seems to be an instance of your Dell Inspiron 640m, Im not sure what we can suggest - except to ask how the specs compare between the two machines?
Some advice for Dells,
#) So that LabVIEW can function properly with the video hardware, it is
occasionally necessary to reduce the video acceleration. You can do
this on Windows 2000 by right clicking on your desktop » Properties » Settings » Advanced » Troubleshooting.
Start with the second setting from the right, "Disable bitmap and
cursor acceleration.", and work your way left if the problem persists.
#) Number of other issues with versions of Dell video drivers.. upgrade?
2) If this is a new installation that is slow then you may be having issues with specs, however there are a few things to try:
a) Defrag Drive
b) VLM licensing? If so, there is a timeout of a view minutes... is your version licensed currently?
c) Clean your registry
d) Check LabVIEW ini file to make sure the tasks are all necessary and the paths are local.
e) Repair LabVIEW finally
Hope this helps make some progress,
Kind Regards
James Hillman
Applications Engineer 2008 to 2009 National Instruments UK & Ireland
Loughborough University UK - 2006 to 2011
Remember Kudos those who help!

Why does LabView crash when I run it in parallel with a temp/ RH logging probe?

I am running LabView 6.1 on windows 95. Up till now I have had no problems. However, we recently acquired a Temperature / Humidity probe which plugs into the Com1 port of the computer and logs the data using it's own software. Since then, when the two programs are used together, eventually LabView crashes with the following error message: Failure, 'image.cpp, line 5793.
Can you tell me why this occurs and what the solution is?

Taking a shot at this. It could be because the two programs are trying to access the same type of logging program(excel??). Only one link can be active at a time or they crash. Try running it without saving the data and see if it crashes.

Labview crashes every time I click on a broken arrow (vi has errors).

I just upgraded Labview from 7 to 8.5.1 a few weeks ago. Now, when I press the broken arrow to check the errors in a vi, Labview crashes. This is a vi that was developed using the state diagram toolbox under Labview 7. I now have the state chart toolbox but not the state diagram toolbox.

Try to disconnect the state diagram from the the state diagram (right-click on the main while loop).
If that doesn't work in 8.5, try to do this in 7.1.
Or install the state diagram toolkit in 8.5.
Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

LabVIEW crashes when you run a VI that contains a mixed signal graph with a multi-plot cursor.

Hello, LV 8.2.1 notes indicates the following bug fix:
43SAIR2A Fixed an issue where LabVIEW crashes when you run a VI that contains a mixed signal graph with a multi-plot cursor.
I am running this version, and still have this behavior. Is there anything I may be missing, and/or certain circumstances that may still be causing this?
thanks in advance,
Darren

Darren:
I looked at the CAR ID that you mentioned and the issue has been resolved in LabVIEW 8.2.1. To verify something similar, I ran the attached VI and things worked just fine. Please feel free to send me the steps to follow to reproduce the issue you are running into in 8.2.1.
Regards,
Rudi N.
Attachments:
MixedGraphs.vi ‏15 KB

Labview crashing - running dll. motorbee

Hi, I'm a student doing my masters project.
I'm trying to run a dc motor with the driver board and software called motorway from pc-control.co.uk
The board came with some software to run it and I have the dll. and header files.
I have managed to import the files, however whenever I try and run the "set motors" vi, labview crashes for no reason and doesn't give an error code.
The files can be found here https://www.dropbox.com/sh/0nbrx0ncyfg58y0/rKMy9iMAKE
Thanks a lot for any help as I don't have much time to complete my project!
Cheers
Henry
Attachments:
mt.h ‏1 KB

Hello, can you please post your LabVIEW code so I can look at the error in order to be able to help.
Thank you

Labview crashing when building application (exe)

Hi,
I am trying to build an application from a simple labview (2011) vi. All the vi does is sets (boolean = TRUE) a line on the digital output card (NI 9472) when I start running the vi. The program works fine after I have coded it. But when I try to build an exe file (application) of that project, then labview crashes in the build process. Is this a known issue? please help. I am attaching my vi alongwith this email
Thanks
Solved!
Go to Solution.
Attachments:
relayProject.lvproj ‏34 KB
relay.vi ‏21 KB

I'm sorry to hear that gascars. I have downloaded your project and VI and have succesfully built an executable in both LabVIEW 2011 and LabVIEW 2012. Can you please send me a screenshot of the error you are receiving? Also, can you make a simple VI that just adds two numbers and see if that can be made into an .exe.
Thanks
Chris
Chris
National Instruments
Applications Engineer

LabView Crashing and compile server error.

Hi,
I'm having some errors when I compile code for my FPGA (PXI-7831R). I am using LabView 8.2.1.
Sometimes labView crashes completely and sometimes it comes up with a compile server error.
My code contains 3 VI's. The first send sends digital output and reads digital input 10 times and then called another VI to save these results. The second VI repeats the first VI 10 times.
When the first VI is compiled on its own it works (including the saving data VI which saves it to a FIFO) but when the second VI is compiled, that is when it errors.
I have attached the compile server errors and the screen dumps of when labView crashes.
Can anyone suggest what I am doing wrong?
Thanks.

ok. Let me try and make my problem a little clearer....
I have now combined all the VI's into one.
It is supposed to write to the digital output and read from the digital outputs 10times at a rate of 10us and store the data to the FIFO. This process is then repeated at a rate of 80ms for 8 times.
I have attached a word document with an explanation on the error.
Attachments:
lvlog07-26-07-12-04-50.txt ‏3 KB
Problem Explaination.doc ‏61 KB
f623_appcompat.txt ‏93 KB

Monitor hardware resources in ucs

Hi everyone,
we've just purchased 2 ucs c240 and 1 c220 and we need to know how to monitor hardware resources like disks faults, fan faults, …...
Can someone help us?
Thank you.
Massimo

Does this help?
https://supportforums.cisco.com/discussion/11529571/ucs-c-series-hardware-monitoring

Releasing hardware resources on LabVIEW crash

Similar Messages

Maybe you are looking for