Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 12

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

  1. #1
    Registriert seit
    27.03.2015
    Beiträge
    6
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Ausrufezeichen


    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
    Zitieren Zitieren .NET Service stürzt sporadisch ab - Hauptverdächtiger ADS-Kommunikation  

  2. #2
    Registriert seit
    25.08.2010
    Beiträge
    49
    Danke
    3
    Erhielt 4 Danke für 4 Beiträge

    Standard

    Moin,
    Zitat Zitat von chripf Beitrag anzeigen
    ExecutionEngineException
    https://msdn.microsoft.com/de-de/lib...vs.110%29.aspx - da läuft im .NET was mächtig schief als Erstes wäre der komplette StackTrace von Vorteil, dann lässt sich vieleicht der Schuldige besser finden
    x8Bit.de

  3. #3
    chripf ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    27.03.2015
    Beiträge
    6
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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.

  4. #4
    Registriert seit
    25.08.2010
    Beiträge
    49
    Danke
    3
    Erhielt 4 Danke für 4 Beiträge

    Standard

    Unser Service ist zu 100% in Managed Code umgesetzt
    C++/CLI oder C# oder VB.NET?? Ruft ihr externe DLL's auf?
    x8Bit.de

  5. #5
    chripf ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    27.03.2015
    Beiträge
    6
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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.
    Geändert von chripf (31.03.2015 um 08:17 Uhr)

  6. #6
    Registriert seit
    24.02.2009
    Beiträge
    1.242
    Danke
    23
    Erhielt 276 Danke für 235 Beiträge

    Standard

    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?
    Sänd from mei Kombjudder mitse Dastadurr.

  7. #7
    chripf ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    27.03.2015
    Beiträge
    6
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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...

  8. #8
    Registriert seit
    24.02.2009
    Beiträge
    1.242
    Danke
    23
    Erhielt 276 Danke für 235 Beiträge

    Standard

    Habt ihr euch schon an den Beckhoff-Support gewendet? Es wäre ja mal interessant zu wissen, was die dazu sagen.
    Sänd from mei Kombjudder mitse Dastadurr.

  9. #9
    chripf ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    27.03.2015
    Beiträge
    6
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard

    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.

  10. #10
    Registriert seit
    24.02.2009
    Beiträge
    1.242
    Danke
    23
    Erhielt 276 Danke für 235 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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 .
    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).
    Sänd from mei Kombjudder mitse Dastadurr.

Ähnliche Themen

  1. Profinet Kommunikation steigt sporadisch aus...
    Von mertens2 im Forum Feldbusse
    Antworten: 2
    Letzter Beitrag: 01.05.2013, 14:24
  2. Antworten: 0
    Letzter Beitrag: 19.11.2012, 17:05
  3. Kommunikation VB.NET <--> SPS via ADS.NET
    Von twincatter im Forum CODESYS und IEC61131
    Antworten: 6
    Letzter Beitrag: 05.05.2012, 00:33
  4. Antworten: 9
    Letzter Beitrag: 08.11.2011, 17:08
  5. Simatic Net Synchronization Service
    Von Norton im Forum Simatic
    Antworten: 1
    Letzter Beitrag: 13.09.2008, 09:52

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •