LabVIEW 2018 64 Bit Crash

[Nambu123]

Hey everyone,

I recently experienced a complete crash of LabVIEW 2018 64bit while running my AF based program. The crash happened two times within a month, the program is usually running 24/7. LabVIEW itself just closed without any error message, in the windows event log if found the following:

Faulting application name: LabVIEW.exe, version: 18.0.0.4012, time stamp: 0x5ba07d6b
Faulting module name: dfir_18_0.dll, version: 18.0.0.49152, time stamp: 0x5a993fbb
Exception code: 0xc0000005
Fault offset: 0x00000000001ded53
Faulting process ID: 0x3acc
Faulting application start time: 0x01d4f52a8a92ef89
Faulting application path: C:\Program Files\National Instruments\LabVIEW 2018\LabVIEW.exe
Faulting module path: C:\Program Files\National Instruments\LabVIEW 2018\resource\dfir_18_0.dll
Report ID: 03d30985-50c5-41e7-b64d-50dc6d46c8e0
Faulting package full name: 
Faulting package-relative application ID: 

The error log is the same for both times the program crashed. Does anyone have an idea what dfir_18_0.dll is related to?

My the AF program contains around 50 modules and since the crash happens this rarely it is very hard to track down. Any help is highly appreciated!

[Bob_Schor]

I'd bump this up to NI Support!  This DLL seems to be a part of the LabVIEW Run Time environment which I hope would be more-or-less crash-resistant.  The fact that it is 64-bit LabVIEW might make it a little more of a problem, but NI will probably have to be involved (it's inside their code, not yours).

Bob Schor

[wiebe@CARYA]

DFIR is an intermediate compile step, between LabVIEW Heap and LLVM...

Knowing a bit about what you're doing would help.

I haven't seen this in 18 (just started using it), but in 13 class hierarchies with recursive containment did get corrupt easily. The recursion would just not work anymore, although no errors are given at first, after a few runs LV would crash.

My solution is to change the CP somehow (disconnect the error in) of reentrant VIs of the parent. That triggers a change that usually fixes it for me.

[altenbach]

---

wiebe@CARYA wrote:

DFIR is an intermediate compile step...

---

That confused me too. A running program should not even involve DFIR.

[Kyle97330]

---

@altenbach wrote:

---

wiebe@CARYA wrote:

DFIR is an intermediate compile step...

---

That confused me too. A running program should not even involve DFIR.

---

Is there anywhere in your code that loads VIs dynamically from disk that might not be in memory?  Since you're not running an EXE, you might be doing this. 

If you dynamically load a VI and it needs to be recompiled, then it might need to use this DLL during a running program.

[wiebe@CARYA]

---

@altenbach wrote:

---

wiebe@CARYA wrote:

DFIR is an intermediate compile step...

---

That confused me too. A running program should not even involve DFIR.

---

I think my recursive composite problem gave a DFIR error. It don't seem to be there in 2018 though.

It could be that DFIR is also used to resolve types during run time?

I'd try the usual things, like clear the compile cash (esp. if separate compiled code is on) and force a recompile of the code.

If it happens that rare, is there anything that is expected to execute that rare? If something execute once a month, and it crashes every time, the situation is quite different then something running steadily 100% of the time, and crashes 0.001% of the time.

[thols]

The reported LabVIEW version is 18.0.0.4012. Does that mean it is not SP1? I had lots of strange crashes in built apps in 18.0 but SP1 fixed them all. At that time I suspected VIMs to be causing them, and calling code that should have been recompiled but didn't. 

So, make sure you have the latest LV18 patch and see if that helps.

[Nambu123]

Tanks for all the reply's! I will try some of the suggested solutions like recompiling everything and also definitely upgrade to SP1, that is a very good point. I hope this will already fix the issue.

I am indeed loading all of my actors dynamically from disk, however all the required modules only load once when the program is launched. Afterwards the program runs in a periodic cycle with a duration of 8 seconds that controls an experiment. In each cycle some data is acquired and saved to disk. I never noticed any memory leaks. The crashes happened after hours of run-time with no input at all to the program.

[Bob_Schor]

Ha!  Here it is almost May, when LabVIEW 2019 should be released, and I realized I'm not running 2018 SP1, but 2018f2.  Why?  What happened to NI Update?  So I ran it "manually", and it's about to install 2017 SP1, 2018 SP1, and a bunch of Module SP1 updates ...

Thanks for the reminder ...

Bob Schor

[thols]

---

@Bob_Schor wrote:

Ha!  Here it is almost May, when LabVIEW 2019 should be released, and I realized I'm not running 2018 SP1, but 2018f2.  Why?  What happened to NI Update?  So I ran it "manually", and it's about to install 2017 SP1, 2018 SP1, and a bunch of Module SP1 updates ...

Thanks for the reminder ...

Bob Schor

---

That happened to me too. I thought maybe I had done something to mess up the NI update service. Anyone else experiencing it? I pulled my hair for two months with inexplicable crashes until I manually updated. (periodic check is on and it is on at a time when the pc is on. I have not seen it running for a long time)