Exception Code: 0xC0000005 (Application Crash)

[Space369]

Hello,

I found crash of the executable file with error message as shown below.

Crash occurred 2-3 times back to back and then executable file working properly. Then crash again happened next day.

FYI : Project contains following modules

LabVIEW Version : 2015 , NI-Vision, Report Generation Toolkit and Database Connectivity Toolkit

I am unable to understand the issue in the log.txt file which is also attached below.

Help me !

[Bob_Schor]

The "We apologize for the inconvenience" message is often a very subtle bug somewhere in the LabVIEW compiler.  You can sometimes get rid of it by making some changes in your code and recompiling/rebuilding the executable.

Does your code work when you are running LabVIEW in Development Mode?  Does the Executable fail on one PC to which it is deployed, but work on another?  Did you submit the Report generated with the crash to NI?  Did you follow up with a Service Request?

You might also try installing LabVIEW 2016 (which I found to be more "stable" and much easier to install than more recent NIPM-based versions of LabVIEW) and see if the problem goes away -- actually, that's probably the first thing to try, in my opinion.

Bob Schor

[Jacobson-ni]

---

@Bob_Schor wrote:

The "We apologize for the inconvenience" message is often a very subtle bug somewhere in the LabVIEW compiler.  You can sometimes get rid of it by making some changes in your code and recompiling/rebuilding the executable.

---

I would say that a runtime crash is very rarely a compiler issue although that doesn't invalidate any of the suggestions you made.

All error 0xC0000005 indicates is that you're trying to read or write to memory you don't have access to. The lvlog.txt you attached shows a call stack which only has calls from nierInterface, KERNELBASE, and ntdll. NIER stands for NI Error Reporting so the actual crash would happen before that. Looking before that we only see KERNELBASE and ntdll so even if those are throwing this exception, the real problem or interesting calls would have happened before this. As Bob suggested, I would recommend opening up a service request.

[BertMcMahan]

Apologies for the necropost- but are there any tools we can use to pinpoint the cause of an application crash? I'm getting these as well, but I also have error code 0xc000001d every once in a while.

[rolfk]

---

@BertMcMahan wrote:

Apologies for the necropost- but are there any tools we can use to pinpoint the cause of an application crash? I'm getting these as well, but I also have error code 0xc000001d every once in a while.

---

Not really that I’m aware off, at least outside of NI. The error log itself is often not very useful, especially if the crash happens deep in the Windows kernel and the printed stack trace does not reach the actual LabVIEW functions.

The crash dump file requires a special program from Microsoft to analyze it, but without at least a debug symbol file from the EXACT compiled executable and ultimately the C++ source code of the application, it is difficult to impossible to reach any useful conclusion.

While crashes in NI modules (including LabVIEW itself) are not unheard of, there is one reason that is at least 100 times more likely to be the culprit. If you have anywhere Call Library Nodes that you did yourself or got from some other place than as an official NI driver, it’s the first thing I would look at. These are easy to not do right and can have catastrophic effects in that case, quite often not even during the actual call itself but only later when LabVIEW stumbles over corrupted memory locations that have been previously destroyed by misconfigured Call Library Nodes or buggy DLLs.

Ultimately you’ll often have to use the  conditional compile structure to “divide et impera” these kind of problems.

[BertMcMahan]

Thanks for the info. I mentioned this in my reply in your other thread but (for future Googler's sake) I'll repeat it here. I'm not using any custom DLL's outside of the normal NI stuff. I use a lot of TDMS functions, and there may be a dangerous Open VI Reference getting a clone name, but I haven't tracked down anywhere it's actually being used wrong yet.

This program is an Actor Framework one with a boatload of classes and all sorts of dynamic loading and unloading of dynamic dispatch Actors. The crash happens generally when I load or unload an Actor (I can't tell which as the events happen nearly simultaneously, and parallelizing them appears to mask the bug, so it's likely a race condition somewhere).