Fehler 1097 bei Aufruf C++ DLL

Tag zusammen,

ich versuche eine zugekaufte C++ DLL in LabVIEW per Knoten einzubinden. Dabei bekomme ich von LabVIEW immer wieder den Fehler "Fehler 1097 ist bei Knoten zum Aufruf externer Bibliotheken aufgetreten".

Bin mir nicht sicher ob die Parameter für die DLL Stimmen:

Der Eintrag in der Header lauetet:
A_API int EXP ReadEEPROM (int MasterID, LPCSTR *Content, FILE *Log);

Meine Funktionstyp in LabVIEW lautet (stdcall / Winapi):
int32_t ReadEEPROM(int32_t MAsterID, LStrHandle *Content, int64_t *Log);


Danke
Christoph

Anzeige

' schrieb:Der Eintrag in der Header lautet:
A_API int EXP ReadEEPROM (int MasterID, LPCSTR *Content, FILE *Log);

Meine Funktionstyp in LabVIEW lautet (stdcall / Winapi):
int32_t ReadEEPROM(int32_t MAsterID, LStrHandle *Content, int64_t *Log);

Rückgabewert und MasterID passen so. Bei *Content und *Log zweifle ich.

LPCSTR ist ein "const char*", also ein normaler PChar. Ein LPCStr* wäre also ein Pointer auf einen Pointer. Das geht in LabVIEW nicht - so einfach. LStrHande* ist ein Pointer auf einen Stringhandle. Ein Stringhandle ist aber was ganz was anderes als ein PChar.

FILE alleine ist bereits ein Pointer. File* wäre also schon wieder ein Pointer auf einen Pointer - was schon wieder nicht ginge. Bist du sicher, dass FILE ein I64 ist, kein I32?

' schrieb:FILE alleine ist bereits ein Pointer. File* wäre also schon wieder ein Pointer auf einen Pointer - was schon wieder nicht ginge. Bist du sicher, dass FILE ein I64 ist, kein I32?

Ich bin mir sicher das File ein I64 ist.

Seit der LV- Version 8 ist dieses als I64 zu definieren, bei vorhergendere Versionen war es ein I32.

' schrieb:Ich bin mir sicher das File ein I64 ist.

Seit der LV- Version 8 ist dieses als I64 zu definieren, bei vorhergendere Versionen war es ein I32.

Wer hat das gesagt? Das gilt allenfalls für 64 Bit Windows UND dann auch nur wenn es 64 Bit LabVIEW ist.

Hat jemand herausgefunden, wie das geht?
Ich habe dasselbe Problem

btw. ich hatte den gleichen Fehler beim Aufrufen einer DLL. Allerdings scheint die DLL dabei sogar korrekt ausgeführt worden zu sein (das was die gecallte Funktion machen sollte ist auch passiert). Verwirrt mich grade xD

Was jedenfalls (bei mir) geholfen hat ist die Aufrufkonvention von C nach stdCall zu ändern. Wenn mir jetzt noch jemand erklären könnte warum das geholfen hat wäre ich dankbar

Anzeige

(05.02.2014 14:26 )Kiesch schrieb:  btw. ich hatte den gleichen Fehler beim Aufrufen einer DLL. Allerdings scheint die DLL dabei sogar korrekt ausgeführt worden zu sein (das was die gecallte Funktion machen sollte ist auch passiert). Verwirrt mich grade xD

Was jedenfalls (bei mir) geholfen hat ist die Aufrufkonvention von C nach stdCall zu ändern. Wenn mir jetzt noch jemand erklären könnte warum das geholfen hat wäre ich dankbar

Bei cdecl räumt der Aufrufer den Stack auf, bei stdcall die Funktion selber. Wenn Du jetzt eine Funktion hast die stdcall compiliiert wurde und Du in LabVIEW sagst dass ist eine cdecl Funktion, dann raumt sowohl die Funktion als danach auch LabVIEW den Stack auf und der Stackpointer weist danach ins Chaos, sprich Crash/Absturz. Wenn Du in der Call Library Node Configuration das Error Handling nicht ganz ausschaltest, kann LabVIEW danach zwar erkennen dass etwas nicht mehr stimmt (und generiert deshalb den error 1097) aber der Pfusch ist schon geschehen und die einzige sichere Methode ist um LabVIEW neu zu starten wenn Du keine ganz hässlichen Nebeneffekte bis hin zu definitiv korrumpierten VIs provizieren möchtest.

Aber grundsätzlich ist zu sagen, nur weil die Funktion zu machen scheint was sie tun soll ist noch lange kein Beweis dass die Konfiguration nicht doch irgendwie nicht stimmt und irgendwo kein Speicher überschrieben wurde. Das kann sogar geschehen ohne dass LabVIEW das mit einem error 1097 erkennen kann.

gibt es denn Möglichkeiten (ausser "Hersteller" selbst fragen) rauszufinden welche Aufrufkonvention da wirklich verwendet wurde beim Kompilieren? Muss ganz ehrlich sagen, dass ich zwar etwas Ahnung vom C coden habe (und theoretisch sogar den Code der DLL auch habe), praktisch aber eigentlich nicht genug Ahnung um als mehr als nur Nutzer zu fungieren.

Hinzu kommt das zwar Wrapper VIs teilweise existieren, die allerdings für LV 4.X geschrieben wurden und zwar noch grundsätzlich funktionieren würden (konnte die irgendwann mal hochspeichern über nen Zwischenschritt auf LV 8.0 oder 8.2), aber quasi ne Blackbox sind da LV 2013 natürlich nix mehr mit der CIN node anzufangen weis... (sprich ich kann aktuell nichtmal nachprüfen wie die VIs eigentlich genau funzen). Außerdem haben die auch nicht den gesamten Funktionsumfang der DLL abgedeckt. Immerhin: Der DLL Aufruf mit stdcall scheint bisher tadellos zu klappen (auch bei längerer Laufzeit und mehrfachen aufrufen; konnte bei >3h laufzeit und >20 Aufrufe pro Sek) bisher noch keine negativen Nebeneffekte feststellen.

Gruß Kiesch

P.S: Danke auch schonmal für den kleinen theoretischen Oberbau. Lerne immer gerne dazu :-)

(24.02.2014 11:15 )Kiesch schrieb:  gibt es denn Möglichkeiten (ausser "Hersteller" selbst fragen) rauszufinden welche Aufrufkonvention da wirklich verwendet wurde beim Kompilieren? Muss ganz ehrlich sagen, dass ich zwar etwas Ahnung vom C coden habe (und theoretisch sogar den Code der DLL auch habe), praktisch aber eigentlich nicht genug Ahnung um als mehr als nur Nutzer zu fungieren.

Die einzige mir bekannte Alternative ist um den Code zu disassemblieren und im Assemblycode zu schauen ob die Funktion den Stack selber aufräumt oder nicht. Nicht gerade eine Methode die ich einem normalen Programmierer empfehlen würde.

Da Du den C Code zur DLL hast ist das aber nicht nötig. Man muss dann nur im C Code schauen ob es entsprechende Definition __cdecl oder __stdcall vor den Funktionsdeklarationen hat. Hats die nicht muss in der dazugehörigen Projectdatei geschaut werden welche default calling convention da gewählt wurde. Visual C verwendet Standard cdecl wenn man im Project nichts ändert.

Boah. Nach langem suchen doch noch fündig geworden. Die Funktionen enthalten in der Declaration "APIENTRY", was laut Google heist das die über "WINAPI" und daher mit stdcall aufgerufen werden wollen. Nu hab ichs dann hoffentlich also komplett verstanden. Danke für die kompetente Hilfe

Gruß Kiesch