Labview Crashing but don't know why

[HobieTcat]

Hello,

We are having a problem with Labview crashing. Here are some screen shots of the messages that pop up. Can anyone help point me in a direction to figure out why this is happening? I don't know what these messages are saying. The project is a few months old and near completion. This problem started recently but I don't think anything new has been added, just more of the same that seemed to work before. Labview will run for a while, sometimes a few minutes, sometimes a few hours, but this message keeps popping up after the crash.

This is the report:

####
#Date: Thu, Oct 12, 2023 5:49:14 AM
#OSName: Windows 10 Enterprise
#OSVers: 10.0
#OSBuild: 22621
#AppName: LabVIEW
#Version: 23.1f276 32-bit
#AppKind: FDS
#AppModDate: 1/27/2023 00:41 GMT
#LabVIEW Base Address: 0x00860000

InitExecSystem() call to GetCurrProcessNumProcessors() reports: 20 processors
InitExecSystem() call to GetNumProcessors() reports: 20 processors
InitExecSystem() will use: 20 processors
Launching resource generator using command: C:\Program Files\NI\LVAddons\nilvfpgahostcomm32\1\Targets\NI\FPGA\bin\gen_res_cache_lvaddons.exe -m "C:\Users\GaryTurell\Documents\LabVIEW Data\2023(32-bit)\FPGATargetData\resource_cache_manifest.txt"
starting LabVIEW Execution System 2 Thread 0 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 8 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 9 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 10 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 11 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 12 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 13 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 14 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 15 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 16 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 17 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 18 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]
starting LabVIEW Execution System 2 Thread 19 , capacity: 30 at [3779956160.13363838, (05:49:20.133638382 2023:10:12)]

<DEBUG_OUTPUT>
10/12/2023 9:10:10.638 AM
Crash 0x00000000: Crash caught by NIER
ExceptionCode: 0xC0000005
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
ExceptionCode: 0xC0000005
[ExecSys:none]minidump id: d7475a70-b818-4654-b937-64f36be9cf68

</DEBUG_OUTPUT>

0x6C8A161F - <unknown> <unknown> + 0
0x6C8A64E4 - <unknown> <unknown> + 0
0x6C8A5863 - <unknown> <unknown> + 0
0x1CB4FDB4 - <unknown> <unknown> + 0
0x7772BDCD - <unknown> <unknown> + 0
0x7772BCBF - <unknown> <unknown> + 0
0x00000000 - <unknown> <unknown> + 0

[ZYOng]

Usually, the first thing I will do is look for any possible memory leak. See Monitor Execution Time and Memory Usage in LabVIEW VIs and Using the Profile Performance and Memory Window

The default crash dump usually does not provide enough information to find the root cause of the issue. You would need Obtaining a WinDbg Dump File to Troubleshoot Crashes in NI Software for more details.

[Bob_Schor]

---

@HobieTcat wrote:

This problem started recently but I don't think anything new has been added, just more of the same that seemed to work before. Labview will run for a while, sometimes a few minutes, sometimes a few hours, but this message keeps popping up after the crash.

---

Are you using Version Control?  If so, load a "slightly older" version and see if the problem is present.  If it "goes away" with older code, then comparing Old (working) and New (crashing) codes might give you a hint.

Another thing to try is the same code, but on LabVIEW 2022 or 2021, or the same code with the same version of LabVIEW but on another PC.

"We apologize for the inconvenience", at least sometimes, is a bug in LabVIEW.  My first suggestion is trying to "tiptoe" around the bug, while my second suggestion is "maybe the bug really is in LabVIEW, so try to find a "bug-free" LabVIEW system.

Bob Schor

[JÞB]

From the dump report I see you are running Win 10 Enterprise.  My FIRST thought would be to see if your companies IT department recently pushed an update.  My second thought is Microsoft no longer supports Win 10 with updates...perhaps something bad got in. 

Either way, send the crash report to NI and follow up with a service request.  Let us know what you learn.

I'm also curious about the target CPU.  a 20 processor system seams a bit strange (but who knows) and it's at least notable that the crash happens immediately after thread index 19 starts.  Almost like it's trying to launch a funny thread. 

so some spitballing is warranted.  Is this crash on the original development machine or, did you pull it from SCC?  Does a mass compile help?  (Did you try one?)  Is Source code separated?  Did you try to clear the compiled object cashe?  What have you tried?

[*3d0g]

I've experience that fateful display pop-up when my dll is wrong.

I couldn't swear to it, but I think it happened when I tried to run a debug build rather than a release build as my dll.  this was a Visual Studio build, not LW/CVI as I recall.

misconfiguration of a dll causes it too, I think.

perhaps you introduced new code that contains CLFNs? maybe? check the c vs winapi setting on it.

[HobieTcat]

Thanks to everyone that replied, there were some interesting ideas, after going through some of the suggestions it appears that the problem is with a third party VI I am trying to use. Unfortunately, it is still happening and I can't seem to trap the error before it crashes Labview. We have decided to not use the suspect VI and so I won't be working on it anymore to find a solution so I can't post any useful findings. If anything on that changes I will post what we find.

[Yamaeda]

The final row looks like a Null reference error. There are many things that can cause that. Maybe something hasn't had time to initialize or have already been killed?

[wiebe@CARYA]

"Labview will run for a while" doesn't inform us if LabVIEW is running for a while, or if your program is running for a while.

When exactly does LV crash?

While running your code? After a while? Any particular part you can limit it to?

During editing?

During compiling your FPGA code?

As the dump mentions cache, and because you say it started without adding anything, I'd definitely try clearing the compile caches ,and maybe cleaning up your FPGA build directory completely.