Es liegt vermutlich an einem Windows Update am 11.11.2022:
Kumulatives Update **KB5020694 **vom 8. November 2022 für .NET Framework 3.5, 4.8 und 4.8.1 für Windows 10, Version 22H2
Kann das wer bestätigen ?
Auf den Systemen bei denen das Problem bei unseren Anwendern auftritt ist das Update nicht installiert. Hab's gerade geprüft.
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.
Hallo Leute,
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:
Fehlermeldung:
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:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>100</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2022-11-10T10:05:00.9500007Z" />
<EventRecordID>7319</EventRecordID>
<Correlation />
<Execution ProcessID="0" ThreadID="0" />
<Channel>Application</Channel>
<Computer>workstation.domain.intern</Computer>
<Security />
</System>
- <EventData>
<Data>Anwendung.exe</Data>
<Data>2022.7.5.211</Data>
<Data>62ebcd0a</Data>
<Data>clr.dll</Data>
<Data>4.8.4515.0</Data>
<Data>624ce98e</Data>
<Data>c0000005</Data>
<Data>00000000006833c0</Data>
<Data>45c</Data>
<Data>01d8f4c71298d974</Data>
<Data>\\SERVER\Application\Anwendung.exe</Data>
<Data>C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll</Data>
<Data>86beaba4-dad9-4edd-8c91-4bf7071dfea3</Data>
<Data />
<Data />
</EventData>
</Event>
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?
Danke & Gruß hypersurf
Gibt es noch Antiviren Lösungen, wo man dem User / Entwickler die Möglichkeit in die Hand geben kann, verzeichnisse von Real time Scan zu excluden?
Wir setzen ESET inkl. zentraler Steuerung ein. Gerade auf meinem lokalen Client erfolgreich ausprobiert ein einzelnes Verzeichnis zu excluden.
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.
Liegt's vielleicht daran, dass "user" ein reserved Word in Access ist?
Ich hab' das Problem auch täglich. Egal ob Forms oder WPF.
Danke für Eure Antworten und sorry für meine späte Antwort, hatte einfach noch keine Gelegenheit ausführlich zu antworten 🙂
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.
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.
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.
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.
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.
Der moderen Weg des Loggings nennt sich Full Structured Logging; eine Implementierung im .NET Ökosystem ist zB.
>
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
> 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.
Gruß hypersurf
Hallo Leute,
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.
Wie würdet Ihr das lösen?
Gruß hypersurf
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.