Home Community Discussion Forums Most Active Software Boards LabVIEW Topic

LabVIEW

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

LV2017 built EXE crashes - Channels behave bad??

LV2017 built EXE crashes - Channels behave bad??

‎07-17-2017 03:34 AM

Labels:

I have a very strange problem with a project. I build an exe, which just crashes without meaningful error info. Right now I am trying to reduce the project to a smaller size an remove all confidential parts, so I could share it for troubleshooting. I build the application using LV 2017 32 bit. The top level VI launches just fine and works totally ok from the Dev environment. However when I launch it from exe, it just crashes. Sometimes just after launch, sometimes after a minute or so... One type of crash info is this:

 

crash1.png

 

First I thought the problem is with a DLL call, but even removing it still a problem. I also checked all dynamically called VIs, and all paths, all is ok (and they would produce meaningful error, not a full crash).

 

Another type of crash report is the following:

 

crash_at_end.png

another:

crashend2.png

 

The crash reports in respective order:

 

Spoiler
####
#Date: 17 Jul 2017 10:19:06
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: MNVST
#Version: 17.0 32-bit
#AppKind: AppLib
#AppModDate: 7/17/2017 08:17 GMT
#LabVIEW Base Address: 0x52650000


InitExecSystem() call to GetCurrProcessNumProcessors() reports: 8 processors
InitExecSystem() call to GetNumProcessors()            reports: 8 processors
InitExecSystem()                                      will use: 8 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3583124348.05353832, (10:19:08.053538323 2017:07:17)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3583124348.05353832, (10:19:08.053538323 2017:07:17)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3583124348.05353832, (10:19:08.053538323 2017:07:17)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3583124348.05353832, (10:19:08.053538323 2017:07:17)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3583124348.05353832, (10:19:08.053538323 2017:07:17)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3583124348.05353832, (10:19:08.053538323 2017:07:17)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3583124348.05353832, (10:19:08.053538323 2017:07:17)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3583124348.05353832, (10:19:08.053538323 2017:07:17)]

<DEBUG_OUTPUT>
17/07/2017 10:19:22.696
DAbort 0xF50EFD7B: 
c:\builds\penguin\labview\components\mgcore\trunk\17.0\source\MemoryManager.cpp(1273) : DAbort 0xF50EFD7B: 
minidump id: d61ee8f9-9b14-469a-9e11-836f31ae726f
$Id: //labview/components/mgcore/trunk/17.0/source/MemoryManager.cpp#4 $

</DEBUG_OUTPUT>
0x527549D9 - lvrt <unknown> + 0
0x52E41CA9 - lvrt <unknown> + 0
0x52E2749C - lvrt <unknown> + 0
0x52FC9465 - lvrt <unknown> + 0
0x52FBE18A - lvrt <unknown> + 0
0x52FBE18A - lvrt <unknown> + 0
0x52FBE18A - lvrt <unknown> + 0
0x52FBE18A - lvrt <unknown> + 0
0x52FA5DD1 - lvrt <unknown> + 0
0x52FBE18A - lvrt <unknown> + 0
0x52FBE18A - lvrt <unknown> + 0
0x52F82FAC - lvrt <unknown> + 0
0x52CBEB91 - lvrt <unknown> + 0
0x52CAC6AF - lvrt <unknown> + 0
0x52F82F30 - lvrt <unknown> + 0
0x53009B3C - lvrt <unknown> + 0
0x52D6758C - lvrt <unknown> + 0
0x52D6786E - lvrt <unknown> + 0
0x52D67C7F - lvrt <unknown> + 0
0x52D678EA - lvrt <unknown> + 0
0x529A7E2F - lvrt <unknown> + 0
0x529ACFDF - lvrt <unknown> + 0
0x529A969F - lvrt <unknown> + 0
0x529A9127 - lvrt <unknown> + 0
0x52997CEB - lvrt <unknown> + 0
0x52996E70 - lvrt <unknown> + 0
0x52999E86 - lvrt <unknown> + 0
0x52C2DD8E - lvrt <unknown> + 0
0x52C2DFD0 - lvrt <unknown> + 0
0x52E9D240 - lvrt <unknown> + 0
0x52F28183 - lvrt <unknown> + 0
0x52E9CB3C - lvrt <unknown> + 0
0x527D0942 - lvrt <unknown> + 0
0x527D1274 - lvrt <unknown> + 0
0x527D275A - lvrt <unknown> + 0
0x52E8B18A - lvrt <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x52650000 ***
#** DisposeInstrument: "C:\_TLK_work\03--MNVST_project\_LabVIEW_stuff\MNVST_LV_project\builds\MNVST\MNVST_0.1\MNVST.exe\Users\Andras\Documents\LabVIEW Data\2017(32-bit)\ExtraVILib\ChannelInstances\Stream-t'Data_descriptor.ctl'\)Channel.vi"
#** VILinkObjRemoveCore: "C:\_TLK_work\03--MNVST_project\_LabVIEW_stuff\MNVST_LV_project\builds\MNVST\MNVST_0.1\MNVST.exe\Users\Andras\Documents\LabVIEW Data\2017(32-bit)\ExtraVILib\ChannelInstances\Stream-t'Data_descriptor.ctl'\)Channel.vi"
*** End Dump ***
Spoiler
####
#Date: 17 Jul 2017 10:23:01
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: MNVST
#Version: 17.0 32-bit
#AppKind: AppLib
#AppModDate: 7/17/2017 08:17 GMT
#LabVIEW Base Address: 0x52650000


InitExecSystem() call to GetCurrProcessNumProcessors() reports: 8 processors
InitExecSystem() call to GetNumProcessors()            reports: 8 processors
InitExecSystem()                                      will use: 8 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3583124583.22498941, (10:23:03.224989415 2017:07:17)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3583124583.22498941, (10:23:03.224989415 2017:07:17)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3583124583.22498941, (10:23:03.224989415 2017:07:17)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3583124583.22498941, (10:23:03.224989415 2017:07:17)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3583124583.22498941, (10:23:03.224989415 2017:07:17)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3583124583.22498941, (10:23:03.224989415 2017:07:17)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3583124583.22498941, (10:23:03.224989415 2017:07:17)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3583124583.22498941, (10:23:03.224989415 2017:07:17)]

<DEBUG_OUTPUT>
17/07/2017 10:23:20.700
DAbort 0x0037C03D: 
c:\builds\penguin\labview\components\mgcore\trunk\17.0\source\MemoryManager.cpp(1426) : DAbort 0x0037C03D: 
minidump id: 31db4400-d2a6-4343-b14d-09820f92866f
$Id: //labview/components/mgcore/trunk/17.0/source/MemoryManager.cpp#4 $

</DEBUG_OUTPUT>
0x527549D9 - lvrt <unknown> + 0
0x52E41CA9 - lvrt <unknown> + 0
0x52E2749C - lvrt <unknown> + 0
0x52E204B1 - lvrt <unknown> + 0
0x52FCE268 - lvrt <unknown> + 0
0x0C3224DA - <unknown> <unknown> + 0
0x0C37067C - <unknown> <unknown> + 0
0x530030D6 - lvrt <unknown> + 0
0x52FFEEDA - lvrt <unknown> + 0
0x52E27DC5 - lvrt <unknown> + 0
0x7585336A - kernel32 <unknown> + 0
0x77B19902 - ntdll <unknown> + 0
0x77B198D5 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0

The only meaningful crash info (at least for me) is that the crash has something to do with my Stream channel ("Dumping Bread Crumb Stack" : ....

DisposeInstrument: Stream-t'Data_descriptor.ctl'

VILinkObjRemoveCore: Stream-t'Data_descriptor.ctl'  .......)

 

I will test this project on another PC, and see if it crashes there as well. We will be able to use this application run from the Dev environment, but I like to create an executable, more lightweight. So I hope i will find a solution...

If I get new info during this bug search, I will share it here. And of course any hints/help are welcome! 🙂

0 Kudos
Message 1 of 16
(5,004 Views)
Reply

Re: LV2017 built EXE crashes - Channels behave bad??

‎07-17-2017 03:52 AM

Ok, as a first step in troubleshooting, I replaced my single Stream channel into a Queue. I still use 5-6 TAG channels in the code. Since I replaced the Stream with a Queue, I do not see more crashes! I launched the rebuilt app 10 times, and also let it run longer time, but no more crash.

Since this application will control a critical experiment where a crash would result in losing very important data, I just use the good old Queues for this one. When I find some time, I will try to reproduce these crashes in a project which I am allowed to share here so people with more skills can have a look...

Message 2 of 16
(4,994 Views)
Reply

Re: LV2017 built EXE crashes - Channels behave bad??

‎07-17-2017 04:29 PM

Sigh.  Is the problem Channel Wires (my now-favorite LabVIEW Feature) or LabVIEW 2017 (which I've had both install "corruptly" and install "OK", but am too timid to install on any of my "production" machines as yet)?

 

I can tell you that I'm currently putting the finishing touches (and doing the final testing) on a routine that uses Channel Wires very heavily.  The Top Level VI has 4 Channels (3 Messengers and a Tag) connecting an Event Loop, a Queue-Listener Loop, and a Channel Message Handler (think QMH with Channel Wires).  It launches up to 24 Clones that each consist of 5 parallel Loops, another Queue-Listener and essentially 4 Channel Message Handlers, with at least 5 Channels (4 Messengers and a Tag).  I think I also have a Stream Channel buried in there, somewhere.

 

I've had no trouble building this as an Executable and deploying it on Windows 7 and Windows 10 machines (I had to learn about building an Installer, but it was easier than I thought).  And it seems to work (in LabVIEW 2016) ...

 

Bob Schor

0 Kudos
Message 3 of 16
(4,943 Views)
Reply

Re: LV2017 built EXE crashes - Channels behave bad??

‎07-17-2017 10:14 PM

I am pretty sure this issue is due to some corrupted code/data on my machine. When I used the problematic exe on another PC (this was win10), it also gave crashes, and including "breadcrumbs" about that particular Stream channel. Maybe this stream in my project is somehow corrupted?

 

I am pretty sure this is not a global bug, channels were already under intensive testing... As a next testing step, I will remove the Queue, and create a new fresh Stream channel. Actually this was the basic Stream channel type, without abort function. I had a single Read node in a consumer loop, and 3 Write nodes inside a state machine of another loop (in different cases).

0 Kudos
Message 4 of 16
(4,935 Views)
Reply

Re: LV2017 built EXE crashes - Channels behave bad??

‎07-18-2017 02:42 AM

I copied the Stream nodes and the corresponding typdef cluster into a new project, and I just created a dummy main VI using these between two parallel loops. If I make a built EXE, cannot see any crashes. So it looks like the trouble is only with that particular VI+Stream+project combination.

 

Using the latest version where I replaced this failing Stream with a Queue, I just removed the Queue, and created a totally new Stream channel. Now if I run the built EXE, no more problem. It is a pity I cannot reproduce the error, but also good my project now works with the Stream 🙂

0 Kudos
Message 5 of 16
(4,922 Views)
Reply

Re: LV2017 built EXE crashes - Channels behave bad??

‎07-18-2017 03:38 PM

Glad to hear that "something works".

 

Channel Wires can be a little tricky, particularly if you have multiple Projects and do "similar things" in these Projects, leading (perhaps) to using similarly-named variables.  When Channels were introduced, I noticed that my code would occasionally get lots of errors because of Channel definitions hidden in Dependencies.  I was being perhaps too profligate with the use of Channels, and frequently had "name clashes" between Projects.  I discovered that unlike ordinary Project variables, which stay "in scope" within the Project, the Channel "scope" is to the User -- all of the Channels that I define "live together" (in harmony?) in my LabVIEW Data folder, and are decidedly not Project-specific.  Indeed, a "cure" for the woes I was encountering was to delete all of the Channel Definitions, re-open the Project, and let LabVIEW rebuild the Channels for that specific Project.  I did argue for narrowing the scope to the Project, but was happy enough with this new Feature that I accepted the Design Decision (I'm certain that "doing it Bob's Way" would have been much more challenging and would have had negative implications that I don't know about).  So this may explain some of your findings.

 

I've also seen weird and inconsistent behavior with LabVIEW 2017, to the extent that I've only installed it on one machine, and then spent a week (well, 4-5 days) getting rid of it and getting LabVIEW 2016 (which was also present) re-installed so I could "do some work".  I've also tried to duplicate the problem, but also without consistent results.

 

Bob Schor

Message 6 of 16
(4,898 Views)
Reply

Re: LV2017 built EXE crashes - Channels behave bad??

‎07-28-2017 09:49 AM

Some more news. Good and bad.

 

The good is that, I had no "MemoryManager.cpp" crashes for a longer time even using Stream Channel. So I suspect I had/have ( 😞 ) some general problem with my build EXEs and/or the LAbVIEW runtime engine...

 

The bad is that, today, just out of nowhere, only changing the position of some GUI elements, and re-building the EXE, I started to get crashes. But only when I quit from the application (properly, closing all references, stopping dynamically called VIs, etc), and randomly, at every 3rd-4th of exit events. This is really sad.

Here is the dialog:

crashagain1.png

 

Here is the dump file:

Spoiler
####
#Date: 28 Jul 2017 16:23:48
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: MNVST
#Version: 17.0 32-bit
#AppKind: AppLib
#AppModDate: 7/28/2017 14:23 GMT
#LabVIEW Base Address: 0x5DCF0000


InitExecSystem() call to GetCurrProcessNumProcessors() reports: 8 processors
InitExecSystem() call to GetNumProcessors()            reports: 8 processors
InitExecSystem()                                      will use: 8 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3584096630.45495749, (16:23:50.454957486 2017:07:28)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3584096630.45495749, (16:23:50.454957486 2017:07:28)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3584096630.45495749, (16:23:50.454957486 2017:07:28)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3584096630.45495749, (16:23:50.454957486 2017:07:28)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3584096630.45495749, (16:23:50.454957486 2017:07:28)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3584096630.45495749, (16:23:50.454957486 2017:07:28)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3584096630.45495749, (16:23:50.454957486 2017:07:28)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3584096630.45495749, (16:23:50.454957486 2017:07:28)]
VI_BROKEN (0): [VI "NI_FileType.lvlib:LVFileType.ctl" (0x0ed9c2b8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NI_FileType.lvlib:LVFileType.ctl" (0x0ed9c2b8)]
this->flags=34611712, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Control Info.ctl" (0x0ed994c8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Control Info.ctl" (0x0ed994c8)]
this->flags=34611712, compilerError=6
VI_BROKEN (0): [VI "NI_PackedLibraryUtility.lvlib:Get Exported File List.vi" (0x0ed9bfa8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NI_PackedLibraryUtility.lvlib:Get Exported File List.vi" (0x0ed9bfa8)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle Tab Settings.vi" (0x0ed99650)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle Tab Settings.vi" (0x0ed99650)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle Table Settings.vi" (0x0ed99340)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle Table Settings.vi" (0x0ed99340)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle Multicolumn Listbox Settings.vi" (0x0ed99c70)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle Multicolumn Listbox Settings.vi" (0x0ed99c70)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle Tree Settings.vi" (0x0ed99df8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle Tree Settings.vi" (0x0ed99df8)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle Chart Settings.vi" (0x0ed99f80)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle Chart Settings.vi" (0x0ed99f80)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle Graph Settings.vi" (0x0ed9a108)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle Graph Settings.vi" (0x0ed9a108)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Process Column Width.vi" (0x0ed9a290)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Process Column Width.vi" (0x0ed9a290)]
this->flags=50340352, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle Knob Settings.vi" (0x0ed9a5a0)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle Knob Settings.vi" (0x0ed9a5a0)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle Slide Settings.vi" (0x0ed9a728)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle Slide Settings.vi" (0x0ed9a728)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Get Default Path.vi" (0x0ed9a8b0)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Get Default Path.vi" (0x0ed9a8b0)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Save Settings.vi" (0x0ed9b058)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Save Settings.vi" (0x0ed9b058)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Write Setting.vi" (0x0ed9b678)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Write Setting.vi" (0x0ed9b678)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Read Setting.vi" (0x0ed9b800)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Read Setting.vi" (0x0ed9b800)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle Ctl[] Settings.vi" (0x0ed9b988)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle Ctl[] Settings.vi" (0x0ed9b988)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Load VI.vi" (0x0ed9bb10)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Load VI.vi" (0x0ed9bb10)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "NI_FileType.lvlib:FT_FileTypes.ctl" (0x0ed9c440)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NI_FileType.lvlib:FT_FileTypes.ctl" (0x0ed9c440)]
this->flags=34611712, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Setting[].vi" (0x0ed9aed0)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Setting[].vi" (0x0ed9aed0)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle Ctl Settings.vi" (0x0ed997d8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle Ctl Settings.vi" (0x0ed997d8)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "NI_FileType.lvlib:Get File Type.vi" (0x0ed9c130)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "NI_FileType.lvlib:Get File Type.vi" (0x0ed9c130)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Load Settings.vi" (0x0ed9b1e0)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Load Settings.vi" (0x0ed9b1e0)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Save VI.vi" (0x0ed9c5c8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Save VI.vi" (0x0ed9c5c8)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Handle VI Settings.vi" (0x0ed99960)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Handle VI Settings.vi" (0x0ed99960)]
this->flags=33563136, compilerError=6
VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Save Restore Settings.ctl" (0x0ed991b8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Save Restore Settings.ctl" (0x0ed991b8)]
this->flags=36708864, compilerError=6

<DEBUG_OUTPUT>
28/07/2017 16:24:04.602
DAbort 0xF50EFD7B: 
c:\builds\penguin\labview\components\mgcore\trunk\17.0\source\MemoryManager.cpp(1273) : DAbort 0xF50EFD7B: 
minidump id: cac1fe45-ae80-461b-8739-49618a370a1e
$Id: //labview/components/mgcore/trunk/17.0/source/MemoryManager.cpp#4 $

</DEBUG_OUTPUT>
0x5DDF49D9 - lvrt <unknown> + 0
0x5E4E1CA9 - lvrt <unknown> + 0
0x5E4C749C - lvrt <unknown> + 0
0x5E669465 - lvrt <unknown> + 0
0x5E65E18A - lvrt <unknown> + 0
0x5E65E18A - lvrt <unknown> + 0
0x5E65E18A - lvrt <unknown> + 0
0x5E65E18A - lvrt <unknown> + 0
0x5E645DD1 - lvrt <unknown> + 0
0x5E65E18A - lvrt <unknown> + 0
0x5E65E18A - lvrt <unknown> + 0
0x5E622FAC - lvrt <unknown> + 0
0x5E35EB91 - lvrt <unknown> + 0
0x5E34C6AF - lvrt <unknown> + 0
0x5E622F30 - lvrt <unknown> + 0
0x5E6A9B3C - lvrt <unknown> + 0
0x5E40758C - lvrt <unknown> + 0
0x5E40786E - lvrt <unknown> + 0
0x5E407C7F - lvrt <unknown> + 0
0x5E4078EA - lvrt <unknown> + 0
0x5E047E2F - lvrt <unknown> + 0
0x5E04CFDF - lvrt <unknown> + 0
0x5E04969F - lvrt <unknown> + 0
0x5E049127 - lvrt <unknown> + 0
0x5E037CEB - lvrt <unknown> + 0
0x5E036E70 - lvrt <unknown> + 0
0x5E039E86 - lvrt <unknown> + 0
0x5E2CDD8E - lvrt <unknown> + 0
0x5E2CDFD0 - lvrt <unknown> + 0
0x5E53D240 - lvrt <unknown> + 0
0x5E5C8183 - lvrt <unknown> + 0
0x5E53CB3C - lvrt <unknown> + 0
0x5DE70942 - lvrt <unknown> + 0
0x5DE71274 - lvrt <unknown> + 0
0x5DE7275A - lvrt <unknown> + 0
0x5E52B18A - lvrt <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x5DCF0000 ***
#** DisposeInstrument: "C:\_TLK_work\03--MNVST_project\_LabVIEW_stuff\MNVST_LV_project\builds\MNVST\MNVST_1.0\MNVST.exe\Users\Andras\Documents\LabVIEW Data\2017(32-bit)\ExtraVILib\ChannelInstances\Stream-t'Data_descriptor.ctl'\)Channel.vi"
#** VILinkObjRemoveCore: "C:\_TLK_work\03--MNVST_project\_LabVIEW_stuff\MNVST_LV_project\builds\MNVST\MNVST_1.0\MNVST.exe\Users\Andras\Documents\LabVIEW Data\2017(32-bit)\ExtraVILib\ChannelInstances\Stream-t'Data_descriptor.ctl'\)Channel.vi"
*** End Dump ***

Now I see some new elements in these logs: what do these parts mean??? --> VI Broken???

VI_BROKEN (0): [VI "Save Restore Settings.lvclass:Control Info.ctl" (0x0ed994c8)]
VirtualInstrument::SetOrClearBadVILibrary - now VI is bad on [VI "Save Restore Settings.lvclass:Control Info.ctl" (0x0ed994c8)]
this->flags=34611712, compilerError=6

How could they be broken, when I am able to build my EXE? Most of the entries in this list mention subVIs from the MGI "Save Restore Settings.lvclass". I do have these VIs in my code, but actually they are not fired even once during the runtime when the memory crash happens at the Exit operation...

 

So I have no idea. Is there any possibility for better debugging why these crashes happen on my PC?? This is my recent setting in the "Build Specifications":

 

crashagain2.png

 

0 Kudos
Message 7 of 16
(4,839 Views)
Reply

Re: LV2017 built EXE crashes - Channels behave bad??

‎07-28-2017 11:22 AM

I would kind of "close" this thread with a satisfying result, that moving the very same exe to another laptop, i just cannot reproduced the crashes...

I must have something wrong with this particular laptop where i see these symptoms. I think it will be soon time for a clean OS reinstall, and putting LabVIEW fresh on it...

0 Kudos
Message 8 of 16
(4,832 Views)
Reply

Re: LV2017 built EXE crashes - Channels behave bad??

‎02-15-2018 05:02 AM

 

Hi , I am having similar problem with my application (Consisting of class structures..). Using LV2015 and Windows 7. After creating exe , when I tried to run the application following error popped up. I have tried following:

 

Mass compilation

Checking the dependencies 

Cleaning up the project and keeping oly the vis required for the project.

 

Any suggestions for building the project????

 image.png

0 Kudos
Message 9 of 16
(4,598 Views)
Reply

Re: LV2017 built EXE crashes - Channels behave bad??

‎03-20-2018 04:34 AM

I am not in luck, the mysterious crashes just started again with my EXE application. I had to rebuild the application recently (like 3 weeks ago?), but only some cosmetic changes were done on the GUI, so these cannot explain why the crashes are back. I had two crashes in the last 2 weeks. Right not I am upgrading LV 2017 to SP1, who knows, maybe a rebuild with SP1 will fix this issue...? Fingers crossed...

 

The only other change I did in my application was way back in January, and all was fine since, the recent three crashes happened only, one at end of February and now the last 2 in March. This change I did in January was about, I replaced a previously used shift register storage (incrementally built 2D array, and deleting some data from it time by time to avoid mem leak) with a Queue-based solution, to store 2 days of data (1 Hz of sampling).

 

One of the crash reports mentions something about Channels again as last year, as during the last year crashes. The other crash report mentions the "Data_storage_Ring_buffer.vi", so just in case I attach this VI as well. I cannot see any possible problem with this VI, it does not have memory leak, and nothing which would explain these recent crashes. And if this was the reason, why the crashes did not start in January when I deployed this VI in my app?? Do you see any problem with this vi? There will be some missing subVIs/typdef ctrls, but those are not relevant now anyway.

 

I attach the two crash reports, and also show their "lvlog.txt" content below. As well, a screen shot of the latest crash window...

 

What do you think? Any idea what goes wrong?

 

Crash report 7th of March:

Spoiler
####
#Date: 07 Mar 2018 15:12:15
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: MNVST
#Version: 17.0 32-bit
#AppKind: AppLib
#AppModDate: 3/07/2018 14:11 GMT
#LabVIEW Base Address: 0x50480000


InitExecSystem() call to GetCurrProcessNumProcessors() reports: 4 processors
InitExecSystem() call to GetNumProcessors()            reports: 4 processors
InitExecSystem()                                      will use: 4 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3603276738.36098242, (15:12:18.360982418 2018:03:07)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3603276738.36098242, (15:12:18.360982418 2018:03:07)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3603276738.36098242, (15:12:18.360982418 2018:03:07)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3603276738.36098242, (15:12:18.360982418 2018:03:07)]
Thread consumption suspected: 4 Try starting 1 threads
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3603276754.87992716, (15:12:34.879927159 2018:03:07)]
Thread consumption suspected: 2 Try starting 1 threads
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3603285437.40253925, (17:37:17.402539254 2018:03:07)]
Thread consumption suspected: 3 Try starting 1 threads
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3603305845.11079359, (23:17:25.110793591 2018:03:07)]
Thread consumption suspected: 1 Try starting 1 threads
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3603372923.66746712, (17:55:23.667467118 2018:03:08)]
<LVExec>
{"a":[
{
"vi": "C:\\MNVST_LV_project\\builds\\MNVST\\MNVST\\MNVST.exe\\MNVST_LV_project\\MNVST_software\\Ring_buffer\\subVIs\\Data_storage_AE_Ring_buffer.vi",
"ctx": "Main Application Instance",
"type": "subVI"
}
,
{
"vi": "C:\\MNVST_LV_project\\builds\\MNVST\\MNVST\\MNVST.exe\\MNVST_LV_project\\MNVST_software\\subVIs\\update_popupGraph.vi",
"ctx": "Main Application Instance",
"type": "subVI"
}
,
{
"vi": "C:\\MNVST_LV_project\\builds\\MNVST\\MNVST\\MNVST.exe\\MNVST_LV_project\\MNVST_software\\subVIs\\popup_Graph_dialog_v3_small.vi",
"ctx": "Main Application Instance",
"type": "topVI"
}
] }
</LVExec>

<DEBUG_OUTPUT>
12/03/2018 12:45:12.271
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: 9738c881-e3fd-4490-b6dd-ac7728ad23eb
ExceptionCode: 0xC0000005

</DEBUG_OUTPUT>
0x747E146F - nierInterface <unknown> + 0
0x747E5D75 - nierInterface <unknown> + 0
0x747E517A - nierInterface <unknown> + 0
0x7C37FDB4 - MSVCR71 <unknown> + 0
0x77B550D7 - ntdll <unknown> + 0
0x77B19805 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0

Crash report 19th of March:

Spoiler
####
#Date: 12 Mar 2018 12:50:53
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: MNVST
#Version: 17.0 32-bit
#AppKind: AppLib
#AppModDate: 3/07/2018 14:11 GMT
#LabVIEW Base Address: 0x50E00000


InitExecSystem() call to GetCurrProcessNumProcessors() reports: 4 processors
InitExecSystem() call to GetNumProcessors()            reports: 4 processors
InitExecSystem()                                      will use: 4 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3603700256.84870386, (12:50:56.848703862 2018:03:12)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3603700256.84870386, (12:50:56.848703862 2018:03:12)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3603700256.84870386, (12:50:56.848703862 2018:03:12)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3603700256.84870386, (12:50:56.848703862 2018:03:12)]
Thread consumption suspected: 3 Try starting 1 threads
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3603700266.50325680, (12:51:06.503256798 2018:03:12)]
Thread consumption suspected: 3 Try starting 1 threads
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3603710124.05807686, (15:35:24.058076859 2018:03:12)]
Thread consumption suspected: 3 Try starting 1 threads
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3603724329.61258793, (19:32:09.612587929 2018:03:12)]
Thread consumption suspected: 2 Try starting 2 threads
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3603763390.20872641, (06:23:10.208726407 2018:03:13)]
starting LabVIEW Execution System 2 Thread 8 , capacity: 24 at [3603763390.20872641, (06:23:10.208726407 2018:03:13)]
<LVExec>
{"a":[
{
"vi": "C:\\MNVST_LV_project\\builds\\MNVST\\MNVST\\MNVST.exe\\Users\\MNVST\\Documents\\LabVIEW Data\\2017(32-bit)\\ExtraVILib\\ChannelInstances\\Stream-t'Data_descriptor.ctl'\\)Channel.vi",
"ctx": "Main Application Instance",
"type": "subVI"
}
,
{
"vi": "C:\\MNVST_LV_project\\builds\\MNVST\\MNVST\\MNVST.exe\\MNVST_LV_project\\MNVST_software\\MAIN_toplevel_v8.vi",
"ctx": "Main Application Instance",
"type": "topVI"
}
] }
</LVExec>

<DEBUG_OUTPUT>
19/03/2018 09:58:19.066
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: d7a4ab81-2c00-43bd-9365-a60676f1bd47
ExceptionCode: 0xC0000005

</DEBUG_OUTPUT>
0x747E146F - nierInterface <unknown> + 0
0x747E5D75 - nierInterface <unknown> + 0
0x747E517A - nierInterface <unknown> + 0
0x7C37FDB4 - MSVCR71 <unknown> + 0
0x77B550D7 - ntdll <unknown> + 0
0x77B19805 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0

crahsfinal.png

 

Download All
0 Kudos
Message 10 of 16
(4,512 Views)
Reply