Darüber habe ich auch schon nachgedacht, Verbindungsabbrüche sind zwar nicht protokolliert, ich werds aber mal testen die Anwendung lokal auf den Rechner zu legen.
wir haben eine größere .NET-Anwendung (Windows Forms) die speziell auf einer Workstation Probleme macht.
Das Problem stellt sich wie folgt dar:
- Benutzer arbeitet eine Weile mit der Anwendung auf seinem Windows 10-Rechner.
- Er macht Pause (oder ist aus sonstigen Gründen eine längere Zeit nicht am Rechner), die Anwendung läuft weiter.
- Er kommt wieder an den Rechner und egal was er macht, die Anwendung crashed, d. h. sie schließt sich ohne Fehlermeldung (auch einfach beim Bewegen der Maus).
Im Ereignisprotokoll finde ich dann folgenden Eintrag:
Fehler
Name der fehlerhaften Anwendung: Anwendung.exe, Version: 2022.7.5.211, Zeitstempel: 0x62ebcd0a
Name des fehlerhaften Moduls: clr.dll, Version: 4.8.4515.0, Zeitstempel: 0x624ce98e
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00000000006833c0
ID des fehlerhaften Prozesses: 0x45c
Startzeit der fehlerhaften Anwendung: 0x01d8f4c71298d974
Pfad der fehlerhaften Anwendung: \\SERVER\Application\Anwendung.exe
Pfad des fehlerhaften Moduls: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Berichtskennung: 86beaba4-dad9-4edd-8c91-4bf7071dfea3
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Unbehandelte Ausnahmen werden abgefangen und es wird dann eine Messagebox angezeigt und die Ausnahme in der Logdatei protokolliert. In diesem Fall passiert das aber nicht.
AppDomain.CurrentDomain.UnhandledException += new System.UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
Natürlich habe ich schon eine ganze Weile nach der Access Violation (0xc0000005) gegoogelt. Ich finde aber nur relativ allgemeine Tips, wie Virenscanner deaktivieren, .NET-Runtime neu installieren, usw. was wir natürlich schon gemacht haben.
Gibt es einen Weg die Ursache zu ermitteln? Liege ich richtig mit meiner Annahme, dass das nur mit ProcDump + Windbg gehen wird?
Das TreeView ist viel übersichtlicher als die vorherige Variante. Ich würde definitiv das TreeView nehmen. Zudem bist Du nicht eingeschränkt, falls mal aus irgendwelchen Gründen noch eine Ebene dazu kommen soll.
Danke für Eure Antworten und sorry für meine späte Antwort, hatte einfach noch keine Gelegenheit ausführlich zu antworten
Zitat von T-Virus
Habt ihr keine Exception/Stacktrace für die ursachen Forschung?
Doch haben wir, manchmal sind die Abläufe aber komplexer, oder es entstehen einfach durch die einzigartige Bedienweise der Software durch die Benutzer Unhandled Exceptions deren Ursache wir nicht ohne weiteres nachvollziehen können.
Klar sehen wir anhand der Exception wo es zum Fehler kommt, der Weg dahin ist aber nicht immer reproduzierbar. Ich stelle mir eine Lösung vor die einfach permanent loggt, so dass wir im Fehlerfall viel schneller nachvollziehen können, was der Benutzer direkt vor dem Fehler gemacht hat.
Zitat von T-Virus
Was für einen Fehler habt ihr?
Zuletzt hatten wir einen Deadlock durch nicht ganz sauber umgesetzte asynchrone Abläufe. Das ließ sich letztendlich einfach beheben, nachdem wir wussten an welcher Stelle die Problematik auftritt. Da hätten wir durch vorhandenes, permanentes Logging viel Zeit sparen können.
Zitat von T-Virus
Was ich auch empfehlen kann, wäre z.B. mit Sentry zu arbeiten.
Der Einbau ist sogar relativ einfach und gut dokumentiert.
Finde ich sehr interessant und werden wir uns definitiv anschauen.
Zitat von Palladin007
Was Du schreibst, klingt ein bisschen so, als wär euer Logging selbst geschrieben?
Jop ist es. Und es ist an der Zeit das durch eine vernünftige Lösung zu ersetzen, die uns Fehlersuche erleichtert und dadurch letztendlich Zeit spart.
Zitat von Abt
Alle Methoden zu protokollieren ist der völlig falsche Weg. Das hat noch nie wirklich sinnhaftig funktioniert.
Wenn ich aber den Ablauf durch den ein Fehler entsteht nachvollziehen kann, komme ich meiner Erfahrung nach viel schneller an die Ursache.
Zitat von Abt
Der moderen Weg des Loggings nennt sich Full Structured Logging; eine Implementierung im .NET Ökosystem ist zB. Serilog — simple .NET logging with fully-structured events
Weiterhin sollte ein Logging auch immer Teil der Software Architektur sein, zB über Operation based Logging.
Operation based Logging wird zB auch in AWS, Google Cloud, Azure ... verwendet, um die genauen Abläufe in der Cloud zu protokollieren, zB auf Basis von Application Insights.
Wie wir das umgesetzt haben ist in [Artikel] Die myCSharp.de Infrastruktur beschrieben (so wende ich das auch in allen Kundenprojekten sowohl Architektur wie auch Implementierung an).
Danke, genau das habe ich gesucht. Hab' mir Serilog heute Mittag schonmal zwei Stunden angeschaut und werd's morgen mal mit den Kollegen besprechen.
PS: Gebt mir bitte mal einen Tipp wie ich mich technologisch besser auf dem aktuellen Stand halten kann. D. h. welche Quellen sind gut um sich über aktuelle Entwicklungen und Vorgehensweisen auf dem aktuellen Stand zu halten? Ich hab' durch die viele Arbeit öfter mal das Gefühl hinterher zu hinken.
ich habe folgende Problemstellung:
Ich möchte alle Methodenaufrufe protokollieren können um nicht direkt nachstellbare Probleme/Bugs in unserer Software leichter beheben zu können. Aktuell können wir den internen Loglevel erhöhen und alle Methodenaufrufe werden in eine Logdatei geschrieben. Das ist im Alltag nicht praktikabel, weil dadurch die ganze Software langsam wird.
Ich könnte alle Methodenaufrufe auch in eine Queue schreiben, welche dann in einem separaten Thread irgendwohin geschrieben wird. Das bringt mir aber nichts, wenn das Programm abstürzt und die Einträge aus der Queue zum Zeitpunkt des Absturzes noch nicht vollständig weggeschrieben sind.
Wie machen das andere Programme? Bei List & Label gibt es beispielsweise die debwin3.exe in der in Echtzeit alles angezeigt wird was in List & Label gerade passiert.
Ich dachte daran, vielleicht eine Art Logserver zu schreiben, der beispielsweise mittels SignalR die Methodenaufrufe mitgeteilt bekommt und sie dann wegschreibt.
Das ganze nennt sich Zugriffsmodifizierer und gehört zu den Grundlagen von OOP. Zugriffsmodifizierer geben die Möglichkeit, einfach zu steuern, wer wann auf welche Weise auf Klassen, Properties, Events, Felder und Methoden zugreifen darf.
Ist alles identisch zu anderen Benutzern. Es muss irgendwas sein, was der Benutzer mit in die Sitzung bringt.
Wir verschieben den Benutzer jetzt auf einen anderen Server und schauen mal, ob das Problem noch auftritt.
Also wenn es nur ein Benutzer ist, wird es meiner Meinung nach nicht an dem Framework des Servers liegen. In der RDP Verbindung kannst du lokale Ressourcen mal alles deaktivieren bis auf Zwischenablage (auch die Remoteaudioeinstellungen).
Das hatten wir schon versucht, also Druckerweiterleitung, und was man sonst so mit in die Sitzung nehmen kann deaktiviert.
Ich hatte einen ähnlichen Fall mal mit dem PDF-Drucker von DATEV (SkyPDF heißt der glaub' ich). War dieser mit auf dem Server installiert kam es zu völlig sinnlosen Abstürzen, damals gabs aber einen Verweis auf den Drucker in den Einträgen im Eventlog.
Zitat von Stefan.Haegele
Wie sind die User mit dem Server verbunden? Gibt es hier eine AUusnahme welche nur auf diesen User zutrifft (z.B. VPN wegen HO?)
Alle über's lokale Netzwerk.
Zitat von Stefan.Haegele
Stellt ihr die Applications als RemoteApp zur Verfügung?
Nope, jeder hat seinen eigenen Desktop auf dem Server und startet dann die Anwendung. Außer der Anwendung läuft sonst nichts auf dem Server (keine weitere Software installiert).
Yes, wir installieren am WE mal das Framework auf dem Server neu. Das Benutzerprofil hatten wir schon neu eingerichtet, hatte leider keine Auswirkung.
Kann's theoretisch auch etwas sein, was der Nutzer mit in die Sitzung bringt (Druckerweiterleitung)??
Werd' ich am Wochenende mal versuchen. Komisch ist wirklich, dass das Problem nur bei einem einzigen Benutzer (es sind 35 auf dem RDP-Server) auftritt.
ich hab' bei einem einzigen Benutzer das Problem, dass unsere Anwendung ohne zutun des Benutzers abstürzt (siehe Anhang). D. h. der Benutzer schaut nur auf die Eingabemaske und die Anwendung stürzt ohne weitere Benutzereingabe ab. Das ganze passiert total sporadisch und so gut wie in jeder vorhandenen Eingabemaske.
In der Main-Methode fangen wir UnhandledExceptions natürlich ab und handeln diese entsprechend. Das funktioniert auch immer - nur bei der oben beschriebenen Problematik nicht.
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
AppDomain.CurrentDomain.UnhandledException += new System.UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
TaskScheduler.UnobservedTaskException += new EventHandler<UnobservedTaskExceptionEventArgs>(TaskScheduler_UnobservedTaskException);
Im Ereignisprotokoll werden bei diesen Abstürzen zwei Ereignisse protokolliert:
EventId 1000:
Fehler
Name der fehlerhaften Anwendung: xxxx.exe, Version: 1.0.0.0, Zeitstempel: 0x609ab544
Name des fehlerhaften Moduls: ntdll.dll, Version: 10.0.14393.4350, Zeitstempel: 0x606eaf8d
Ausnahmecode: 0xc000000d
Fehleroffset: 0x00000000000fe2ec
ID des fehlerhaften Prozesses: 0xcd2c
Startzeit der fehlerhaften Anwendung: 0x01d756aaa6428410
Pfad der fehlerhaften Anwendung: D:\Application\Application\xxxx.exe
Pfad des fehlerhaften Moduls: C:\Windows\SYSTEM32\ntdll.dll
Berichtskennung: 27bc97d4-0852-41ce-af0f-42c5660e0e54
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
Anwendung: xxxx.exe
Frameworkversion: v4.0.30319
Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet.
Ausnahmeinformationen: Ausnahmecode c000000d, Ausnahmeadresse 00007FFB9028E2EC
Wir verwenden das .NET Framework 4.5.1 auf einem Windows 2016 Remotedesktopserver.
Natürlich habe ich schon stundenlang (eher tagelang) im Netz nach einer Lösung gesucht, aber keine gefunden die mich irgendwie auf die Spur zur Ursache führen könnte.
Ganz einfache Ansätze wie Serverneustart, Virenscanner ausschalten, usw. haben wir natürlich schon ausprobiert.
Mittlerweile läuft fast täglich procdump (procdump -accepteula -e -ma pid) auf den Prozess des Benutzers, leider ist der Fehler noch nie aufgetreten während procdump lief (darauf warten wir aktuell noch).
Woran liegt es, dass der Fehler nicht durch die Event-Handler für die Unhandled Exceptions gefangen wird? Ist ein Memorydump der einzige Weg die Ursache zu ermitteln?
Ich hab' das Problem auch öfter bei verschiedenen UserControls. Meistens hilft es einmal alle Klassen zu schließen, das Projekt zu bereinigen, zu erstellen und es dann nochmal zu versuchen. Wenn das auch nichts hilft ignoriere ich den Fehler meistens (gibt ne Schaltfläche dazu), kontrolliere dann aber via GIT ob beim Ignorieren irgendwas verloren gegangen ist.
Irgendwas wird wohl null sein, sonst würd's keine NullReferenceException geben.
Wenn die Exception erst in Zeile 11 geworfen wird, würde ich schätzen, dass tsslColValue null ist.
Bulk-Inserts werden unter MySQL scheinbar nicht so unterstützt wie von MS SQL Server. Wenn ich es richtig verstehe basiert das Ganze auf fileinput. Da das auch wieder IO lastig ist, würde es das Problem nur verlagern.
Bulk-Inserts werden unterstützt:
INSERT INTO table_name (column_list)
VALUES
(value_list_1),
(value_list_2),
...
(value_list_n);
Dann wäre es zusätzlich interessant die Tabellenstruktur inkl. Indizes zu kennen, da "zu viele" Indizes die Performance beim Einfügen von Datensätzen negativ beeinflussen können.
Ich gehe mal davon aus, dass Du InnoDB verwendest.
Eine Optimierung der Datenbankkonfiguration könnte wohl helfen.
Das die Platte ausgelastet wird wundert mich nicht:
Zitat
InnoDB must flush the log to disk at each transaction commit if that transaction made modifications to the database. When each change is followed by a commit (as with the default autocommit setting), the I/O throughput of the storage device puts a cap on the number of potential operations per second.
ich bräuchte mal Eure Unterstützung bzw. einfach ein paar Stichworte mit welchen Technologien ich das ganze umsetzen kann.
Ich möchte eingehende Telefonanrufe unseres Telefonanbieters Placetel auf unseren Clients anzeigen. Hierfür bietet Placetel eine Notify-API welche POST-Requests mit den Anruferdaten sendet.
Die RestAPI zu schreiben an welche die POST-Requests gehen ist soweit kein Problem. Aber mit welcher Technologie gebe ich die Informationen an die Clients weiter?
Ich hatte mir das ganze so vorgestellt:
1.) Eingehender POST-Request (z. B. ein Anruf) durch die Placetel-Notify-API
2.) Die RestAPI verarbeitet den Request und leitet diesen an bestimmte Clients weiter.
3.) Auf den Clients werden dann der Anruf und diverse weitere Informationen zu dem Anrufer angezeigt.
Mit welcher Technologie kann ich die Clients aus der RestAPI heraus mit Informationen versorgen?
Nunja ich denke wenn ich eine gewisse Motivation zeigen kann und auch schon selbst kleinere Projekte zum vorzeigen habe, mit denen ich auch zeigen kann das ich genau weiß worauf ich mich einlasse, meine nicht all zu hohe Chance wegen des Abschlusses zu erhöhen ^^.
Ich bin selber Arbeitgeber und finde den Abschluss nicht problematisch. Meiner Erfahrung nach kommt es eher auf die Motivation und den Willen an immer neue Dinge zu lernen.