+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Bug Liste (/Forum-LabVIEW-Bug-Liste)
+---- Forum: LabVIEW 2010 (/Forum-LabVIEW-2010)
+---- Thema: Aufruf der user32.dll führt zum Absturz von Labview (/Thread-Aufruf-der-user32-dll-fuehrt-zum-Absturz-von-Labview)
Aufruf der user32.dll führt zum Absturz von Labview - aptiva - 19.10.2010 07:42
Hallo,
bin zur Zeit am Erstellen eines größeren Projekts und Labview beendet sich beim Aufruf der user32.dll mit der Funktion keybd_event komplett. In den Labview Versionen 8.6 und 2009 funktioniert das jedoch ohne Probleme. Diese Windows-Funktion hat die Aufgabe einen Tastendruck der Print-Screen Taste zu emulieren, damit ich dieses Bild im Anschluss aus der Zwischenablage entnehmen und abspeichern kann.
Kann bitte jemand diesen Bug verfizieren? Bzw. hat jemand eine Idee für das Lösen des Bugs?
Anbei ein Bild auf dem Block-Diagramm
[attachment=30009]
Vielen Dank im Vorraus
Aptiva
Aufruf der user32.dll führt zum Absturz von Labview - nookie - 19.10.2010 08:32
Hallo,
du kannst alternativ auch auf anderem Wege einen Screenshot machen.
lG nookie
[attachment=30012]
Aufruf der user32.dll führt zum Absturz von Labview - aptiva - 19.10.2010 09:31
Die Variante geht leider nicht, da ich nicht vom Frontpanel, sondern von einem anderen Programm einen Screenshot machen muss, das im Hintergrund läuft
Aufruf der user32.dll führt zum Absturz von Labview - rolfk - 13.12.2010 22:44
' schrieb:Hallo,
bin zur Zeit am Erstellen eines größeren Projekts und Labview beendet sich beim Aufruf der user32.dll mit der Funktion keybd_event komplett. In den Labview Versionen 8.6 und 2009 funktioniert das jedoch ohne Probleme. Diese Windows-Funktion hat die Aufgabe einen Tastendruck der Print-Screen Taste zu emulieren, damit ich dieses Bild im Anschluss aus der Zwischenablage entnehmen und abspeichern kann.
Kann bitte jemand diesen Bug verfizieren? Bzw. hat jemand eine Idee für das Lösen des Bugs?
Anbei ein Bild auf dem Block-Diagramm
[attachment=58978:LV_crash.JPG]
Vielen Dank im Vorraus
Aptiva
Könnte es sein dass Du in Deiner CLN den absoluten Pfad zu user32.dll hast stehen? Das das crasht ist nämlich ein bekanntes Problem und steht so auch in der Bugliste für 2010. Für DLLs im Systemverzeichnis (und wohl auch Windowsverzeichnis) muss man spezifisch NUR den DLL Namen einführen. Nach schliessen und wieder öffnen steht da zwar wieder der absolute Name aber solange man daran nichts editiert sollte noch immer der DLL Name alleine abgespeichert bleiben und dann crasht es nicht.
Aufruf der user32.dll führt zum Absturz von Labview - aptiva - 17.12.2010 13:34
Danke, werd das eben mal schnell ausprobiern...
Aufruf der user32.dll führt zum Absturz von Labview - aptiva - 18.01.2011 16:32
So habe es mal ausprobiert und verschiedenes andere auch.
Hilft leider nichts, LV crasht leider immer noch. Auch im NI-Forum wird von dem Problem berichtet:
http://forums.ni.com/t5/LabVIEW/Can-i-make...p/534790/page/4
Aufruf der user32.dll führt zum Absturz von Labview - toaran_ - 19.01.2011 10:33
Hallo
bei funktioniert es so ...
WindowsXP prof. LV2010
[attachment=31774]
gruß T
Aufruf der user32.dll führt zum Absturz von Labview - aptiva - 19.01.2011 11:28
Danke, der Vorschlag von toaran_ funktioniert. Er unterscheidet sich durch die Verwendung der Funktion "Run in any Thread" bei der Thread Option. Des weiteren sind die Eingangsdatentypen anders. Anscheinend hatte ich den Aufruf aus einem Beispiel aus dem LV Forum kopiert.
Die älteren LV-Versionen sind fehlertoleranter, da diese alte Vi auch in den LV Versionen 8.6 und 2009 funktioniert hat. Kann somit als gelöst betrachtet werden.
Fehlerursache ist somit, die Übergabe eines falschen Eingangsdatentypes in einen DLL-Aufruf führt zum Absturz von LabView...
Aufruf der user32.dll führt zum Absturz von Labview - rolfk - 19.01.2011 13:09
Also ich habe mir mal schnell die MSDN Dok angeschaut und Dein ursprünglicher Code war definitief falsch konfiguriert.
MSDN sagt dazu:
Code:
VOID WINAPI keybd_event(
__in BYTE bVk,
__in BYTE bScan,
__in DWORD dwFlags,
__in ULONG_PTR dwExtraInfo
);Man müsste also die Parameter als folgt definieren:
U8
U8
U32
Pointer sized integer
Die ursprüngliche Konfiguration verhaut durch die unterschiedlichen Parametergrössen den Stack, und WINAPI kann damit absolut nicht umgehen (wenn LabVIEW dazu nicht noch einen extra Stackframe und weitere Protection hinzufügt, was man in LAbVIEW 2010 mit dem Maximum Debug Level bei der Call Library Node erreicht), wobei die Funktion dann aber einen Fehler zurückgibt, da der Stack eigentlich zerschossen wurde. Und wenn man Pech hat kracht es auch trotz der extra Protection. Eigentlich ist das nicht Pech sondern Glück, denn auch wenn es auf der Entwickelmaschine in der CLN nur einen Fehler generiert statt zu krachen, kann das auf einem anderen System plötzlich doch in einen Crash enden.