LabVIEW 2014 x64 AppCrash StackHash crash

[Thomas_robertson]

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.

[Thomas_robertson]

Bump.  Anybody?

[Inachosa]

Hello! Could you please upload the dump file of you application  to see what might be going on?

[Thomas_robertson]

Trying to upload the dump file but it's failing.  In the meantime here's windows's info (from View Details in the Windows crash dialog):

Problem signature:
Problem Event Name: APPCRASH
Application Name: LabVIEW.exe
Application Version: 14.0.1.4008
Application Timestamp: 54c50c6f
Fault Module Name: StackHash_2264
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 0000000061612c94
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 2264
Additional Information 2: 2264db07e74365624c50317d7b856ae9
Additional Information 3: 875f
Additional Information 4: 875fa2ef9d2bdca96466e8af55d1ae6e

[amandion]

I'm having a hard time uploading the crash dump to the form so I've uploaded it to Google Drive. You can download it with this link:

https://drive.google.com/file/d/0B8rpj24dycSVdGt1Ny10Q2R0V2s/view?usp=sharing

Thanks!

[Jacobson-ni]

When your application crashes are you making sure to send it into NI?  If you are, the two most helpful pieces of information are the Crash ID and the lvlog.txt that should also be in the .zip.  I have never had a whole lot of success looking at dump files, the lvlog will give information in a more readable format that can sometimes yield helpful results.

Trying to diagram disable parts of your code is a really great step when trying to figure out what is causing a crash.  In regards to reproducing the error, how long does 1500 runs take?  If you are looking to reproduce this error and a total of 4500 runs without crash is good enough for you to say it is working is this an hour of testing or days?

If you have time tomorrow it might just be best to call into NI support.  Crash issues are often hard to diagnose (exception 0xC0000005 is pretty generic) and a lot of the times the issue will get resolved more quickly if you are able to call and email NI support directly rather than go through the forums.

[Thomas_robertson]

Unfortunately when this crash occurs it's beyond the point of LabVIEW reporting a crash and having the nice "report to NI" dialog.  Instead it's windows directly telling me that the application has crashed and that I have to close it at the OS level.  So, no logs.  We have been able to use Desktop Execution Trace Toolkit but what it's told us is that the crash is happening in a variety of places rather than always as a result of one specific call chain.

We have a support ticket with NI and they're trying to reproduce it on their end today.

[Thomas_robertson]

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.

[Thomas_robertson]

Here's a screenshot of Visual C++ opening into a debugger when the crash occurs.    I think this says the crash is occuring in "mgcore_SH_14_0.dll"?

[jojo_mcbean]

I'm having the same error. Labview crashes after 10-30 minutes of running. Did anyone figure this one out?