APPCrash on initialization of Labview

I get the following error notice when I try to initialize LabView. It will not start correctly.
Problem signature:
Problem Event Name: APPCRASH
Application Name: LabVIEW.exe
Application Version: 10.0.1.4002
Application Timestamp: 4d2fa7a6
Fault Module Name: LabVIEW.exe
Fault Module Version: 10.0.1.4002
Fault Module Timestamp: 4d2fa7a6
Exception Code: c0000005
Exception Offset: 018d7f76
OS Version: 6.0.6002.2.2.0.768.3
Locale ID: 1033
Additional Information 1: dc0b
Additional Information 2: 873d0176a93954fe135a8a4b75b24b24
Additional Information 3: 4660
Additional Information 4: 17053f6932b1708da7cd4ee5f404311c
Steven S. Hardy

Is this the first time you've tried to run LabVIEW on this computer? YES
OS version 6.0 indicates Vista. The exception code could be, I believe, related to a driver. What kind of computer do you have? DELL XPS 1530 32 Bit.
What else besides LabVIEW have you installed? Not very much.
Have you tried a repair of LabVIEW? Yes, Twice.
Have you tried an uninstall and reinstall? NO (Make sure to turn off your anti-virus during installation.)
If you were installing drivers I'd suggest installing only the LabVIEW development environment to narrow it down. I just put in the disk and Run it.: NI LabView for Lego Mindstorms.
Steven S. Hardy

Similar Messages

Appcrash adobelingguistics.dll

How do I resolve a CS6 AI Illustrator launch failure? Has worked in the past without a glitch??
Vista Home Premium 64bit, AI Illustrator.exe APPCRASH on initialization fault module adobelinguistics.dll version 6.0.0.17206

Run the cleaner tool and reinstall the program.
Use the CC Cleaner Tool to solve installation problems | CC, CS3-CS6
Mylenium

Win8繁体装lv打包的程序出错fatal error unable to find initialization file

win8繁体装lv打包的程序出错fatal error unable to find initialization file

我的labview是2012简体版本，在win7简体系统上开发

I have encountered the new error "Fatal internal error fpinit.cpp line 7398

I get the error message "Fatal internal error fpinit.cpp line 7398".
I use:
TestStand 2.0
LabView 7.1
Vision 7.1
uEye USb Camera
I've included into my TestStand programm some new steps that control the uEye USB Camera.
I use following steps (all steps written in LabView):
- Initialze Camera
- Wait
- Close Camera
- Wait
I have the settings "Load dynamically" in TestStand"
If I use also the setting "Unload after sequence executes" and start the sequence I get somtimes a LabView error after running the Step for the Camera initialization. LabView is sometimes immediatlly closed. This happen at leased after 10 turns/starts of the programm. If I use the loop functions "Loop on selected steps" it happen only sometimes at the first loop. The initialize Camera Step is every time pass, if TestStand try to run the next step I get a error.( Sometimes I get also the message ActiveX Server got lost)
I detected also that sometimes in this case a constant in a other vi is emty.
Normally I use the setting "Unload when sequence file is closed" then I have the problem only sometimes at the first turn.
If the initialize Camera step is succesfull I have no problem with further camera steps.
Regards
Alexander
Attachments:
lvlog02-18-10-09-34-10.txt ‏1 KB
Copy of Error.jpg ‏76 KB
Copy of Error2.jpg ‏42 KB

Hi Alex,
I'd suggest to replace all ctl. with new ones.
Perhaps one of them is corrupt.
You will find a documentation about preferred execution system
in the LabVIEW help. I also attached this files.
Regards
DianaS
Attachments:
help1.gif ‏37 KB
help2.gif ‏11 KB

Error 1097 calling dll

Hi,
I am trying to read Data from a frame grabber card in my PCIe slot. When I call the "Initialize" function from the .dll I got with the card I always get the error 1097. 1097 means that the function called threw an error. When I run the program that came with the frame grabber, the frame grabber still works.
If I simply omit the "initialize" function call and continue with the function, that would be called after the "Initialize" function, LabVIEW crashes(Program shuts down without any warning).
I also got a LabVIEW program that uses the dll which was supposed to work. But here I get the same error.
Do you have any idea what normally causes this behaviour and how I can solve this Problem?
Solved!
Go to Solution.

jak888 wrote:
The thing is:
I don't have many options left to configure e.g.: there's one function called void initialize (uint_16t nDevNo) so I call it configuring it accordingly. The only thing I could change is the calling convention. When I set it to C I got the 1097 error. When I set it to stdcall I think it destroyed the dll. I had to replace it to make the VI start again.
When I looked at the dll before I baught the grabber card, I paid attention if there were any "funny" variables, like unions, structs or Arrays of pointer to union of struct, because I had Problems with stuff like that before. The dll is really simple basically, so I don't quite get why it shouldn't work. As you said: the reason it sometimes works and sometimes not is because it never really works...
Today I am going to send back the frame grabber and order another one that's supposed to work with DirectShow... Hopefully that turns out better.
Well a frame grabber surely has more complex functions than "void initialize(unsigned short)". How would you get otherwise the grabbed image in LabVIEW. If this function alone already bombs (sorry for the old Mac reference), well then this DLL surely is worthless. It could be that you need to pass a valid device number of course, but such a simple function that attempts to corrupt memory when passed an invalid parameter is simply rubbish.
Usually the problem starts with other functions. And it's not only the problem with the complicated data types. A simple byte array can cause that error too. Lets assume you have instructed the frame grabber to return an image of 1024 * 800 pixels in RGB 8 bit format. When you call the grab function, it will want to write the image data into a memory buffer. And someone needs to provide that buffer. And LabVIEW not having mind reading capailities can not do that for you. So you need to know how the function will try to store the image data in the buffer. Each pixel would require at least 3 bytes. Maybe 4 if they store it in RGBx format, since that is easier to align in memory. Then the grabber may also add a border around the image. This could be anything from 0 to several pixels on each side. And last but not least it may add a header with image information before the image pixels.
So you get x + (1024 + y) * (800 + y) * 3 or 4 bytes. This buffer needs to be allocated by you on the diagram and passed to the DLL function.If you happen to not allocate that buffer or make it a few bytes to small the DLL function will attempt to write into memory that has not been allocated for that purpose. It could not be allocated at all for the current process in which case the CPU will raise an exception, and LabVIEW will report the 1097 errror or it could be allocated for something else in LabVIEW and sooner or later LabVIEW trips over that corrupted memory and does something weird or crashes, causing itself an exception that could cause the 1097 error. Sometimes the error only makes itself apparent when you close LabVIEW and it tries to properly deallocate all its memory blocks, stumbling eventually over some corrupted memory pointer your DLL has caused.
A frame grabber may support different image formats so your grab function would also need to be flexible enough to account for that too.This all is why writing a frame grabber interface for LabVIEW (or any other programming language) is usually a much sought something but seldom gets done by anyone in a way that really works.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Possible threadsafe issues using Matlab scripts?

Hi all,
I'm developing an application in Labview 6.1 that makes extensive use
of Matlab scripts. The application executes the same set of
scripts for multiple data sources, and keeps track of the inputs and
outputs for each data source separately. I've been noticing that
the application produces the correct results when running only one data
source, but that the results are often incorrect when I run it against
multiple data sources.
I've done some investigation, and have found that all Matlab scripts
share a common memory workspace in Matlab. That is to say that if
I have ScriptA that takes variable X as an input, and ScriptB that does
not, ScriptB nonetheless has access to variable X in its workspace
(from the last time ScriptA was called). This doesn't pose a
problem to me directly, but it has made me wonder if there are
potential threading issues in the scripts.
Consider the following scenario with one script and two data
sources. I'm wondering if this scenario is possible in Labview:
1. Thread1 calls ScriptA, passing data from SourceX.
2. During Matlab execution (somewhere in the middle), Thread1 is suspended.
3. Thread2 calls ScriptA, passing data from SourceY (data have the same variable names, since it's the same script).
4. Thread2 finishes ScriptA execution uninterrupted with SourceY data.
5. Thread1 is reactivated, but now the Matlab workspace data has
been replaced with SourceY. So, Thread1 started with SourceX
data, but finished with SourceY data.
6. An incorrect result for Thread1 is produced, because the wrong data was processed.
Clearly I could get around this problem with a semaphore, but first I'd
like to know if this scenario can even happen. Are Matlab scripts
treated as atomic operations in Labview, or can the threads be
suspended midway through execution?
Thanks for your help!
cjb

Hello,
No. LabVIEW will definitely not compile a VI while it's running - I think that would be, even conceptually, impossible. In fact, some properties (accessed via property nodes) are not editable at run-time for basically that reason, that a recompile would be necessary in order for the affect to take place, and the recompile can't take place at run-time!
It is indeed strange behavior, particularly because it is intermittent (which does hint at a threading issue, or some factor outside the development environment). Can you try moving the initialization to LabVIEW? I have attached an example of a so-called functional global variable (a simple code module in this case). It has two "states" (which are cases) - one is initialize and the other is the "usually executing case." The initialize case is used to initialize the shift register to an array of 50 doubles, where the other case will compute the running average, min, and max across the 50 most recent random numbers generated. The 50 data point code module.vi is the code module, and it is called by Use 50 data point code module.vi. When you run Use 50 data point code module.vi, be sure to toggle the initialize boolean so that the initialize case executes once to allocate and initialize an array with 50 elements; when you toggle it back then it will execute the other case on each iteration, and begin computing the statistics noted by keeping an array with the 50 most recent random data points generated.
I hope this helps and that you are able to incorporate a similar code module into your application to avoid the intermittent errant behavior!
Best Regards, and feel free to post again with updates!
JLS
Best,
JLS
Sixclear
Attachments:
Use 50 data point code module.zip ‏27 KB

How can I check the instru manu ID

I had a Tek 4330 card (of 1995) repaired and either the Manufacture ID info has changed (and/or the firmware) and now I get error 1223. It is in a Tek VXI rack with an NI GPIB-VXI/C in the first slot. I'd like to turn off the ID query, but the switch setting does not show up on the VX4330Intialize.vi. Even if the ID query is turned off I still want to find out what the manufactures ID and Model code are set somewhere in the Labview software. Can anyone tell me where to look? Does anyone know why the ID query is not shown for the initialization files (Labview 4.0.1). Thanks in advance for any help.

First open the VI called VX4330 Initialize. Set the logical address and platform to match what your're using. Then you can open the diagram to view the code (Window>Show Block diagram or Ctl-E). You will see an outer case statement - make sure it's set to False. There is an inner case statement. Set this to 1. You will see the text "Query ID and device type register". There are two VXI Read Register functions. One for 0 and one for register 2. Each of the functions has a blue wire coming out of it. Move the mouse over each wire, right click, and select Probe. This will create a new window for each probe that will display the actual values returned. If both values do not match the expected results, you will get error 1223. To change the ex
pected value, just enter the actual values in the numeric constants. These are the little blue boxes with some hex values in them.

LabVIEW 2014 x64 AppCrash StackHash crash

Our application is crashing somewhat inconsistently in the x64 compile, but not the x32 compile. We are using LabVIEW 2014. When it crashes, LabVIEW stops responding and has to be closed from windows. The View Details feature says it's AppCrash and further says StackHash_someHEXnumber. Another member of the team analyzed dump files and seemed to think it's crashing in the LabVIEW run time.
Any known issues out there that would explain this?
It happens on the original release of LV2014x64 and SP1. It happens in LabVIEW and in a compiled executable. If is not consistent, if we open the software and start running tests, sometimes it will never crash, other times it will crash before 1500 test runs. Our way of testing this has been to run 1500 runs, then close it then reopen it, run again. If it doesn't crash within 3 times of doing 1500 runs, we say that the crash probably isn't going to happen in that version of the software. So we've been selectively disabling parts of the software trying to figure out which code is triggering the crash.

Some more information:
In addition to not happening in LV2014x86, it does not happen in LV 2014 MacOS x64. So this is specific to LV 2014 Windows x64. Furthermore, if we save our code to previous and open it in LV2013x64 there's no crash (there's some hickups with the downgrade so it's not 100% apples-apples though) .
We have narrowed the crash down to a specific changelist in source code control. In that changelist we changed the architecture of how we pass messages around in our program. We used to use User Events to pass messages and the vi listening would subscribe to the user event. However, we found this created a memory leak in LV2012. So we switched to a queued based messaging architecture in this changelist. We created a variant which held the queues as a variant attribute associated with the message enum. This was so that when a message is sent we could do a fast lookup by taking the message and getting a varriant attribute associated with it (thus giving us the queues subscribing to that message). When we introduced this in LV2012 we stressed tested it all and it worked great. Later we upgraded to LV2014 and that's when the crashing started, we have gone back to this specific changelist and tried it with LV2014 it crashes.
We have found other parts of our code which if we disable the crashing goes away. Our suspicion is that this occurs due to a perfect storm of calling vi's asyncronously (which call other vi's ascncronously), passing messages to them via queues, and maybe the variant's containing queues in attributes. Based on what various programmers have seen via a variety of observations, our suspicions are that some combination of those circumstances is triggering some sort of LV2014 windows x64 bug.

Unable to initialize IMAQ1394 in Labview

I have a new problem. This used to work OK. I get the attached error when trying to initialize my camera using Labview. I can use MAX without a problem, and a previously built executable works. An executable that I just built gives the same error, though. I have uninstalled and reinstalled NI-IMAQ for IEEE 1394 Cameras, but it did not help. Any ideas?
Attachments:
IMAQ1394 Error.doc ‏25 KB

Hi Brian,
Can you run Snap.vi (example program that ships with the 1394
driver)? If Snap.vi will run then we know that the driver and
LabVIEW are not corrupt and the problem lies with the source VI you are
using to make your .exe. If Snap.vi will not run then it must be
a corruption of the driver or LabVIEW. You indicated that you had
reinstalled the driver. Did you uninstall the driver first?
If not, then uninstall the driver and reinstall. There is a
possibility that the call library node primitive could be corrupt
(located in the IMAQ 1394 init.vi). If this is the case we might
have to uninstall/reinstall LabVIEW but I would like to do this as a
last resort. Test the functionality of the call library node
first. You can do this very easily if you have any other NI
hardware that you are controlling through LabVIEW. Typically the
API will use a call library node to make a call to the driver
.dll. This is what's happening with the IMAQ 1394 init.vi.
If you can control other NI hardware through LabVIEW then we know that
the call library nodes are working properly. If none of these
suggestions help you find the source of the problem, please post your
simplified VI and I will take a look at it.
Regards,
Brooks W.
National Instruments

LabView - Agilent 34970A initializer error

i am using LabView 6i connect with GPIB-PCII (ISA) to Agilent 34970A
i downloaded VISA software and use it to control my device. However,
the initializer for the 34970A sent an error message "old visa occur
with my device". LabView can still run, but didn't trigger the device
to start taking measurement.
the error message number is 107380743
i would be appricated if anyone can help on this issue

Here's a copy of my modifed VI.
Attachments:
HP34970A_Initialize.vi ‏113 KB

Id like to be able to initialize my 7344 Motion Controller card from within Labview and not through motion and automation explorer

Every time I boot my PC , I have to reinitialize my 7344 through Motion and Automation Explorer in order for it to work. Does anyone have any suggestions as to how to initialize it from within labview itself?
thanks

Hi,
I am sending you a Vi for initializing the controller.The only thing you have to do is that you need to use sequence structure. In the first sequence you need to use the VI which is attached i.e 0 (default). Then the next sequence will be the program itself.
So that as soon as you run your vi the first thing done will be initialising controller using LabVIEW. Then your program will run.
Here the led in the front panel will glow green only the first time you are initializing.The next time it will be dim but no doubt your initializing will be taking place.Hope this vi solves your problem.
Thxs
Manish Karnik
Application Engineer
Cruiser Controls
Mumbai, India.
Attachments:
Initializing controller.vi ‏42 KB

I uninstalled LabVIEW 6.1 from a Windows 2000 computer and now when I run DOS programs I get a pop-up error, "gpib-vdd.dll, An installable Virtual Device Driver failed Dll initialization". How do I correct this?

Occurs when running Edit.com for example. Error has choice to Close application or Ignore. If Ignore is chosen, application appears to run normally. Running repair of Windows 2000 does not correct the problem.

I'm glad you found it. Don't worry about the post. It's always good to check the KBs first, but we can't help it if we miss one sometime! The forum is definitely helpful though so don't feel hesitant to use it in the future. Good luck with the programming!
J.R. Allen

"Hi,I'm having problems controlling the Agilent E4422B Signal Generator with Labview. When using the Labview driver functions such as initialize instrument I always get an Error -1074135040.

I can query the device through the measurement and automation tool. I can also Identify the instrument by issuing a *IDN? with VISA write and read. Why do I get this error while using the drivers supplied by NI for this equipment? Any Ideas?

Hi, Brooks.
Attached please find the files containing all the information concerning my attempt to control the Agilent E4438C. Hope you can make sense of it and help me.
Regards
isaac
Attachments:
nireport.txt ‏2 KB
Capture.spy ‏5 KB
CaptureSpy.doc ‏117 KB

WinXP, LabView 6.1 Installation error message: 'Failed to initialize installer. Error 110.'

I am using WinXP and have no virus protection software installed. I have already tried installing instmsiw.exe, which didn't help. I also tried restarting in safe mode, starting and cancelling the install process, and restarting in normal mode, as per a suggestion I found, to no avail. Any other suggestions?

Hi,
Some steps you can take to check if it is the CD or your system would be:
1) Copy cd down to hard drive and try to install from there
2) Try installing from cd on another machine
3) Try another CD (if you have one)
If you run into the situation where it works on another machine, but doesn't work when copying down to your hard drive, I would then further try sharing the cd-rom drive of another machine temporarily and then accessing the cd from the network, or just copy it down into another machine and share it across the network. If this does not resolve your installation problem, the issue may be related to some corruption in your system install or possibly any permission issues. Lastly, if you cannot get the cd to work anywhere, I would co
ntact your local sales representative to see if you can get a new copy of the cd.
Jeremy L.
National Instruments
Jeremy L.
National Instruments

How to run downloaded drivers on Fresh Install of Labview 6.1 on a Mac G4 OS 9

I have just completed a fresh install of Labview 6.1 on an Macintosh G4 running OS9. I can run it and it seems to work just fine. I downloaded some drivers for an oscilloscope (HP 546XX) to run with an HP 54603b. When I installed, I went to open the 'Get Started.VI' I get a freeze and have to force quit out of labview. I am not sure how to resolve this. I am pretty sure that it is independent of the device, since I can open the vi's at least on another computer with no hardware attached. So I guess to boil my situation down. I have 2 questions:
-How do I get a fresh install on a mac G4 OS 9 to run downloaded drivers from the internet
-How do I ensure that I have the hardware configured on
a macintosh to run properly.
I really have little experience with macs so I am not really sure what my options are or what could be the problem so any assistance would be much appreciated.

Hmmm. I wonder if NI-VISA isn't installed correctly on this machine.
When LabVIEW loads a VI that uses a VISA name control on the front panel, it queries VISA for the installed devices. Sometimes this takes a few seconds, but maybe in your case, something has been corrupted and it's hanging.
To try to narrow this down, first run the separate program "VISAConfig". This should list your devices. If this works, this means it's pretty likely that VISA is installed correctly.
Next, run LabVIEW. On an empty front panel, select the "Controls->I/O->VISA Resource Name" and place it on the front panel. When you click on the arrow on this control, you should see a list of your devices. If this works, then that indicates that LabVIEW is successfully talking
to the VISA software.
If both of those succeeded, then we have to take a closer look at this particular instrument driver. Can you drop other VIs (say, Initialize or Close) without hanging?
If either of the first two steps fail, I'd suggest that you reinstall the VISA software. You may want to try the latest version of NI-VISA (from ni.com), but first confirm that it supports LabVIEW 6.1.
I hope this helps.
Brian

APPCrash on initialization of Labview

Similar Messages

Maybe you are looking for