Executable crashes with error code 0xC0000005

[Josh2212]

Hi,

I created an installer for an application in LabVIEW 2015. The installed application captures data from two sources. One from DAQmx device and another from CNC controller. This application used to run correctly for the past few days. Now whenever the application is launched it throws an error code 0xC0000005 stating access violation. But this is not consistent as sometimes the application runs for hours without crashing or crashes at once it is opened. I suspect there is a problem with installer because only the application gets installed while other necessary NI softwares aren't installed. This phenomenon differs from system to system as one system runs the application without flaws while other doesn't showing crash message. The specifications of all the systems used are similar. Requesting someone to suggest me the most appropriate way to create an installer as I could not find any help for this specific case .

Thanks. 

[Andrey_Dmitriev]

---

@Josh2212 wrote:

and another from CNC controller. This application used to run correctly for the past few days. Now whenever the application is launched it throws an error code 0xC0000005 stating access violation. 

---

Usually this exception happened by accessing wrong memory address or something like that. The first question is - are you using any third party DLLs (to communicate with CNC controller, for example) in your code?

[Kyle97330]

As Andrey mentions this is quite often caused by 3rd party DLLs or other software interfacing with LabVIEW, like ActiveX.

Besides that, it can also be caused by hardware or driver problems.  I would suggest the following:

• Run the Windows Memory Diagnostic tool on the failing PC to see if there's bad RAM in it.
• Check to see if you can get updated drivers for:
  • Your CNC controller, if it's USB or has a PCI card in the computer
  • Your DAQmx device (even though you're using LabVIEW 2015, you should be able to use up to DAQmx 2018 with it as NI releases those to be backwards compatible for 3 versions)
  • Your PC motherboard's chipset
  • Any other USB or PCIe card you use that's more complicated than a mouse/keyboard/thumbdrive.
• Check the "Documents\LabVIEW Data\LVInternalReports" to see if there's any crash data in there to look at.  
  • If there are any, check any that are text files.  Any DMP files are pretty much useless.  Check inside any ZIP files to find text files.
  • The text files might point you to a VI that ran that is possibly (but not definitely) linked to the crash problem.

[Josh2212]

Thanks for the response. 

Yes I am using a third party .dll file from FANUC FOCAS Library in order to communicate with FANUC CNC controllers. Also I should specify that the application crashes only if I take data from the CNC controller + DAQmx and not when I take data from DAQmx alone.

[Josh2212]

Thanks for the response.

I suspect it is due to the usage of third party .dll file as I have the latest drivers installed. While checking LVinternal reports there weren't any text files but whenever the application crashes it says error occured at XXX.vi which is my main VI. 

[rolfk]

---

@Josh2212 wrote:

Thanks for the response.

I suspect it is due to the usage of third party .dll file as I have the latest drivers installed. While checking LVinternal reports there weren't any text files but whenever the application crashes it says error occured at XXX.vi which is my main VI. 

---

I would bet my hat that it is the use of that DLL. And no the DLL itself may be perfectly fine, but your interfacing to it is most likely not. Who wrote the VIs to interface to that DLL? How much C programming experience do they have?

[Andrey_Dmitriev · Accepted solution]

---

@Josh2212 wrote:

Thanks for the response.

I suspect it is due to the usage of third party .dll file as I have the latest drivers installed. While checking LVinternal reports there weren't any text files but whenever the application crashes it says error occured at XXX.vi which is my main VI. 

---

Let me add five cents for better understanding. Will be long comment (slightly "advanced"), but may be helpful for you or someone else who will get the same trouble.

At the first we can provocate error 0xC0000005 by very simple way:

I will create DLL with simple function:

char Crash ()
{
	char *ptr = (char*)0x1;
	return *ptr;
}

Attempt to read address 0x1 (or any other invalid address) will be sufficient to get this exception.

This function will be called as simple as:

But very important to set error handling to Disabled (because we would like to get not handled exception):

Now from this VI:

I will build application (because its much more convenient to crash simple app and not whole LabVIEW), run it and hit "Crash It!" Button, then the following Dialog will appear:

And when I hit View Report, then the following destination will be opened:

The only meaningful text file here is lvlog.txt which looks like this (some strings skipped):

####
#Date: Mo, 18. Mrz 2024 11:03:35
#OSName: Windows 10 Enterprise 
#OSVers: 10.0
#OSBuild: 19045
#AppName: Crash
#Version: 24.1.1f1 32-bit
#AppKind: AppLib
#AppModDate: 3/18/2024 10:03 GMT
#LabVIEW Base Address: 0x7AAF0000

//SKIPPED
<LVExec>
{"a":[
{
"vi": "C:\\Users\\..\\Desktop\\LV_Crash\\builds\\Crash\\Crash\\Crash.exe\\Crash.vi",
"ctx": "Hauptanwendungsinstanz",
"type": "topVI"
}
] }
</LVExec>

<DEBUG_OUTPUT>
18.03.2024 11:03:40.239
Crash 0x00000000: Crash caught by NIER
ExceptionCode: 0xC0000005
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
ExceptionCode: 0xC0000005
[ExecSys:0; Executing:"[VI "Crash.vi" (0x0e1d0040)]"]minidump id: 6a778680-7890-43cf-b0b8-3fe86f7757e1

</DEBUG_OUTPUT>

0x74F4161F - nierInterface <unknown> + 0
0x74F464E4 - nierInterface <unknown> + 0
0x74F45863 - nierInterface <unknown> + 0
0x750036FA - mscoreei <unknown> + 0
0x10009B12 - nilm_LabVIEW_080000 <unknown> + 0
0x77CB4821 - ntdll <unknown> + 0
0x77C77C2E - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0

VI call stack:
- Crash.vi

So, here we have the name of crashed VI, but not DLL. In additional to text file we have also minidump, which can be opened in any suitable tool, for example, if you have Microsoft Visual Studio installed, then by default minidump will be opened here:

and if you will hit "Run Diagnostic Analysis"m, then you will see DLL caused this exception:

Alternatively you can open minidump also in Windows Debugger if you haven't Visual Studio installed and after run analyze -v command you will see the same:

Or you can run your application under debugger — WinDbg or any other debugger like x64dbg (attach to executable), then when I hit "Crash" Button in LabVIEW, then application will be crashed into my hands and you can see assembler code caused this (in our case attempt to read address 0x1 and put to eax, which is register for returned value):

If you haven't source code of DLL, this makes almost no sense, but sometimes helpful as well. 

Important to understand how exception is handled by Windows, in case of NI software its handled by structured Exception Handler, which is running here:

We can kill nierserver.exe, then this exception will be handled by Windows, and then when crashed you will not see dialog about report, instead of that you will get entry in Application Log, which can be viewed by Event Viewer:

Good point, the the name of the DLL caused this will be also written as you can see on the screenshot above.

The minidump will be also created, but in other CrashDumps  folder:

(can be analyzed in WinDbg as well, of course).

And the last point - if we will enable error checking and set error handling to maximum (Default also will work in this case):

The the LabVIEW will try to handle this exception and then set error code 1097 instead of "hard crash":

(how the application will run after this, its another question, but at least in this particular case this works. It is not guaranteed that any kind of exception will be handle successfully, so it may not work for other exceptions). This is not normal behavior and needs be fixed at source code level, my recommendation - never go into production with application caused error 1097 on any DLL calls.

Hope it helps for understanding a little bit.

[Josh2212]

Thank You @Andrey_Dmitriev,

This helped me to figure out which vi was causing the crash. That particular vi was reimported from library and now everything works fine.