Failure : "resource.cpp", line 2477

When building an application on LABVIEW 6.1 on Window 98, I get the error message:"Failure : "resource.cpp", line 2477". Attached is my Labview failure log file
Attachments:
LabVIEW_Failure_Log.txt ‏1 KB

Hi Kluu,
This error appears when checking the "Do not compress target file" option when building an application. The workaround is to not check that option in Application Builder.
While in the application builder, in the "Target" tab, in "Build Options", do NOT check the "Do not Compress Target File" option.
We are currently looking into this and will soon be fixing it up.
Hope this helps.
Regards,
Pravin Borade
Applications Engineer, National Instruments

Similar Messages

Labview version 6.1 failure:"linker.cpp", line 2302

I have the labview version 6.1 failure:"linker.cpp", line 2302 fault.
Does any one can help me please ?
Solved!
Go to Solution.

Actually HeapPeak existed as far back as LabVIEW 4 or maybe even 3. However it is not usually helpful for linker errors as that is something in the LabVIEW compiler itself. HeapPeak can be sort of useful for Insane errors to locate the element that the compiler considers insane (and consequently delete and/or rewire it).
If this is a recent error on a VI that used to work before, it is most likely related to a corruption to the VI and the best course of action is to replace the VI from a backup (source code revision control would be a great advantage here). If it is something where no previous (working) state is known about, then it is going to be a tough cookie. This version is 14 years old and eventhough I still have some installation of that version somewhere it is several years ago that I started that up for more than some accidential reasons. I'm pretty sure NI would need to do some archeological work nowadays to come up with a system they could use to replicate such an error and the OP would need to be a pretty high profile customer that they would go through that sort of effort.
Maybe it is related to this error. It is the closest available in the publically accessible list of errors. A complete recompile of the entire source code tree is definitely one of the first actions to try. It may fix the problem or run into even more errors that could maybe point into a more specific location. Upgrading to a more recent LabVIEW version is another possibility although hampererd by the fact that the currently shipping version isn't officially supporting XP anymore and that the Vision software is one piece of software that underwent serious changes in the course of time and an update from 6.1 to the most recent version is most likely not a seamless operation.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Failure : "load.cpp", line 4081

My main front panel VI will no longer open and I just get the error, Failure : "load.cpp", line 4081.
I am running an Eval version of 6.0.1 and was deciding whether to buy this product for a new project.
Given that I see from this forum that this error has been known for 9 months plus and I've lost a weeks
work I am not so sure.
It occured after I added some tab controls to the front panel, so beware.

Hi RCT,
This error occurs in LV 6.0.1. It seems that it is fixed in LV 6.0.2 and LV 6.1.
One thing you can do is ask NI to delete the insane objects for you. You have to redo your work you have done since the time the VI was correct until it got corrupt.
The other thing you can do is use a copy from a backup and redo the rest of the work.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Failure: "might.cpp" line 815 on LabVIEW executable

Hi,
I have a program written in LabVIEW 6.1 on a Windows XP platform. The program includes an ActiveX container that shows an Internet Explorer content window (just like the "Using the Microsoft Web Browser ActiveX Control" example found on http://sine.ni.com/apps/we/niepd_web_display.DISPLAY_EPD4?p_guid=B123AE0CB9BF111EE034080020E74861&p_node=DZ52051&p_submitted=N&p_rank=&p_answer=&p_source=External
, but without the activex queue in that example).
After I built the executable, I was able to run the exectuable on the development machine without problem. However when my client runs it on his PC with LabVIEW runtime engine 6.1 installed, he gets the message:
Failure: "might.cpp" line 815
For assistance in reso
lving this problem, please record the procedeing information and navigate to www.ni.com/failure or contact national insturments.
I cannot find any information on might.cpp on the NI support site. Any idea of what can be done to fix this problem?
Thanks!
Dan

Hi dan,
you must contact NI support sending them the problem. "might.cpp" is a source module of LV and they can investigate the error.
Another thing you have to take into account is that LV stores the class ID and not the application. Has the client PC the same MS IE version installed? If not, the error could also result from different versions of the Active-X control.
As with the reporting Toolkit for MS Office you have to build a different version of your app for each different version of the control.
Waldemar
Waldemar
Using 7.1.1, 8.5.1, 8.6.1, 2009 on XP and RT
Don't forget to give Kudos to good answers and/or questions

Failure: scalesup.cpp line 767

Hi,
My vi is crashing and giving me the error message:
Failure: scalesup.cpp line 767
I have isolated the problem, and it occurs at a waveform graph property node. I have the property node set for Xscale.Markervals[ ] . I'm trying to create a set of custom markers by sending a 1D dbl array to the property node. This custom marker array is the same length as the data array (600 points).
Thanks for your help in advance.

Are you using a logrithmic scale? If so, then make sure that the value of one of the markers is not zero.
If not, then what version of LabVIEW are you running? Can you take your data and create a simple VI that das that data aas the default in an array and then plots it to a graph and then does the property node? This should be pretty easy to set up so that we can reproduce this issue.
Also, bug reports such as this one are normally handled better in an e-mail or phone support request.
Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask

Failure window.cpp line 2039

Developed LV 5.1.1-Applications on Win NT4.0. Now i need to run them on WIN 2000 Systems but receive only errors while starting :
window.c line 2019 (by starting my Application.exe)
window.cpp line 2039 (by starting the LV Development system on the WIN 2000 PC)
Until now I`ve tried two WIN 2000 PC`s, different graphic drivers and graphic settings,
w/wo additional PCI-GPIB cards -> no result
Even the LV 6.0 student edition shows this error after installing on Win 2000
Any idea will be welcome
Best Regards
Markus

MarkusM wrote:
>
> Developed LV 5.1.1-Applications on Win NT4.0. Now i need to run them
> on WIN 2000 Systems but receive only errors while starting :
> window.c line 2019 (by starting my Application.exe)
> window.cpp line 2039 (by starting the LV Development system on the WIN
> 2000 PC)
> Until now I`ve tried two WIN 2000 PC`s, different graphic drivers and
> graphic settings,
> w/wo additional PCI-GPIB cards -> no result
> Even the LV 6.0 student edition shows this error after installing on
> Win 2000
> Any idea will be welcome
> Best Regards
> Markus
Does www.ni.com/failure help?
Mark

Failure load.cpp line 4835 VI runs ok in 6i will not load in 6.1

I have created a rather complex instrument interface in 6i and it works fine. I have recently upgraded to 6.1 professional; the VI will not load and an internal failure occurs in load.cpp on line 4835. Is this a bug, or did I do something incorrect? I tried to do a mass compile, but this fails also. The load seems to have problems with a specific VI, so I removed this VI and was able to load by cancelling attempts to locate. I have tried to re-link the problem VI, rebuild the problem VI in 6.1, modify the diagram so that the problem VI is not used/referenced; none of these worked. Labview generally would crash when I save after making the aforementioned modifications. Note: the problem VIs consist of a globa
l variable, and a case VI that uses the same global variable.
I hope that this information is complete enough to point to a solution. Thank You,
Howard Havlicsek, Acutronic

This is typically a result of having more than 555 controls/indicators on
a front panel. A workaround is to place controls/indicators into clusters
since each cluster only counts as a single UI object. Do this until you
get below the 555 limit. A better ideal in most cases is that you don't
need that many indicators on the front panel where a user has to try and
figure out what he should be looking at. If they are not used often move
them into subVIs and display the subVI front panels as needed.
If this doesn't appear to be the cause of your load.cpp error I would
contact NI tech support at ni.com/ask.
Marcus Monroe

Failure "save.cpp", line 1427

i have this failure when i build an application
any ideas to solve it?? and to explain it

Hello sanaa,
I use LV6.1 with windows XP.
The different devices are SMT02, audio analyzer UPA, Power Supply NGSM32/10 from Rohde &Schwarz.
I tried to build it with another PC but it is the same configuration. It is difficult to change the OS beacause I would have to make a lot of modificatio on my application (Excel..)
Thank you very much
hors

Failure "linker.cpp", line 2302

How to solve this problem?

Hi Sasha 1,
Yes, you will first have to uninstall NI-DAQ that was shipped with LabVIEW. Make sure you have no reference to NI-DAQ on your system. You will then want to install NI-DAQ 6.1 on your system (which is the last driver to support your board).
What probably happened was that you installed NI-DAQ 6.1 over NI-DAQ 6.9.2 and the problem is that the LabVIEW VIs for DAQ still referenced the old driver. Therefore when LabVIEW tried to call them at run-time, you got the linker error since the driver no longer existed on the system.
You might have to go through a couple steps to clear things correctly. You might have to uninstall NI-DAQ 6.1, reinstall NI-DAQ 6.9.2 and then uninstall NI-DAQ 6.9.2 (remove reference from LabVIEW) and th
en reinstall 6.1.
It might simply be easier to remove all NI software on your system by uninstalling it from Add/Remove Programs and then reinstalling LabVIEW without the DAQ driver and then install the NI-DAQ 6.1 driver.
Anyway, hope that helps. Have a good day.
Ron
Applications Engineering
National Instruments

Failure: "Datatype.cpp", line 614

How to overcome this error?

I have the same Error. See Attachement Log File.
If anyone could help me.
many thanks,
Attachments:
lvlog08-05-04-17-13-46.txt ‏1 KB

Error 38 "thread.cpp line 1938" failure during an application execution

I made a Labview6.1 based application that handle serial communication with six RS-232 ports. The program is intended to run 24 hours a day. After around 2 days of execution an error occurs. Here the reference:
Error 38
thread.cpp line 1938
What can be the root cause of this failure?
I'm pretty sure it's not lack of memory/CPU.

Hi Mao,
Be sure that all the threads you oppened are all closed.
For example if you put an "open VI reference" don't forget to put the "close reference" at the end of the task.
Hope it helps!
Best regards,
G Liagre
Best regards,
G Liagre

Failure : load.cpp in line 4081

I'm working in a new application demo. Yesterday i saved it normally, but today when i tried to open gives me this failure message:
"Failure : load.cpp in line 4081"
I need to recover the file, because i don´t have any backups.
Thank you in advance, regards.
Fede

On Tue, 12 Nov 2002 12:58:08 -0600 (CST), Fede2002 wrote:
>I'm working in a new application demo. Yesterday i saved it normally,
>but today when i tried to open gives me this failure message:
>"Failure : load.cpp in line 4081"
>
>I need to recover the file, because i don=B4t have any backups.
>
I had the same error changing video resolution (developed both in
1280x1024 and 1024x768).
The error has gone returning to the higher resolution.
Try It & let us know! :-)
Bye!
http:\\www.depquest.net

SQL Server Assertion: File: "logmgr.cpp" , line=5512

Hi All,
We are using Sql Server 2005 Express ,
we got the below exception of Sql Server Assertion
2014-11-17 00:26:12.59 spid51 Error: 17066, Severity: 16, State: 1.
2014-11-17 00:26:12.59 spid51 SQL Server Assertion: File: <"logmgr.cpp">, line=5512 Failed Assertion = '!(minLSN.m_fSeqNo < lfcb->lfcb_fSeqNo)'. This error may be timing-related. If the error persists after rerunning
the statement, use DBCC CHECKDB to check the database for structural integrity, or restart the server to ensure in-memory data structures are not corrupted.
2014-11-17 00:26:12.61 spid51 Error: 3624, Severity: 20, State: 1.
2014-11-17 00:26:12.61 spid51 A system assertion check has failed. Check the SQL Server error log for details. Typically, an assertion failure is caused by a software bug or data corruption. To check for database corruption, consider running
DBCC CHECKDB. If you agreed to send dumps to Microsoft during setup, a mini dump will be sent to Microsoft. An update might be available from Microsoft in the latest Service Pack or in a QFE from Technical Support.
2014-11-17 00:27:34.81 Server Using 'dbghelp.dll' version '4.0.5'
2014-11-17 00:27:34.81 Server ***Unable to get thread context - no pss
2014-11-17 00:27:34.81 Server * *******************************************************************************
2014-11-17 00:27:34.81 Server *
2014-11-17 00:27:34.81 Server * BEGIN STACK DUMP:
2014-11-17 00:27:34.81 Server * 11/17/14 00:27:34 spid 0
2014-11-17 00:27:34.81 Server *
2014-11-17 00:27:34.81 Server * Non-yielding Scheduler
2014-11-17 00:27:34.81 Server *
2014-11-17 00:27:34.81 Server * *******************************************************************************
2014-11-17 00:27:34.81 Server Stack Signature for the dump is 0x000003E6
2014-11-17 00:27:35.75 Server External dump process return code 0x20000001.
External dump process returned no errors.
2014-11-17 00:27:35.75 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
99%. Interval: 75000 ms.
2014-11-17 00:28:35.77 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
98%. Interval: 135953 ms.
2014-11-17 00:29:35.77 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
98%. Interval: 195953 ms.
2014-11-17 00:30:35.77 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
98%. Interval: 255953 ms.
2014-11-17 00:31:35.77 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
98%. Interval: 315953 ms.
2014-11-17 00:32:35.77 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
98%. Interval: 375953 ms.
2014-11-17 00:33:35.77 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
98%. Interval: 435953 ms.
2014-11-17 00:34:35.77 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
98%. Interval: 495953 ms.
2014-11-17 00:35:05.77 Server The time stamp counter of CPU on scheduler id 1 is not synchronized with other CPUs.
2014-11-17 00:35:35.77 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
98%. Interval: 555953 ms.
2014-11-17 00:36:35.77 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
97%. Interval: 615953 ms.
2014-11-17 00:37:35.77 Server Process 51:0:0 (0x1574) Worker 0x20AA00E8 appears to be non-yielding on Scheduler 0. Thread creation time: 13059477540625. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle
98%. Interval: 675953 ms.

Assertion error are usually some corruption in SQL Server database. And non yielding scheduler seems like bug what is output of
select @@Version
Did you tried running dbcc checkdb on SQL Server 2005 database
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
My Technet Wiki Article
MVP

Lv crashes every 10 days, "plotsupp.cpp, line 1330"

This vi continually writes to a buffer and displays on a waveform chart. Upon a trigger signal, a predefined amount of data (in the buffer) is written to a file and the vi ends. Labview is crashing every 10 days with failure message "plotsupp.cpp, line 1330". Mac G-4, OS 9, LabVIEW 6.1, 6031 I/O Card, 38 channels of data.

Hello �
What happens every 10 days? Does the program get to the same specific point after 10 days of running? What does that specific part of the program do? Does the user have interaction with the VI or is it running by itself?
The only report of this error crash we have is when the user tried to modify the labels in a control. Somehow the control got corrupted and the problem was fixed by replacing the controls in the front panel with new ones.
If this does not help, you can narrow the problem down and post a simple VI so that we can reproduce the issue.
S Vences
Applications Engineer
National Instruments

Error #3, "memory.cpp", line 865(V6.0) 876(V6.0.2)

I used a VI one day with no problems, and the next I got this message - "Error #3, "memory.cpp", line 865" I did not even close the VI or modify it an anyway.
I was first running Labview V6.0 and tried upgrading to V6.0.2 but the error continued (now on line 876). I also tried recompiling and backup copies of the VI and SubVIs, which did not work either. A suggested fix is to delete "dir.mnu", which likewise did nothing.
To me it looks like the problem rests in the Labview "Copy" command, which I use to copy a file to another directory, because when I delete it it works fine again.
Any suggestions would be greatly appreciated!

Hello,
It seems that while copying your file, memory is filling up too quickly for LabVIEW to clean it up and it's crashing LabVIEW. View the memory usage in the Task Manager to confirm this.
LabVIEW Internal Errors (Failure in XXX.c / XXX.cpp at line YYY)
If the Copy function is not the cause of the error, about 95% of the time, the next step is to look for DLL nodes or CIN nodes. The likely culprit is that a string or array is being handed to the C code, which either overwrites memory, or leaves the array/string data structure to an inconsistent state leading LV to overwrite memory. Anyway, this is a very common cause.
If you eliminate that possib
ility, the remainder are usually some sort of corruption saved in the VI, but normally those will not even load.
To simplify it before submitting it to support, please try executing individual subVIs and see if the problem is limited to a particular VI or a smaller set of VIs.
Zvezdana S.

Failure : "resource.cpp", line 2477

Similar Messages

Maybe you are looking for