.NET Service stürzt sporadisch ab - Hauptverdächtiger ADS-Kommunikation

chripf

Level-1
Beiträge
6
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

wir haben ein Problem: sporadisch stürzt der SCADA-Service unserer Anwendung ab. Unser Hauptverdächtiger ist die ADS-Kommunikation. Leider kommen wir nicht weiter.

Grundsätzliches:
- Unser SCADA-Service ist in .NET implementiert und läuft als Windows-Service.
- Die ADS-Kommunikation bauen wir über die von Beckhoff bereitgestellte .NET-Dll auf, das ganze entspricht in etwa den Beispielen auf der Webseite. Es gibt einige Notifications, geschrieben wird hauptsächlich in ein paar Buffer - nichts ungewöhnliches soweit.
- Lokal nutzen wir nur den Router von TwinCAT, die SPS läuft auf einem Hutschienen-PC (CX9020) von Beckhoff.
- TwinCAT-Version ist 3.1

Der Fehler:
Ein plötzlicher Absturz auf Grund einer ExecutionEngineException. Es sollte an sich praktisch jede Exception unserer Anwendung geloggt werden - in den Logs ist aber nichts zu sehen.
Im Windows-Eventlog findet sich die .NET-Runtime-Exception sowie der eigentliche Absturz mit einer Speicherzugriffsverletzung (Exception code 0x0000005).
Die SPS läuft unbehelligt weiter.

Trenne ich die Verbindung zur SPS, tritt der Fehler nicht mehr auf, aber das schränkt die Funktionsfähigkeit dann doch ein wenig ein...
Läuft die SPS auf dem lokalen PC, ist das Problem auch nicht nachzustellen.

Die Hypothese ist also, dass die Ads-Kommunikation aus irgendwelchen Gründen sich nicht mit dem Netzwerk verträgt.

Im Dump ist leider nicht all zu viel zu erkennen, das Ganze tritt offenbar beim Start bzw. beim Aufräumen eines Threads auf, fallweise ist ein Stacktrace zu erhalten, der zur AdsNotification führt. Meist aber gibt der Dump nichts her, bis auf den Threading-Context.


Hatte jemand schon mal Probleme dieser Art?

Christian
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Hauptproblem ist, dass der Stacktrace nicht viel hergibt.

Meist schaut er in etwa so aus:
Code:
	clr.dll!Thread::~Thread()  + 0x10a bytes	 	clr.dll!Thread::DecExternalCount()  - 0xcd3cd bytes	
 	clr.dll!Thread::OnThreadTerminate()  + 0x1e9 bytes	
 	clr.dll!DestroyThread()  + 0x84 bytes	
 	clr.dll!ThreadpoolMgr::WorkerThreadStart()  + 0x12468a bytes	
 	clr.dll!Thread::intermediateThreadProc()  + 0x49 bytes	
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes




Fallweise scheinen auch Aufrufe der Crypt-Dll beteiligt zu sein:

Code:
	ntdll.dll!_LdrpUpdateLoadCount2@8()  + 0x508e bytes	
 	ntdll.dll!_LdrpUnloadDll@8()  - 0x348e4 bytes	
 	ntdll.dll!_LdrUnloadDll@4()  + 0x4a bytes	
 	KERNELBASE.dll!_FreeLibrary@4()  + 0x82 bytes	
 	crypt32.dll!FreeDllWaitForCallback()  + 0x195 bytes	
 	crypt32.dll!ILS_WaitForThreadProc()  + 0x48 bytes	
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

Und in einigen Fällen ist sichtbar dass der Aufruf von einer Ads-Notification ausgeht:
Code:
	clr.dll!ThreadStaticHandleTable::AllocateHandles()  + 0x2d bytes	
 	[Managed to Native Transition]	
 	System.Core.dll!System.Threading.ReaderWriterLockSlim.TryEnterReadLockCore(System.Threading.ReaderWriterLockSlim.TimeoutTracker timeout) + 0x5f bytes	
 	System.Core.dll!System.Threading.ReaderWriterLockSlim.TryEnterReadLock(System.Threading.ReaderWriterLockSlim.TimeoutTracker timeout) + 0x38 bytes	
 	(...)
 	TwinCAT.Ads.dll!TwinCAT.Ads.TcAdsClient.NotificationReceiver.OnNotification(int handle, long timeStamp, int length, TwinCAT.Ads.Internal.NotificationEntry entry) + 0x10f bytes	
 	TwinCAT.Ads.dll!TwinCAT.Ads.Internal.TcAdsSyncPort.OnSyncNotification(int handle, long timeStamp, int length, TwinCAT.Ads.Internal.NotificationEntry entry, bool bError) + 0x153 bytes	
 	TwinCAT.Ads.dll!TwinCAT.Ads.Internal.NotificationMngt.OnSyncNotification(TwinCAT.Ads.Internal.QueueElement[] elements) + 0x1fa bytes	
 	TwinCAT.Ads.dll!TwinCAT.Ads.Internal.ServerCycleNotificationMngt.NotificationThread() + 0x2c3 bytes	
 	mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x6f bytes	
 	mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0xa7 bytes	
 	mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) + 0x16 bytes	
 	mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x41 bytes	
 	mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes	
 	[Native to Managed Transition]	
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes



Laut Microsoft-Support haben wir es höchst wahrscheinlich mit MemoryCorruption bzw. eventuell auch StackCorruption zu tun - die Ursache suchen wir noch.
Unser Service ist zu 100% in Managed Code umgesetzt und von daher laut MS-Support an sich gar nicht in der Lage ein Problem dieser Art zu verursachen.
 
Wir verwenden C#. Externe Dlls laden wir nicht (und haben auch eine StyleCop-Regel die genau das prüft).

Die Ausnahme stellt hier eben die TcAdsDll.dll dar - auch die laden wir allerdings nicht direkt, sondern verwenden den von Beckhoff bereitgestellten .NET-Wrapper. Nichtsdestotrotz wird in diesem dann natürlich über PInvoke auf die (C++)Dll zugegriffen. Daher auch die Vermutung, dass hier die Ursache liegt.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Das wäre aber schon sehr merkwürdig, wenn euer Problem mit der TcAdsDLL zusammenhängt. Ihr seit ja nicht die Einzigen die diese DLL einsetzen. Bei uns laufen dutzende Anwendungen damit und wir hatten bisher keine Probleme. Habt ihr eure Software auf mehreren (unterschiedlichen) Systemen getestet?
 
Der Fall ist in der Tat einigermaßen merkwürdig. Die Eingrenzung auf die Ads-Komponente kommt ja auch nicht nur von uns, sondern ist in recht intensiver Zusammenarbeit mit dem MS-Support entstanden.

Was ich noch vergessen habe zu erwähnen: da unsere SCADA-Prozess als Windows-Service läuft, mussten wir die Synchronisierung mit dem Haupt-Thread abschalten (TcAdsClient.Synchronize = false). Das ist aber auch schon die einzige Besonderheit, soweit ich das beurteilen kann.

Dass die Dll häufig eingesetzt wird ist uns bewusst - für die .NET-Komponenten gilt da allerdings ebenfalls (in wesentlich stärkerem Maß) und von seiten des MS-Supports wurden schon beträchtliche Anstrengungen unternommen. Ich halte einen Fehler im .NET-Framework für noch deutlich unwahrscheinlicher. Zudem ist das Problem nicht mehr reproduzierbar wenn ich die Ads-Notifications abschalte...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Beckhoff-Support sagt, dass die Dll recht häufig im Einsatz ist... - bislang haben wir aber auch zusammen mit dem Beckhoff-Support nichts konkretes gefunden.

Der Fehler ist recht heimtückisch. Mittlerweile haben wir Beckhoff ein System gegeben, auf dem der Fehler bei uns mehrmals pro Tag aufgetreten ist. Bei ihnen allerdings bislang kein einziges Mal.

Eine Vermutung ist daher auch, dass irgendwas aus dem Netzwerk das Problem verursacht. Im Wireshark-Trace konnten wir bis dato allerdings auch nichts auffälliges identifizieren.

Das Hauptproblem ist, dass der Fehler extrem unregelmäßig auftritt und wir nicht in der Lage sind, ihn auf Knopfdruck oder auch nur zuverlässig innerhalb kurzer Zeit zu verursachen. Wir sind also über jede Anregung froh wie wir das Ganze weiter eingrenzen oder auch nur zuverlässig auslösen können.
 
Naja wie schon gesagt. Ihr scheint da bisher ein Einzelfall zu sein. Hätte hier von uns schonmal jmd so ein Problem gehabt, würdest du sicher einen Beitrag dazu finden.
Ich hätte jetzt auch keine Idee wie ich dir weiterhelfen könnte :confused: .
Es wäre aber trotzdem nett, wenn du uns hier auf dem Laufenden hälst. Denn es interessiert mich schon was am Ende die Ursache ist und evtl. auch die Lösung dazu (wenn ihr hoffentlich fündig werdet).
 
D[...]da unsere SCADA-Prozess als Windows-Service läuft, mussten wir die Synchronisierung mit dem Haupt-Thread abschalten (TcAdsClient.Synchronize = false).[...]

Vermutung: da wird irgendwo ein Fenster geöffnet. Das ist für einen Service aber nicht erlaubt (Sicherheitslücke in Windows). Lasst mal euren Service als normales Programm im Hintergrund statt als Service laufen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das ist leider nicht die Ursache - wir haben das Ganze mal als Prozess gestartet, es tritt aber immer noch der Fehler auf.

Interessanterweise erhalte ich jetzt aber auch wenn das Programm als normaler Prozess läuft keine Notifications mehr, wenn TcAdsClient.Synchronize = true gesetzt ist.
 
Zurück
Oben