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.
Ich hab' zwei kostenlose Kredikarten. Die eine von der DKB um im Ausland kostenlos Geld abholen zu können und die andere mit einem hohen Limit um Flüge und Reisen buchen zu können.
Im Alltag nutze ich eigentlich nur die EC-Karte zum Bezahlen. Ich hab so gut wie nie mehr als 20 € Bargeld in der Tasche. Seit Corona kann man auch bei jedem Bäcker mit Karte zahlen bei uns. Zum Tanken hab' ich Tankkarten.
Dafür gibt es "Unhandled Exception"-Handler mit denen man unbehandelte Ausnahmen abfangen kann.
Du kannst auch einen Blick in das Ereignisprotokoll werfen, da werden unbehandelte Ausnahmen, die eine Anwendung zwangsweise beenden mitunter protokolliert.
kostenlose Alternativen hab ich noch keine gesehen, ein Tipp wäre nicht schlecht.
Ich hab' auch länger gesucht und keine kostenlosen alternativen gefunden (heißt nicht, dass es sie nicht gibt), die auch alle PDF-Dateien korrekt anzeigen konnten. Bei PDF-Dateien mit eingebetteten Schriftarten hatte ich oft das Problem, dass die Librarys diese nicht gerendert haben und die PDFs dann halt leer waren.
Wir verwenden für die reine Anzeige jetzt das Produkt PDFPrinting.NET von Terminalworks (nur den Viewer).