+1 800 256 3608 (toll-free in North America) or +49 7531 90 60 10| service@combit.com

Crash bei AutoExport LL21


(Nikolaus Kern) #1

Hallo,

in meinem Programm gibt es die Möglichkeit, Berichte zeitgesteuert nach bestimmten Ereignissen zu erstellen. Dabei wird ein PDF Export in ein Verzeichnis geschrieben.

Dabei tritt eine AccessViolationException an folgender Stelle auf:
public virtual void CreateDataSources()
{
this._report = new ListLabel();
this._report.LicensingInfo = this._licenseKey;

}

Der Stacktrace dazu sieht wie folgt aus:
bei combit.ListLabel21.NativeMethods.LlSetOptionString32(Int32 hLlJob, Int32 nIndex, String pszBuffer)
bei combit.ListLabel21.LlCore.LlSetOptionString(LlOptionString option, String value)
bei combit.ListLabel21.ListLabel.set_LicensingInfo(String value)
bei Bauradar.Reports.BaseListLabel.CreateDataSources() in D:\Software Development\Bauradar Experimental\Bauradar.Common\Reporting\BaselListLabel.cs:Zeile 142.
bei Tauschek.CR16.CreateDataSources() in D:\Software Development\Tauschek\CR16 Arbeitseinteilung.cs:Zeile 82.
bei Tauschek.CR16.AutoExport(ExportConfiguration exportConfig, Int32 range, List`1 orgs) in D:\Software Development\Tauschek\CR16 Arbeitseinteilung.cs:Zeile 338.
bei Bauradar.Basics.DelayedReportGenerator.RunAutoExport(Object sender, EventArgs e) in D:\Software Development\Bauradar Experimental\Bauradar.Basics\Services\DelayedReportGenerator.cs:Zeile 72.
bei System.Windows.Threading.DispatcherTimer.FireTick(Object unused)
bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
bei System.Windows.Threading.DispatcherOperation.InvokeImpl()
bei System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object state)
bei MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(Object obj)
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.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
bei MS.Internal.CulturePreservingExecutionContext.Run(CulturePreservingExecutionContext executionContext, ContextCallback callback, Object state)
bei System.Windows.Threading.DispatcherOperation.Invoke()
bei System.Windows.Threading.Dispatcher.ProcessQueue()
bei System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
bei MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
bei MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
bei System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
bei MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
bei MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
bei System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
bei System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
bei System.Windows.Application.RunDispatcher(Object ignore)
bei System.Windows.Application.RunInternal(Window window)
bei System.Windows.Application.Run(Window window)
bei System.Windows.Application.Run()
bei AppFact.Shell.LOB.App.Main() in D:\Software Development\Bauradar Experimental\Bauradar.Shell\obj\Debug\App.g.cs:Zeile 52.

Bitte um Rückmeldung zu den möglichen Ursachen und deren Behebung.

Danke

Schöne Grüße

Nikolaus Kern

PS: Ein Ticket mit der Meldung eines vermuteten Produktfehlers war nicht möglich, weil LL21 nicht mehr aktuell sei ?!


(Oliver Hambrecht) #2

Hallo,

wie es aussieht, wird der Druck/Export threaded ausgeführt. Da ist es dann wichtig, dass das verwendete ListLabel-Objekt im Thread erzeugt, verwendet und zerstört wird. Dabei gilt aber auch zu beachten, dass man in der App einen Schutzjob haben sollte, um native System-Ressourcen etc. vorzuladen. Sollte aber hier im Artikel erklärt sein:
https://www.combit.net/reporting/support/list-label-knowledgebase/knowledgebase/allgemeine-hinweise/multithreading-mit-list-label/

Vielleicht hilft das bereits weiter?

Beste Grüße


(Nikolaus Kern) #3

Hallo Oliver,

danke für die Rückmeldung.

Im ersten Schritt habe ich einmal überprüft, ob der Report im gleichen Thread erzeugt und zerstört wird. Das ist der Fall.

Den Artikel in der Knowledgebase habe ich einmal so verstanden, dass mit “Schutzjob” ads Erzeugen eines LL Objektes gemeint ist. Vor dem Erzeugen eines Reports überprüfe ich, ob das statische Property ListLabel in einer statische Klasse existiert. Ist das nicht der Fall, erzeuge ich das statische Property. Die LicenseInfo setze ich damit im gesamten Code nur 1x bei dem statischen Property. Alle anderen Berichte bekommen die licenseinfo nicht mehr gesetzt.

Interessant ist, dass der Crash beim Schreiben der Lizenzinformation auftritt, was im unmanaged code erfolgt. Was passiert da genau?

MfG

Nikolaus Kern