Labview 7 crashes when a vi containing a dll is closed

Dear All,
I've written a dll in C language to use a USB dongle. Before making my
C code into a dll, I throughly tested it as a console application,
using Borland C++.
In Labview, I call my dll, using the call library function node. The
first time I run my program, it does what I expect with the dll. If I
try to run it again, it doesn't work. I found a program on the
internet, called listdll, which displays the dlls that are currently
loaded in memory. The dll that I wrote as well as the other dlls that
this function uses (loaded statically), appear in the list.
To get my program to run properly once again, I need to shut down
labview and open it up again. However when I shut down Labview, I get a
Labview-Application Error message, that says that the instruction at
"0x06b323d1" referenced memory at "0x06b323d1". The memory could not be
"read".
How can I possibly get around this problem and how can I run my program
several times without shutting Labview down in the meantime?
My Labview program was written in Labview 7, but if needed be, I've
also access to LAbview 8.
Thanks in advance for your help,
Regards,
Alan

Hi Alan,
LabVIEW pre-allocates memory for calls to DLL's, if the DLL's goes over the memory allocation this can cause problems such as a LabVIEW crash. Are any of the parameters arrays or strings?
Regards
Jon B
Applications Engineer
NI UK & Ireland

Similar Messages

Labview 8 crashes when saving a vi with a 'Bundle By Name' function

We have a working vi (Get_AN_Fast.vi), created with Labview 7.1.
Trying to open this vi with Labview 8 crashes Labview.
Problem seems to be related to a 'Bundle by Name' function, but it is not that simple as using this function by itself wirks fine.
Any ideas would be a help.
Attachments:
Labview_Upgrade_Crash.zip ‏117 KB

Sorry for the delay, I have been testing on other machines.
We can reproduce the error on other machines, with completly fresh installs of Labview 8.
The ActiveX Object we are connecting to is our own COM server, for interfacing to USB based data acquisition devices.
I have found that when our COM server is not installed on a computer, then the VI will open, but with errors related the the missing COM Server.
When the COM Server is installed, Labview 8 crashes when opening the vi.
I realise that our COM server might have bugs, but it worked fine with Labview 6 and 7, and it is Labview 8 that gives the error, not our COM Server (which is a stand-alone executable).
I have attached a zip file with our COM server, it just needs to be unzipped to a temporary file, and then run the 'register.bat' file to register the server.
It will not install any other files on your computer and, can just be deleted when you are finished.
Thanks
Charlie.
Attachments:
COM_Server.zip ‏659 KB
Labview_Upgrade_Crash.zip ‏117 KB

Labview 7 crashes when opening an earlier Labview version VI

Hello guys. I am using Labview 7 professional edition. The labview crashes when opening an earlier labview version VI. The error message I'm getting is just "Labview has encounted a problem and eneds to close. We are sorry for the inconvenience." The VI contains a few Tag SubVIs, and It is written with an earlier version of Labview(BridgeView is what it was called).
Do anyone have any ideas that how I can fix this bug? It's going to be a great help. Thank you very much.

Hello,
LabVIEW should not be crashing in this situation. Now, does this happen for other similar VIs too? It could be possible that a particular VI is corrupt. Also could you post your VI here so that I can try and reproduce the problem at my end.
Regards,
Chetan K
Application Engineering
National Instruments

LabVIEW is crashing when i am trying to build the exe

I am trying to build an executable from a program in which i am communicating with several instruments, whenever i am trying to build an exe labview is crashing and i am getting the error Exception: access violation(0xc0000005)at eip=0x10054DD1.
after reading some posts on forum i tried builduing an exe on other system also, but still i am getting the same error.
below i am attaching the program and the image of the error i am getting.
Attachments:
labview crash.png ‏53 KB
automation.zip ‏4455 KB

Ritu wrote:
waiting for the reply....
Realize this community is by a large majority volunteer based. If you need urgent support contact NI directly
http://sine.ni.com/apps/utf8/nicc.call_me?loc=en-US
That being said I would try to disable the large amount of code. Say you have a Main that launches a bunch of stuff, put a disabled diagram code around the launching part and then try to rebuild. It is a very slow process (especially when the build takes a while to fail) but by doing this you can more isolate the parts of the code that can cause the crash. The only time I've seen a crash on build like you described, I simply rebooted and it was fine. Usually because of my own fault by stopping code in a bad way previously leaving things in memory.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

Labview 2013 crashing when restarting VI

My VI runs and I have no problems.
If I stop then Vi and re-run it, pretty much every second time it crashes. It does not point to anything and the only message I get is:
Problem signature:
Problem Event Name: APPCRASH
Application Name: LabVIEW.exe
Application Version: 13.0.0.4051
Application Timestamp: 525595c6
Fault Module Name: NiViPxi.dll
Fault Module Version: 5.4.0.49152
Fault Module Timestamp: 51c243ad
Exception Code: c0000005
Exception Offset: 0000bbe0
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 6153
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
This only clue in the above I can find is NiViPxi.dll
I am using a PXI rack so maybe it is to do with one of the devices?
I would be nice to have more clues, does anyone know why labVIEW keeps crashing?
Rgds,
Sean
Solved!
Go to Solution.

Hi jinfone.t
I managed to root cause it to a netway 72 PXI dll and have fixed the issue, (took a lot of effort!)
- Does the crash only occur when you re run this particular VI that you are talking about?
Yes
- Is there any crash logs generated?
None that I know of apart from the output I pasted on the screen. It's possible there is something in the event monitor
- What does your VI do?
It function tests our product, (IOT)
- Would it be possible to show the code?
I'm afraid not as it is proprietary. However, the issue appears to be due to the dll. Netway may release the VIs but I believe you are required to buy hardware/ software.
The issue I have is that LabVIEW is not handling this crash well at all. It does not point to the problem dll nor does it drop a fail log that I know of.
Thanks for the feedback.
Ciao,
Sean

Premiere Pro 5.5.2 crashes when generating thumbnails; faults ImageRenderer.dll

Hello all! I'm a new Premiere user. I've been working on a review show, and it's been going great for the last month. A few days ago, however, Premiere Pro started acting wonky. Part of my show involves putting in small clips from other sources, typically 3-4 seconds. With this most recent show, Premiere Pro started crashing left and right without warning. It took me a few days to narrow down the source.
ImageRenderer.dll seems to be crashing when attempting to generate thumbnail images of the sourced clips. Everything else seems to work fine. It seemed to start when I used the Clip Speed / Duration function to slow down a 30fps clip to about 25% speed. I realized later that the clips were at 30fps in a 24fps timeline (the rest of my material is 24fps). Once I changed the clip's speed, Premiere started crashing, perhaps due to how the clip interacted with the timeline. I removed the offending clip, but it seemed that the damage was done. I discovered that if I deleted the source file from the project inventory pane Premiere wouldn't crash.
I just recently discovered that if I collapse the video track of the source clip, Premiere won't generate thumbnails for those clips and thus remains stable. I stress-tested my rig all day yesterday using MemTest86 and Prime95, with no errors. I also uninstalled Premiere Pro, rebooted, and reinstalled from scratch. I still get the ImageRenderer.dll crash when Premiere attempts to generate thumbnails for the clips. So far I do have a workaround (collapse the video track) but I would like to figure out a better solution for it. I even created a new project and re-sourced the clips into a different frame rate.
Any help would be appreciated!
~Josh
Log Name:
Application
Source:
Application Error
Date:
1/31/2014 9:39:50 AM
Event ID:
1000
Task Category: (100)
Level:
Error
Keywords:
Classic
User:
N/A
Computer:
Relic
Description:
Faulting application name: Adobe Premiere Pro.exe, version: 5.5.2.0, time stamp: 0x4e960e56
Faulting module name: ImageRenderer.dll, version: 5.5.2.0, time stamp: 0x4e95f50d
Exception code: 0xc0000005
Fault offset: 0x00000000001756df
Faulting process id: 0x850
Faulting application start time: 0x01cf1e9244d9c6a7
Faulting application path: C:\Program Files\Adobe\Adobe Premiere Pro CS5.5\Adobe Premiere Pro.exe
Faulting module path: C:\Program Files\Adobe\Adobe Premiere Pro CS5.5\ImageRenderer.dll
Report Id: 89880013-8a85-11e3-bef2-60a44c639d5c
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2014-01-31T14:39:50.000000000Z" />
<EventRecordID>4955</EventRecordID>
<Channel>Application</Channel>
<Computer>Relic</Computer>
<Security />
</System>
<EventData>
<Data>Adobe Premiere Pro.exe</Data>
<Data>5.5.2.0</Data>
<Data>4e960e56</Data>
<Data>ImageRenderer.dll</Data>
<Data>5.5.2.0</Data>
<Data>4e95f50d</Data>
<Data>c0000005</Data>
<Data>00000000001756df</Data>
<Data>850</Data>
<Data>01cf1e9244d9c6a7</Data>
<Data>C:\Program Files\Adobe\Adobe Premiere Pro CS5.5\Adobe Premiere Pro.exe</Data>
<Data>C:\Program Files\Adobe\Adobe Premiere Pro CS5.5\ImageRenderer.dll</Data>
<Data>89880013-8a85-11e3-bef2-60a44c639d5c</Data>
</EventData>
</Event>

Same problem - on MBPro 13-inch, Early 2011 running OS X Lion 10.7.4 (11E53)
Uninstalling 3ivx worked like a charm! thanks.

LabVIEW 2009 Crash when save for previous

I'm having a problem when trying to save a VI in LabVIEW 2009 to a previous version of LabVIEW, in this case 8.2, but itseems to crash no matter what version I choose. I've narrowed the problem down to this:
If the vi contains an event structure I get the following error: Fatal Internal Error: "MemoryManager.cpp", line 547
If I remove the event structure it saves fine. I'll even get the error if I create a blank vi, and drop an empty event structure on the diagram. No controls, no other code.
Is this a known problem? Is this a problem with my copy of LV? Is there a workaround? Removing the event structure in this application is not an option.
Thanks
Rob
Message Edited by rgough on 09-30-2009 03:58 PM
Solved!
Go to Solution.

Hi sk_LabVIEW,
Currently there is no workaround, but fixes are being worked on. Sorry.
Flash
National Instruments
Applications Engineer

LabVIEW 6i crashes when trying to "Print To HTML"

My application (not compiled as an executable, still in editor mode) crashes LabVIEW on run. I recieve the pop-up that an error log is being created. Contained in that log are the following sections:
Application exception occurred:
App: (pid=556)
When: 7/11/2002 @ 13:39:20.865
Exception number: c0000005 (access violation)
*----> Stack Back Trace <----*
FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name
0012F240 0071BB57 00000000 011D46E4 0012F360 0012F6D0 !LVSetDefaultPrinter
0012F364 0071843B 00000558 0012F6D0 011D28C0 011D28F0 !VIPrintPanelToPrinter
0012F6A4 00428040 0000021C 0012F6D0 011D28C0 011D28F0 !VIPrintPanelToPrinter
0012F81C 004273D0 00000001 011D3EF8
011D28C0 0012FA50 !VIRefFinishNativeCall
0012FB70 004259E4 00000000 00000001 00000007 02C0F774 !VIRefFinishNativeCall
0012FCA4 004719C6 ECB00000 000003EE 00000007 02C0F774 !KillLVObjAsyncRef
0012FDDC 00522C2B 02C0F800 00000001 02C0EB20 00000000 !CBRPrepareCall
0012FDF4 02C2187D 011D0278 00000000 00000006 00000001 !PrimPostEvt
02C0E800 00925E0C 011E6CA0 002FB510 011D4208 011D31D8
02D67C5C 0048EA10 0048EA50 02C25C82 02C25F9E 02C25F3F !
0048DF70 8B5310EC 8B560C5D 438B0875 FF335708 850FF03B !VINormalInitCProcsHelper
83EC8B55 00000000 00000000 00000000 00000000 00000000
The only printer related funciton in my application is "Print To HTML."

Although this does tend to point to the function where your application prints, I wouldn't trust the message.
What you need to do will be time consuming, but will be necessary to troubleshoot your application.
In iterative steps, perform the following:
Open your VI's diagram.
Place the VI in Highlight Execution Mode.
Run the main VI and watch the diagram in question for the node that causes the whole mess to crash.
Once you have isolated the node, unless it isn't a subVI, open the subVI, and repeat these steps until you find a node that isn't a subVI (a native function).
This will isolate your problem to the precise node that is causing the problem. From there, you can probably figure out what is going on, or either post the information here, o
r contact NI support (ni.com/ask).

Labview 8 crashes when using Read Labview Measurement File

Hi All,
I am a new user for Labview. I installed Labview 8.0 from the CD (evaluation copy). I was just testing the sample code provided by NI. I opened the "Load from File and Display" example and I was trying to open the properties for the Read Labview Measurement File component when Labview crashed. I tried it a couple of times and everytime it happens the same way (when I double click the component or right click on it).
I am using Windows XP with all the updates done. In the Windows crash report, the application version is 8.0.0.4005.
Other problem I encountered is a missing component on the Input Palette (no DAQ Assistant present) and the Instrument I/O Assistant raises the error "Measurement & Automation Explorer or the Instrument I/O Assistant is not installed correctly. Please install these from the Labview Driver CD". For the last problem, I will try to run the Labview Driver CD, once I get it. But I am not sure if the DAQ Assistant will show up then or not.
Any ideas?
Regards,
Nick

Hello Nick,
While it is not my area of expertise, I would expect the DAQ Assistant would appear after installing the driver CD as you said you would be trying.
What caught my attention was the crash. The easiest way to resolve the crash is to delete the instance of the Read LabVIEW Measurement File on the diagram and place a new one from the Express Input palette (now called "Read From Measurement File"). In that situation, I would expect just pressing OK to accept the default configuration should work. The crash occurs in certain circumstances when the Read / Write Measurement File Express VIs are dropped from a previous version of LabVIEW and then their config page is opened in 8.0.x. This issue should be resolved in a future release, sorry for the inconvenience.

LabVIEW 2010 crash when calling user32.dll

Interesting LabVIEW 2010 "feature" I discovered this morning.
Attached are two identical VIs, one saved in 2010 and one saved in 2009. These VIs were specifically written to demonstrate the bug I stumbled upon this afternoon. Each VI when run should allow you to find a specific program (window) open in Microsoft Windows and bring it to the foreground. It relies on "user32.dll" to perform this operation. It also allows you to specify the calling convention for the function call.
In LV 2009, either calling convention works, without error. However, in LV 2010 the calling convention for the function must be "stdcall (WINAPI)" and not the default "C". If the calling convention is "C" then LabVIEW crashes and closes without warning.
If you happen to have both LV 2009 and LV 2010 on your computer, I would love to hear if this phenomenon is duplicated so that I can pinpoint whether the bug is LV 2010 related or is more specific to my personal setup.
Thanks,
~David
Solved!
Go to Solution.
Attachments:
LV2010 test.vi ‏13 KB
LV2009 test.vi ‏14 KB

221113
Return
CLFN with the wrong calling convention may siliently crash LabVIEW.
LabVIEW 8.5 through 2009 could adjust the calling convention at run time if the user selected the wrong option. In 2010 this no longer happens. More information is found in KnowledgeBase 59KB14WI
Workaround: Use the correct calling convention
Reported Version: 2010 32-bit
Resolved Version: N/A
Added: 07/23/2010
From 2010 release notes.
Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA

Finder Crashing When Opening Folders Containing JPEG Images

Here's my odd problem.
Finder seems to work okay until I open folders with certain JPEG images in them. Specifically, it seems to crash whenever I open a folder that has images taken with my old Oregon Scientific camera. It gets a little bit annoying, because once I open the folder, Finder crashes... and then it re-launches, +with the problem window still open+... which causes it to crash immediately upon re-opening. And then it re-launches again, again with the same window open, which causes it to crash again, and on and on into the night.
Incidentally... these images also seem to crash Preview. I never had any problem with this before. They worked fine under 10.5, they worked fine under 10.4... they even work fine on OS9. I've tried turning off icon previews, I've tried list view and icon view and coverflow and all that, and it crashes every single time.
If I use GraphicConverter to re-save the images WITHOUT the EXIF data, then Finder seems to be okay. But considering I have nearly a thousand images that were taken with that (decidedly unsophisticated) camera, it's really an inconvenience to convert every single one. On top of it, I'd kind of like to keep my EXIF data where it is.
I'm really kind of starting to regret not waiting for 10.6.1 before installing, because I've encountered problem after problem... and my fiance's iMac is almost unusable, it's so buggy. Most of the issues I've encountered I can live with, at least long enough for Apple to release an update... but this Finder issue is killing me, because I can't even access my photos.
Anyone have this same issue, or some idea of how to fix it?

I've duplicated this behavior on both my MacBook and my fiance's iMac, which are both running 10.6. With my 10.4-enabled G4 and iMac G3, there's no problems.
I think I've at least figured out the actual cause. I just opened a folder of pictures taken with my Oregon Scientific DShot II camera, and it didn't crash the Finder, nor did it kill Preview. The EXIF data was intact. The difference was that with these images, I'd edited them and re-saved with GraphicConverter when I first took them.
After repeating the tests with some other pictures, I think that the problem isn't so much with the EXIF data as it is with the +preview image+. The DShot II camera saves some kind of a preview image (which isn't very good). When I edited these images with GraphicConverter, the application added it's own custom preview, overwriting the original.
For some reason, Finder (and Preview, though I don't know why) handle GraphicConverter's preview image, but can't seem to be able to deal with the preview image that the DS2 embedded into the image. Why this should change with 10.6, when all previous versions of the software worked perfectly fine, I have no idea.
AJH

LabVIEW 2010 crashes when changing representation of TypeDef

Hello NI,
I have to report a bug
which causes LV 2010 to crash with error in "datamgr.cpp", line 2720.
This crash is reproduceable.I use LabVIEw 2010, 32 bit on Windows 7.
To cause this crash you have to perform the
following steps (I attached a sample VI to reproduce these steps.):
Place a ring control on the FP, change
representation to I32
On the BD, create a property node “Strings
And Values[]”
The datatype of this property is Array of
Cluster with 2 Elems, “String” & “Value”, where “Value” is of type I32
Create a control of this property,
surprisingly the type of Value is “extended”
On the FP, select the cluster inside the
array, click “Customize Control…” from Edit- menu
In the Control- Editor change the DataType
of Value to I32, then exit the Control Editor without saving the control,
but replacing the original cluster
LabVIEW 2010 will crash with the error
message stated above
The problem is to change the
representation of the cluster element, where the cluster is part of a typedef. A
solution is to forbid to call the “Customize”- editor directly from the FP (not
nice) or to forbid to replace the orginal control, instead force the user to
save the altered control to a .ctl (nicer).
This shows a general problem with TypeDefs,
where the array of a not-typedefed cluster is typedefed. This was discussed
earlier with the cursor list of waveform graphs (couldn’t find it anymore, but
read it in this forum) where this problem also can occur. So this is an appeal
to National Instruments to change the TypeDef to the clusters and make arrays
of them.
And, after all, for me it is
unexpected behaviour that a constant / control / indicator, created from a
property (or any terminal / node I can find on the BD) has another datatype
than the original terminal or node.
Greets, Dave
Picture 1: Type of property node
Picture 2: Type of created control
Picture 3: Error message
Greets, Dave
Attachments:
Ring TypeDef Problem.vi ‏66 KB

Hi All,
I am also facing the same bug from the long time which causes loss of data unexpected.Please solve this bug and tell me any way to solve this.I am using Control Type Def in my project.
Thanks
Yogeshwar
Attachments:
error.jpg ‏19 KB

When one window containing 1 tab is closed, the other window with several tabs closes also

I have a set of web pages that reproducibly causes Firefox to act incorrectly. When Firefox is first started I click the "Restore previous desktop" button. Then I have 2 Firefox windows. The first to open has 6 tabs; the second has 1 tab. When I close the 2nd window (with 1 tab), it also closes Firefox completely with no error message. When I run Firefox again, "Restore" creates both windows exactly as they were before.
I don't know yet if the actual URLs make a difference, but here they are anyway:
'''''Window 1:'''''
https://www.google.com/accounts/ServiceLogin?service=mail&passive=true&rm=false&continue=https%3A%2F%2Fmail.google.com%2Fmail%2Fu%2F0%2F%3Fshva%3D1%26ui%3Dhtml%26zy%3Dl&bsv=llya694le36z&ss=1&scc=1&authuser=0&ltmpl=default&ltmplcache=2&from=login#inbox
http://branamsmile.com/gum/?gclid=CLepiIaAhqkCFVJ25QodSyk1nw
http://www.google.com/search?hl=&q=root+viewsonic+g+tablet&sourceid=navclient-ff&rlz=1B3GGLL_enUS412US412&ie=UTF-8&aq=0&oq=root+viewsoni
***** NOTE THIS TAB IS PROBLEMATIC *****
When I press Alt+D, Ctrl+C, and Ctrl+V it into this comment box, I get
'''woot'''
When I look at the actual contents of the web page being displayed, it is the verizon wireless rebate page:
'''www.verizonwireless.com/rebates'''
The page has definitely finished being rendered (the refresh icon is displayed after the url "woot"), but the URL does not match the page. The URL displayed is not even in its proper form (i.e., www.woot.com).
Remember that this page was RESTORED by Firefox from a previous session. It is as if I was on that tab at verizon, tried to go to woot.com by typing "woot" (which would of course bring up a search rather than the web page), DIDN'T PRESS ENTER, and Firefox is duplicating that entire sequence.
********* END PROBLEMATIC *************
chrome://foxtab/content/newTabMessage.html
https://www.bankofamerica.com/Control.do?page_msg=signoff&body=signoff
'''''Window 2:'''''
http://www.freewaregenius.com/2011/06/01/the-best-freeware-file-manager-a-comparative-analysis/
With this exact set of windows and tabs, as restored by Firefox in a brand new instance of it, double-clicking the red Firefox in the top left corner of the 2nd window causes both windows to close.
I wish I could save this configuration so I could always reproduce the error, but I need my computer :)

You can check for problems with the sessionstore.js and sessionstore.bak files in the Firefox Profile Folder that store session data.
Delete the sessionstore.js file and possible sessionstore-##.js files with a number and sessionstore.bak in the Firefox Profile Folder.
*Help > Troubleshooting Information > Profile Directory: Open Containing Folder
*http://kb.mozillazine.org/Profile_folder_-_Firefox
Deleting sessionstore.js will cause App Tabs and Tab Groups and open and closed (undo) tabs to get lost, so you will have to create them again (make a note or bookmark them).
*http://kb.mozillazine.org/Multiple_profile_files_created

CVI crashes when calling function from external DLL

I'm calling a CVI library from Test Stand 4.1. In that CVI library I load an external DLL (using LoadLibrary) and create a few function pointers (using GetProcAddress). The DLL loads successfully, and I get addresses for all of the imported functions.
However, when I one of the functions is called CVI crashes (Test Stand says it lost the ActiveX connection to CVI) when executing in an external CVI instance. If executed in the Test Stand process I get a system level exception.
If I step through the code in CVI, it hangs after trying to step into or over the call to the function pointer from the external DLL.
I am able to call the functions in a small test project I created in CVI, however when integrating it into an existing test library and calling it through Test Stand it fails.
Any ideas on how to go about debugging this issue?

Have you tried calling into the dll that CVI calls directly from TestStand? I am curious to know if this also crashes.
I am also curious to know if there are any path references in the dll that is called by the CVI program. If so are they relative, or absolute paths?
I ask because one of the possibilities is that relative paths are being used to specify a path from the location of the code that is called, and they are not working because the current working directory is being specified by TestStand, and the paths are not relative to the working directory given by TestStand.
Jensen
National Instruments
Applications Engineer

LabVIEW Crashes when Opening Project

Hey Guys,
I'm running into an interesting issue where LabVIEW crashes when opening a project. This is the second time I've run into this issue, on the same project. To get around it the first time I simply deleted and re-made my project, but since it's happened again, I need to figure out how to debug it. The symptom is that LabVIEW will crash when opening the project (sometimes I can see the "vi loading" screen) without any indication that crash has occured. It doesn't even launch the error reporter, the process just dies. Anyone know how I can go about debugging this?
Solved!
Go to Solution.

xkenneth86,
What version of LabVIEW? Have you ever had previous versions of LabVIEW on your computer? Can you attach a screenshot of the crash?
David H.
National Instruments

Labview 7 crashes when a vi containing a dll is closed

Similar Messages

Maybe you are looking for