Unzulässiger Zugriff auf Speicherbereich

(12.10.2012 10:13 )stud12 schrieb:  DLL ist meiner Meinung nach korrekt installiert. Genau so gemacht wie beschrieben. dll und llb hab ich in einem Ordner, desweiteren gibts noch ne .ini und ne .sys im entsprechenden system32-Unterverzeichnis, damit dass ganze übern USB-Port fehlerfrei läuft.
Das Gerät war eines der ersten. Firmware immer noch die von damals, Updates wären nur noch nach Kontakt mit Hersteller möglich (siehe die von dir angegebene Website). Treiber sind ebenfalls die damals zugehörigen.

Es gibt eine Anwendung (.exe) die läuft egal wie oft ich sie ausführe und wie oft ich die Anwendung schließe und neu starte; ich kann immer die Lichtquelle ansteuern.
Genau die gleiche Anwendung is im Treiberpaket nochmals als .vi enthalten (halt nur nich in .exe umgewandelt), und hier genau das selbe Problem: einmal läufts, dann will LabVIEW beim Beenden, dass ich alle darin enthaltenen Funktionen neu abspeichere (auf die 2011er Version). Beim nächsten Start funktionierts nich mehr.
Auch andersrum würde es nich klappen, sprich Programm öffnen, gleich wieder schließen und vorher die Funktionen konvertieren. Dann Programm neu öffnen, einmal starten und wieder schließen. Beim nächsten Mal tritt dann der Fehler auf. Es scheitert also immer die zweite Ausführung des Programmes. Das Konvertieren scheint keinen Einfluss zu haben, weil ichs nach Variante 2 ja auch zumindest einmal ausführen kann.

Vielleicht helfen euch diese Infos weiter:
Info1:
Wenn ich das nun funktions-unfähige VI lösche und durch das gleiche ersetzte, welches ich noch in nem Backup-Ordner drin hab, dann bietet sich mir zunächst nochmal die Möglichkeit, die zugehörige dll über ein Dialogfeld auszuwählen, bekomme dann aber wenn er die dll für das neue programm laden will die Fehlermeldung: "Eine DLL-Initialisierungsroutine ist fehlgeschlagen"

Info2:
die .exe-Datei läuft weiter problemlos, obwohl ich im Dialogfeld bein Programmstart jedesmal die selbe DLL auswähle, die auch versucht wird aufzurufen, wenn das VI geladen wird (dann aber halt mit Fehlermeldung "Unzulässiger Zufriff auf einen Speicherbereich").... und das wundert mich am meisten...

Das sieht nach einer ActiveX DLL aus, oder zumindest macht sie intern Gebrauch von ActiveX und die Programmierer dieser DLL haben die Feinheiten von der Verwendung von ActiveX innerhalb eines miltithreaded Programmes noch nicht ganz begriffen. LabVIEW ist grundsätzlich multithreaded und die einzige Möglichkeit um das beim Aufruf einer DLL zu verhindern ist um alle Call Library Nodes so zu konfigurieren dass diese im UI Thread ausgeführt werden. Das kann aber je nach Situation wieder andere Probleme mit sich mitbringen. Da ich die entsprechende DLL nicht kenne kann ich das nicht beurteilen, aber grundsätzlich lässt sich sagen, dass die verwendete ActiveX Componente wahrscheinlich als sogenannte Apartement Threading DLL registriert ist. Das besagt im wesentlichen dass die Aufrufe in die ActiveX Server DLL immer vom gleichen Thread aus erfolgen müssen. Die einzie Art und Weise um das in LabVIEW zu garantieren ist um entweder in der Wrapper DLL selber diese Threadsynchronisation zu tun (aber das ist noch schwieriger dann eine ActiveX Componente zu schreiben die echt Free-Threading ist), oder aber in LabVIEW all Call Library Nodes so zu konfigurieren dass sie im UI Thread ausgeführt werden (dann macht LabVIEW das Ganze mit der Einschränkung dass es im speziellen UI Thread passiert und wenn die DLL oder ActiveX Komponente sich selber dabei blockiert auch LabVIEW komplet unbedienbar wird.

Grundsätzlich ist einfach zu sagen dass der Treiberhersteller die Feinheiten von Multithreadingprogrammierung zumindest noch nicht ganz begriffen hat. In Visual Basic läufts ja, also ist LabVIEW das Problem!!! Aber er vergisst dabei dass die meisten Visual Basic Programmierer nicht mal in die Nähe von Multhreading Programmen kommen und seine schöne Komponente halt einfach grundsätzlich Singelthreaded angesprochen wird, somit dass Problem nicht darin liegt dass LabVIEW grundsätzlich Multithreaded ist, sondern darin dass seine Componente mit multithreading Probleme hat.