03-28-2016 02:50 PM
Hi All,
I've received a C++ Exception (0xE06D7363) at EIP=0x754E80D7 during the deployed state. Any help would be much appreciated.
Below is the log file it created. Update Status.vi calls the Main Event.vi that creates a user event that updates a string on the Main.vi's front panel.
####
#Date: Thu, Jan 28, 2016 8:30:47 AM
#OSName: Windows 7 Professional Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: App Name
#Version: 14.0.1f3 32-bit
#AppKind: AppLib
#AppModDate: 1/11/2016 16:04 GMT
#LabVIEW Base Address: 0x30000000
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 [3536832651.36128000, (08:30:51.361279965 2016:01:28)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3536832651.36128000, (08:30:51.361279965 2016:01:28)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3536832651.36128000, (08:30:51.361279965 2016:01:28)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3536832651.36128000, (08:30:51.361279965 2016:01:28)]
Thread consumption suspected: 2 Try starting 3 threads
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3536832658.51099490, (08:30:58.510994912 2016:01:28)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3536832658.51099490, (08:30:58.510994912 2016:01:28)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3536832658.51099490, (08:30:58.510994912 2016:01:28)]
<LVExec>
{"a":[
{
"vi": "C:\\Program Files\\App Name\\App Name.exe\\Events\\Engines\\Main Event.vi",
"ctx": "Main Application Instance",
"type": "subVI"
}
,
{
"vi": "C:\\Program Files\\App Name\\App Name.exe\\SubVIs\\Utility\\Update Status.vi",
"ctx": "Main Application Instance",
"type": "subVI"
}
,
{
"vi": "C:\\Program Files\\App Name\\App Name.exe\\Main.vi",
"ctx": "Main Application Instance",
"type": "topVI"
}
] }
</LVExec>
<DEBUG_OUTPUT>
2/3/2016 4:19:53.656 AM
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: 91d149df-2d75-411a-a61d-5c2eedb2a8b7
ExceptionCode: 0xE06D7363
</DEBUG_OUTPUT>
0x100011AB - nierInterface <unknown> + 0
0x10005E96 - nierInterface <unknown> + 0
0x1000621C - nierInterface <unknown> + 0
0x762B07FE - kernel32 <unknown> + 0
0x77C1810A - ntdll <unknown> + 0
0x77C0396E - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
03-29-2016 04:07 PM
Hi ADrexelDragon,
At first glance I have found a similar issue on the fourms that talks about the C++ Exception (0xE06D7363). The link to that forum is below. Are you experiencing similar issues to the previous user in this post? Are you able to reproduce this issue consistently? I also would like to confirm that you are using LabVIEW 2014 as the error log shows. Are you using any other software?
http://forums.ni.com/t5/Multisim-and-Ultiboard/0xE06D7363-Error-Cosimulation/td-p/2939782
It might also be worthwhile for you to post your code. Having a bit more context might help troubleshoot the issue.
03-29-2016 07:34 PM
Hi John,
I am not using MultiSim, just LabVIEW 2014 SP1.
The error is sporatic and doesn't happen every time the customer runs the software. The software runs over multiple days and I'm not sure what could be causing the issue. The frequency has seemed to increase as of late... which makes me think it is a computer related issue. I was hoping for more insight on the specific error to help track down the issue.
Thanks,
Nick
03-30-2016 06:07 AM
It looks like you have a NULL reference (0x000000), that could be caused by some race condition or not closing references causing a ref to be closed before hand or running out of ref-memory. I'm in no way certain, but at a glance.
/Y
03-30-2016 10:32 AM
Ok. I will look into the code to see where this could have occurred.
Could the Null reference be created after the program crashes? For example, on a released queue or event registration?
03-31-2016 08:41 AM
ADrexelDragon,
Please let us know if you find anything in the code that is throwing this error. As far as I am aware, null references are typically the cause of a crash and not the product of one. This depends on the situation and what other programs you are using, but if you are only using LabVIEW it seems like the null reference comes before the crash. If you don't mind me asking, does your program use and DLLs? Could there be a chance that a DLL is configured incorrectly, or broken? Also posting the area of the code that you are working as well as the intention of the code might help debug the issue.
03-31-2016 09:16 AM
I am not using any DLLs. The null reference could be coming from a queue reference or user event reference. I ended up replacing the update status user event with a global variable. It just updates a string on the main GUI.
I can't post any code due to company policy. Overall architecture is 5 loops (Event handler, Event processor, Testing loop, DAQ loop, Error loop).
04-01-2016 01:26 PM
ADrexelDragon,
What OS are you deploying this program to? Have you been able to replicate this issue in the development enviornment? Does the code use any data acquisition hardware that you could simulate instead? I think trying to isolate the issue a bit further might help. You mentioned that you replaced the update status user event with a global variable. Were you able to see if this improvement made any changes with regards to the crash frequency? The exception you are receiving could be a custom exception or, even more generally, one raised through call to throw by the Microsoft Visual C++ compiler. You could also run DETT to find out what kind of VI calls are made right before the crash happens on the deveopment machine. Please let us know if any of these steps are helpful.