Hallo zusammen,
eine meiner Applikationen stürzt in unregelmäßigen Abständen ab und zuletzt häufiger.
Laut der Ereignisanzeige von Windows 10 ist es immer die lvrt.dll und auch immer mit dem gleichen Fehleroffset:
0x0000000000302955
Kann ich mithilfe dieses Offsets herausfinden, welche Funktion dieser DLL beim Absturz aufgerufen worden ist?
Es handelt sich um LV2017 Sp1 x64
ciao Tom
Hallo Einzug,
was würde es dir helfen, wenn du wüsstest, das der MemoryManager ein Problem hatte?
Was macht dein executable? Was wird aufgerufen? Irgendwelche "dubiosen" DLL-Aufrufe?
Hallo Tom,
wie Gerd schon andeutet: Das Problem ist so ziemlich sicher nicht lvrt.dll
Die Ursache solcher Abstürze ist irgend eine andere DLL oder ein fehlerhafter Aufruf einer DLL Funktion aus deinem Programm heraus. Das kann irgendwo in deinem Programm sein und es kann ziemlich lange dauern, bis das zum Crash führt.
(18.10.2023 09:40 )dereinzug schrieb: [ -> ]0x0000000000302955
In deinem Falle dürfte der Ausnahmecode 0xC0000005 relevanter sein als der Ort der Ausnahme. Im Normalfall tippe ich zwar eher auf ein SW-Fehler in der Applikation als auf RT oder BS.
Bei 0xC0000005 steht oft, dass man die Datenausführungsverhinderung abschalten(!?) soll.
Google mal nach 0xC0000005, kuck wie das mit der Datenausführungsverhinderung abschalten funktioniert, probier es aus und sag Bescheid.
Hallo,
danke für die Hinweise soweit. Der Absturz lässt sich leider nicht direkt einem Programmteil zuordnen. In Sachen Fremd-DLLs schaut es eigentlich recht überschaubar aus.
Es wird eine DLL für einen 3D-Sensor aufgerufen, welche aber in der Vergangenheit nicht durch Probleme aufgefallen wäre.
Dann wird noch die advapi32.dll aufgerufen um Windows Umgebungsvariablen zu lesen.
Zur Datenausführungsverhinderung:
Ich habe mir das nun in einem Windows 10 20H2 angeschaut und dort lässt es sich selektiv schon mal nur für 32Bit-Applikationen deaktiveren.
Ich habe dann noch einen Kommandozeilen-Befehl gefunden, mit dem es sich generell abschalten liese, habe davon aber erstmal abgesehen.
Schade, dass es sich nicht genauer eingrenzen lässt.
Ich hatte vor Jahren mal eine abstürzende Applikation und über die dort genannte DLL konnte ich es Eingrenzen auf IMAQ Rotate in Kombination damit, dass sehr viele Overlays mitgedreht werden sollten (gut letzteres habe ich durch Tests dann herausgefunden). Ist mit LV2011 aufgetreten und dann aber auch erst mit LV2014 behoben worden. Hat mir zwar nichts mehr geholfen, mich dann aber doch gefreut, es in den Changelogs zu lesen.
(19.10.2023 14:34 )dereinzug schrieb: [ -> ]Es wird eine DLL für einen 3D-Sensor aufgerufen, welche aber in der Vergangenheit nicht durch Probleme aufgefallen wäre.
Was aber nicht heist, dass dort nicht die Ursache liegen könnte. Anderer compiler oder andere Einstellungen, andere CPU, anderen Betriebssystem, irgend eine Kleinigkeit geändert - und schwupp kann so etwas von "es lief doch jahrelang problemlos" plötzlich zu Problemen führen. Fehler bei DLL aufrufen in LabVIEW sind oft sehr schwierig lokalisierbar, weil es nicht reproduzierbar ist.
Zitat:Dann wird noch die advapi32.dll aufgerufen um Windows Umgebungsvariablen zu lesen.
Umgebungsvariablen werden doch über Funktionen aus Kernel32.dll abgerufen und Registry Einträge über Funktionen aus advapi32.dll
Kannst du das genauer beschreiben? Verwendest du dafür VIs von NI oder irgend etwas anderes? Ok, eigentlich egal - ich traue da auch den NI VIs nicht wirklich.
Zitat:Zur Datenausführungsverhinderung:
Ich glaube nicht dass es damit etwas zu tun hat. Es müsste schon eine ziemlich krude Software/DLL sein, die so etwas tut und es müsste gut reproduzierbar sein.
Zitat:Schade, dass es sich nicht genauer eingrenzen lässt.
Ich hatte vor Jahren mal eine abstürzende Applikation und über die dort genannte DLL konnte ich es Eingrenzen auf IMAQ Rotate in Kombination damit, dass sehr viele Overlays mitgedreht werden sollten
Ja klar, LabVIEW und die vielen Zusatzpackete haben auch Fehler, aber so schnell würde ich da nicht aufgeben. Die DLL Aufrufe abschalten und abwarten, was passiert. Es lässt sich schon eingrenzen. Ob du am Ende etwas dagegen tun kannst, ist noch mal eine eine andere Sache.