Handle-Leck in LabVIEW-Applikation - Verdacht auf Versionskonflikt bei NI-DLLs

[SvenBittl]

Hallo zusammen,

ich hoffe, mir kann jemand bei einem hartnäckigen Problem mit meiner LabVIEW-Anwendung helfen. Die Applikation friert nach längerem Betrieb ein und reagiert nicht mehr.

Nach einer ersten Analyse habe ich folgende Auffälligkeiten festgestellt:

• Problem: Die Anwendung zeigt ein konstantes Handle-Leck, wie ich mit dem Process Explorer beobachten konnte. Die Anzahl der Handles steigt sporadisch, bis die Anwendung nicht mehr reagiert.

• Diagnose: Mithilfe von listdlls.exe habe ich die geladenen DLLs überprüft und bin auf eine mögliche Versionsinkonsistenz gestoßen.

Hier die relevanten Informationen zu den geladenen NI-DLLs:

• lvrt.dll (LabVIEW 2020 Run-Time Engine)

  • Version: 20.0.1.4000

• NILVRuntimeManager.dll

  • Version: 20.0.1.49152

Obwohl beide DLLs die Hauptversion 20.0.1 haben, weichen die Build-Nummern stark voneinander ab.

Meine Frage an die Community:

Hat jemand ähnliche Erfahrungen mit einem Handle-Leck in einer LabVIEW-Anwendung gemacht, das möglicherweise auf eine solche Versionsdifferenz zurückzuführen ist? Gibt es bekannte Inkompatibilitäten zwischen diesen spezifischen Builds von lvrt.dll und NILVRuntimeManager.dll?

Über jeden Tipp oder Hinweis, wie ich dieses Problem beheben kann (z. B. durch ein Update oder eine saubere Neuinstallation), wäre ich sehr dankbar.

Vielen Dank im Voraus!

[GerdW]

Hallo Sven,

wenn du hier im im weltweiten LabVIEW-Board schreibst, dann besser auf Englisch…

---

@SvenBittl wrote:

Die Applikation friert nach längerem Betrieb ein und reagiert nicht mehr.

Über jeden Tipp oder Hinweis, wie ich dieses Problem beheben kann (z. B. durch ein Update oder eine saubere Neuinstallation), wäre ich sehr dankbar.

---

Maybe the "handle leakage" has its reasons in your program?

Atleast I don't think it will be related to build revisions of LV-RTE and LVRunTimeManager DLLs…

[SvenBittl]

Hello everyone,

Thank you again for your feedback. I have analyzed the matter in more detail and have come across some other very specific details. The application crashes after about 19 hours of runtime.

• Handle and memory distribution: The strangest thing is that the application starts with over 8616 event handles. The total number of handles is also very high, and the private bytes also increase over time. I've attached a screenshot that shows the distribution. Is such a high number of event handles normal?

• Other findings: I also found out that Runtimes from 2021 and 2023 are additionally installed on the system, even though the application should be using the 2020 version.

• Reason for the crash: An analysis of the crash report shows that a background process is stuck in the NtUserMsgWaitForMultipleObjectsEx function - this seems to happen when too many handles are open.

I suspect that the different installed runtimes are getting in each other's way and are causing the application to start with this huge number of event handles, which then leads to the crash.

Has anyone here ever experienced such a distribution or a similar problem? Any help would be great.

Thank you!

[Quiztus2]

Did you start and stop your application already with DETT running? This is what I would use.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kJh6SAE&l=en-GB