Access Violation nach mehrmaligem Aufruf und Abbruch des Druckdialoges

Nach mehrmaligem Aufruf und Abbruch des Druckdialoges bekomme ich eine Access Violation Exception mit folgendem Stack trace :

   bei combit.ListLabel24.NativeMethods.LlSetOptionString64(Int32 hLlJob, Int32 nIndex, String pszBuffer)
   bei combit.ListLabel24.LlCore.LlSetOptionString(LlOptionString option, String value)
   bei combit.ListLabel24.ListLabel.set_LicensingInfo(String value)
   bei Geraeteliste.MainForm.PrintBackgroundWorker_DoWork(Object sender, DoWorkEventArgs e) in C:\Users\faller\source\Workspaces\Arbeitsbereich\Geraeteliste\Geraeteliste\MainForm.cs:Zeile 328.
   bei System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
   bei System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)
   bei System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
   bei System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
   bei System.Threading.ThreadPoolWorkQueue.Dispatch()

Folgenden Code in einem BackgroundWorker verwende ich :

private void PrintBackgroundWorker_DoWork(object sender, DoWorkEventArgs e)
    {
        ListLabel ll = new ListLabel();
        ll.LicensingInfo = llLicensingInfo;

        //ll.DataSource = ((BindingSource)e.Argument).DataSource as Geraeteliste.KonsolidierungMigrationDataSet;
        ll.SetDataBinding(((BindingSource)e.Argument).DataSource);

        ll.AutoDestination = LlPrintMode.Normal;
        ll.AutoProjectFile = @".\geraeteliste.lst";
        ll.AutoShowSelectFile = false;

        //ll.Design();

        try
        {
            ll.Print();
        }
        catch(combit.ListLabel24.ListLabelException ex)
        {
            System.Diagnostics.Debug.WriteLine(ex.Message);
        }
    }

Hallo Herr Faller,

verwenden Sie in Ihrer Anwendung einen Schutzjob? Ggf. könnte es helfen (falls Sie keinen verwenden) Ihre Anwendung um diesen zu erweitern. Nähere Informationen hierzu können Sie unserem Knowledgebase-Artikel “Multithreading mit List & Label” unter:

oder unserer .NET-Online Hilfe unter:
https://docu.combit.net/net/de/#Multithreading%20and%20Protection%20Job.html
entnehmen.

Sollte unser Vorschlag keine Abhilfe schaffen, benötigen wir zur Klärung weitere Informationen von Ihnen, die auf dieser Plattform nicht sinnvoll ausgetauscht werden können. Gerne können Sie in unserem Supportportal unter https://www.combit.net/supportportal/ einen Support-Case eröffnen, bitte kopieren Sie dabei die relevanten Informationen aus diesem Thread in die Beschreibung und übermitteln Sie uns zusätzlich noch die Dump-Datei.

Hallo

ich habe einen ziemlich komplizierteren Dataprovider (als oben im Beispiel?)
und eine bekomme nach 2 Aufrufen ein [Access Violation] -Fenster von LL heraus und einen Absturz der Anwendung. Es wird ein Log erzeugt:

2019-08-02, 10:12.21.873 CMUT24.DLL >>>========================= 02.08.2019, 10:12:21
2019-08-02, 10:12.21.884 CMUT24.DLL Exception code: 0xc0000005 (Access Violation)
2019-08-02, 10:12.21.900 CMUT24.DLL Registers:
2019-08-02, 10:12.21.910 CMUT24.DLL EIP: 0x278500a9
2019-08-02, 10:12.21.919 CMUT24.DLL EAX: 0x278500a9, EBX: 0x3baa6604, ECX: 0x00000000, EDX: 0x00000000
2019-08-02, 10:12.21.927 CMUT24.DLL ESI: 0x4aef09a8, EDI: 0x00000000, ESP: 0x3baa6198, EBP: 0x3baa61c0 (Stack Range: 0x3bab0000…0x3ba9d000)
2019-08-02, 10:12.21.937 CMUT24.DLL CS: 0x0023, DS: 0x002b, ES: 0x002b, FS: 0x0053, GS: 0x002b, SS: 0x002b
2019-08-02, 10:12.21.947 CMUT24.DLL Flags:0x00010246
2019-08-02, 10:12.21.956 CMUT24.DLL Code environment:
2019-08-02, 10:12.21.967 CMUT24.DLL 27850060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-08-02, 10:12.21.977 CMUT24.DLL 27850070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-08-02, 10:12.21.988 CMUT24.DLL 27850080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-08-02, 10:12.21.998 CMUT24.DLL 27850090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-08-02, 10:12.22.008 CMUT24.DLL 278500A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-08-02, 10:12.22.017 CMUT24.DLL 278500B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-08-02, 10:12.22.027 CMUT24.DLL 278500C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-08-02, 10:12.22.037 CMUT24.DLL 278500D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2019-08-02, 10:12.22.046 CMUT24.DLL
2019-08-02, 10:12.22.057 CMUT24.DLL Die Informationen über den Ausnahmefehler wurden in die Datei ‘C:\Users\DANIEL~1.BRA\AppData\Local\Temp\COMBIT.LOG’ geschrieben.

Es gab vorher eine Warnung:
[API] CMLL24 : the parent window’s thread is not the current thread!

Ist die Warnung relevant bzgl. der hiesigen Thematik ?

Hallo,

bei einem Absturz im Code wie hier denke ich ist es besser direkt mit dem Support in Kontakt zu treten. Vielleicht vorher noch schnell sicherstellen, dass das aktuelle Service Pack verwendet wird und schauen ob es damit auch nachstellbar ist. Wenn ja, würde ich auch direkt ein vollständiges Debwin4-Log sowie ein Dump vom Absturz dazu packen, da man hier den Kontext nicht erkennt - also bei welchem Call mit welchem Parameter es Probleme gibt. Die Warnung im Log kann wichtig sein, muss aber nicht… ist aber doch sehr speziell.

Dennoch, weil es mich neugierig macht und @hwysoszynski darauf bereits hingewiesen hat:

  • Wird denn im Thread gedruckt?
    • Wenn ja, muss auch in diesem Thread das List & Label erstellt werden!
  • Wird ein Schutzjob verwenden?

Hallo

wir hatten den “Schutzjob” nachträglich hineingemogelt, irgendwie hat er nicht gezogen. Nachdem ich da etwas umstrukturiert habe, ist das Fehlerfenster erst mal weg (nach ü20 aufgepoppten Fenstern test).

Scheint es also doch gewesen zu sein.
Trotzdem nicht toll.

Wir können uns das gerne via Support noch genauer ansehen, wenn Sie möchten. Einen globalen Job empfehlen wir aber ohnehin zu verwenden - schon aus Performancegründen, da dann das ständige Laden und Entladen unserer DLLs vermieden wird. Für eine Analyse des ursprünglichen Absturzes würden wir - wie von @Oliver_Hambrecht geschrieben - eine Dump-Datei benötigen. Die Vorgehensweise ist hier beschrieben:

Diesen Thread würde ich dann aber zunächst als “gelöst” markieren.