LabView Continuously Crashing

[Gryffin]

Hello all,

I have a complicated program which was seemingly working fine several days ago, however, it now crashes the entire LabView environment quite frequently. I have attached an error dump from LabView (2015, 32-bit).

Can anyone provide any insight as to what the problem might be?

[Jacobson-ni]

The lvlog calls out several fatal insanities which you probably want to address.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P9QYSA0&l=en-US

https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-03-08-2010/td-p/1086373

[Gryffin]

I am not very familiar with the lvlog.txt file and how to address the fatal insanities. Could you give me an example from my lvlog.txt provided and any clues as to what could be the source?

As an example:

DWarn 0x613A5C04: Fatal insanity (0x00000008) detected in'Critical-Current-2016.vi: Main Application Instance'
e:\builds\penguin\labview\branches\2015\dev\source\panel\fpsane.cpp(1136) : DWarn 0x613A5C04: Fatal insanity (0x00000008) detected in'Critical-Current-2016.vi: Main Application Instance'
minidump id: 6125c79e-6dce-4695-8a12-d1a4ad8dbc5a
$Id: //labview/branches/2015/dev/source/panel/fpsane.cpp#3 $

</DEBUG_OUTPUT>
0x0069672C - LabVIEW <unknown> + 0
0x10015124 - mgcore_SH_15_0 <unknown> + 0
0x00BF8D4D - LabVIEW <unknown> + 0
0x00BFE364 - LabVIEW <unknown> + 0
0x00BFE6AA - LabVIEW <unknown> + 0
0x00DFEAD8 - LabVIEW <unknown> + 0
0x01048297 - LabVIEW <unknown> + 0
0x0113E552 - LabVIEW <unknown> + 0
0x01148433 - LabVIEW <unknown> + 0
0x01149FC3 - LabVIEW <unknown> + 0
0x0114A9AA - LabVIEW <unknown> + 0
0x0114ACFA - LabVIEW <unknown> + 0
0x01833DDD - LabVIEW <unknown> + 0
0x01833EEB - LabVIEW <unknown> + 0
0x017C1168 - LabVIEW <unknown> + 0
0x00A762E7 - LabVIEW <unknown> + 0
0x00A7664B - LabVIEW <unknown> + 0
0x00A76A33 - LabVIEW <unknown> + 0
0x01E51509 - LabVIEW <unknown> + 0
0x01EF7B15 - LabVIEW <unknown> + 0
0x01E45B0C - LabVIEW <unknown> + 0
0x01E71E18 - LabVIEW <unknown> + 0
0x01EF70B4 - LabVIEW <unknown> + 0
0x01E71021 - LabVIEW <unknown> + 0
0x0044C2E9 - LabVIEW <unknown> + 0
0x0044C67F - LabVIEW <unknown> + 0
0x0044C6F0 - LabVIEW <unknown> + 0
0x0204ACD1 - LabVIEW <unknown> + 0
0x0044BF13 - LabVIEW <unknown> + 0
0x773E0419 - KERNEL32 <unknown> + 0
0x77A1662D - ntdll <unknown> + 0
0x77A165FD - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00400000 ***
#** Saving: "C:\LabView VIs\LV 2015 Files\LV Ic & RRR Program Files\Critical-Current-Programs-2016\Critical-Current-2016.vi"
*** End Dump ***
Last sanity check for the VI took 64ms.
Insane object heap info:

flags = 0x10000
owner = 0x19F94240
0001:inTerm, 0002:invalR, 0004:invalD,   0008:sel,     0010:selR, 0020:selD
0100:loose,  0200:onPath, 1000:stretchH, 2000:stretchV,
joint count=13, logical size=387514416
    [ 1]: upStreamJt= 0, link=0x000001, flags=0x0003 hv=( -19, 286) uldr=[ 0, 0, 0, 2]
    [ 2]: upStreamJt= 1, link=0x000002, flags=0x0004 hv=(  37, 286) uldr=[ 0, 1, 3, 0]
    [ 3]: upStreamJt= 2, link=0x000003, flags=0x0002 hv=(  37, 293) uldr=[ 2, 0, 0, 4]
    [ 4]: upStreamJt= 3, link=0x000004, flags=0x0002 hv=(  58, 293) uldr=[ 5, 3, 0, 7]
    [ 5]: upStreamJt= 4, link=0x000005, flags=0x0006 hv=(  58, 250) uldr=[ 0, 0, 4, 6]
    [ 6]: upStreamJt= 5, link=0x000006, flags=0x0001 hv=(  88, 250) uldr=[ 0, 5, 0, 0]
    [ 7]: upStreamJt= 4, link=0x000007, flags=0x0002 hv=( 161, 293) uldr=[ 8, 4, 0,12]
    [ 8]: upStreamJt= 7, link=0x000008, flags=0x0004 hv=( 161, 206) uldr=[ 0, 9, 7, 0]
    [ 9]: upStreamJt= 8, link=0x000009, flags=0x0002 hv=( 104, 206) uldr=[10, 0, 0, 8]
    [10]: upStreamJt= 9, link=0x00000A, flags=0x0004 hv=( 104, 146) uldr=[ 0,11, 9, 0]
    [11]: upStreamJt=10, link=0x00000B, flags=0x1003 hv=(  91, 146) uldr=[ 0, 0, 0,10]
    [12]: upStreamJt= 7, link=0x00000C, flags=0x0001 hv=( 226, 293) uldr=[ 0, 7, 0, 0]

[altenbach · Accepted solution]

Some additional comments:

• Can you define "complicated"? Do you have an example? (Is this one gigantic monolithic toplevel VI?)
• You are running patchlevel 15.0.1f3, but there are upgrades (I am running 15.0.1f10). Might be worth updating.
• Can you define "quite frequently" (Immediately after loading? Always? Sometimes? After making code changes? When trying to run?, etc.)

[Gryffin]

---

@altenbach wrote:

Some additional comments:

• Can you define "complicated"? Do you have an example? (Is this one gigantic monolithic toplevel VI?)
• You are running patchlevel 15.0.1f3, but there are upgrades (I am running 15.0.1f10). Might be worth updating.
• Can you define "quite frequently" (Immediately after loading? Always? Sometimes? After making code changes? When trying to run?, etc.)

---

• A very old, gigantic, monolithic VI, with many subVIs, but not arranged in a project. (More so difficult to read than complicated)

• I am attempting to convince them to bring it up to LV2019, but I will also attempt to update 2015 as much as possible to see if that alleviates it.

• Apparently the crash only occurs when using the measurement portion of the program. When a measurement is attempted, it apparently crashes within ~5 minutes.

Also, I was following advice given in an earlier post to use the heap peak tool, and when I was looking through information in the heap peak tool, LabView crashed.

[altenbach]

---

@Gryffin wrote:
Apparently the crash only occurs when using the measurement portion of the program. When a measurement is attempted, it apparently crashes within ~5 minutes.

This potentially hints at some driver issue? Did anything change since the last time it was running successfully?

Does it use DAQmx? Was that upgraded? Does it use any third party drivers/DLLs that could have changed?

(I always thought insanities are edit/compile time issues, typically not encountered at run time, but what do I know? ;))

[Gryffin]

I updated LV2015 as much as I could and the errors went away. Not sure what the cause was but thanks for the suggestions.