Hallo, ich habe ein Problem mit der Umstellung unserer Applikation auf 64-bit (OS ist Windows 10 64bit).
Unsere App hat ca. 10 externe Komponenten die sich alle auf 64-bit umstellen ließen.
Nach der Umstellung unserer Druckausgabe startet noch das Preview-Fenster mit ausgegrautem Toolbar und unmittelbar danach kommt ‘FatalExecutionEngineError’.
Die richtige combit.ListLabel22.dll aus dem Redist/64 Verzeichnis wurde referenziert und die entspechenden 64 bit combit dll in das bin/debug Verzeichnis gepielt. DebWin4 zeigt auch keine Auffälligkeiten bis zur Exception.
Ich komme an dieser Stelle nicht mehr weiter und hoffe auf Hilfe - Danke
Hallo,
auf die Schnelle habe ich dazu im Inet nur das hier gefunden, was vermutlich nicht weiterhelfen wird:
FatalExecutionEngineError tritt auf, wenn Sie com-Aufrufe zusammen mit mehreren AppDomains ausführen
Also wenn LL22 eine Freigabe für Windows 10 hat würde ich mal schauen, dass das aktuelle bzw. das letzte Service Pack der Version 22 von List & Label auch zum Einsatz kommt. Mit welcher Version von LL22 kommt denn diese Meldung?
Da von “bin/debug” die Rede ist, vermute ich, dass das die eigene .NET Anwendung ist, richtig? Wie sieht es denn dann mit dem Release-Build aus? Kommt hier die gleiche Meldung?
Sollte es weiterhin ein Problem sein, sieht es für mich nach einem Fall für den Support von combit aus, wenn die Meldung aus dem Callstack der List & Label Module kommt.
Betrifft das denn auch die x86-Version der Anwendung auf dem gleichen System, oder klappt da 32-bittig alles prima?
Kannst ja mal versuche das vollständige Logfile von Debwin hier hochzuladen - vielleicht erkennt man ja etwas Spannendes. Sonst aber weiter an den Support von combit - gleich inklusive Logfile und ein DUMP am besten.
Hallo,
unsere Anwendung basiert auf .NET 4.7.
Die 32-bit Variante läuft problemlos.
An Release habe ich mich noch nicht getraut…
Der call stack:
| mscorlib.dll!System.Runtime.InteropServices.Marshal.PtrToStructure(System.IntPtr ptr, System.Type structureType) Line 992 | C# | |
|---|---|---|
| combit.ListLabel22.dll!combit.ListLabel22.ListLabel.GeneralLlCallback(short nMsg, System.IntPtr lParam, int lUserParam) | Unknown | |
| [Native to Managed Transition] | ||
| [Managed to Native Transition] | ||
| combit.ListLabel22.dll!combit.ListLabel22.LlCore.LlPrintWithBoxStart(combit.ListLabel22.LlProject projectType, string projectFile, combit.ListLabel22.LlPrintMode printMode, combit.ListLabel22.LlBoxType boxType, System.IntPtr windowHandle, string title) | Unknown | |
| combit.ListLabel22.dll!combit.ListLabel22.ListLabel.PrintReportFromRelationalDataSourceNewMode(combit.ListLabel22.DataProviders.IDataProvider dataSource, string projectFile, bool showFileSelect, combit.ListLabel22.LlPrintMode printMode, combit.ListLabel22.LlBoxType boxType, System.IntPtr windowHandle, string dialogTitle, bool showPrintOptions, string tempPath) | Unknown | |
| combit.ListLabel22.dll!combit.ListLabel22.ListLabel.AutoPrint(combit.ListLabel22.LlProject projectType, string projectFile, bool showFileSelect, combit.ListLabel22.LlPrintMode printMode, combit.ListLabel22.LlBoxType boxType, System.IntPtr windowHandle, string dialogTitle, bool showPrintOptions, string tempPath) | Unknown | |
| combit.ListLabel22.dll!combit.ListLabel22.ListLabel.Print(object userData, combit.ListLabel22.LlProject projectType, string projectFile, bool showFileSelect, combit.ListLabel22.LlPrintMode printMode, combit.ListLabel22.LlBoxType boxType, System.IntPtr windowHandle, string dialogTitle, bool showPrintOptions, string tempPath) | Unknown | |
| combit.ListLabel22.dll!combit.ListLabel22.ListLabel.Print(combit.ListLabel22.LlProject projectType, string projectFile, bool showFileSelect, combit.ListLabel22.LlPrintMode printMode) | Unknown | |
| combit.ListLabel22.dll!combit.ListLabel22.ListLabel.Print(combit.ListLabel22.LlProject projectType, string projectFile, bool showFileSelect) | Unknown | |
| > | … .PrintProvider.Print() Line 388 | C# |
Danke!
Nachtrag:
Der letzte Patch für L&L22 ist installiert, und diese Dll’s werden auch benutzt.
Der ‘Release-Build’ hat das selbe Problem.
So sieht es zum Zeitpunkt der Exception aus:
Ich denke, dass hier dann combit selbst ran muss. Würde dann auch gleich direkt das volle Debwin-Log und auch ein DUMP mit dem Callstack dazu packen. Mal sehen, ob da noch was gemacht werden kann… denn aktuell ist die Version 22 ja nicht mehr. Gut möglich, dass hier dann direkt LL26 verwendet werden sollte - da müssten noch Anpassungen möglich sein.