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:

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:

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

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

Was auf den ersten Blick ins Auge fällt, die Anwendung liegt unter \\SERVER\Application\Anwendung.exe
Netzwerkfreigaben können zum Problem werden wenn z.B. die Verbindung wegbricht z.B. durch Standby vom Rechner.
Ist auch generell keine gute Idee.

T-Virus

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.

Habe auch so etwas seit einigen Tagen eine Anwendung startet nicht mehr:

Name der fehlerhaften Anwendung: AutomaticEmailProcessor.exe, Version: 3.0.19.0, Zeitstempel: 0x633c56c6
Name des fehlerhaften Moduls: clr.dll, Version: 4.8.4515.0, Zeitstempel: 0x624ce98e
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00000000006833c0
ID des fehlerhaften Prozesses: 0x4c68
Startzeit der fehlerhaften Anwendung: 0x01d8f90afd93b54f
Pfad der fehlerhaften Anwendung: C:\Program Files\Automatic Email Processor\AutomaticEmailProcessor.exe
Pfad des fehlerhaften Moduls: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Berichtskennung: 1fb4745e-06e7-4781-87d6-2ea1ad0cb85c
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

und

Name der fehlerhaften Anwendung: SurSvc.exe, Version: 2.4.0.8919, Zeitstempel: 0x62746409
Name des fehlerhaften Moduls: clr.dll, Version: 4.8.4515.0, Zeitstempel: 0x624ce98e
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00000000006833c0
ID des fehlerhaften Prozesses: 0x10f8
Startzeit der fehlerhaften Anwendung: 0x01d8f90a13b5e5ef
Pfad der fehlerhaften Anwendung: C:\Program Files\Intel\SUR\QUEENCREEK\SurSvc.exe
Pfad des fehlerhaften Moduls: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Berichtskennung: fad741a8-6392-4130-b782-bc088dda2fd7
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

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 ?

Wenn es am Update liegen würde, wären die offiziellen Kanäle voll von Reports. Dem ist aber bislang nicht so.
Das Update ist seit einer Woche offiziell raus (seit 2 Wochen im Release), und im offiziellen Repo gibts nicht ein einzigen Issue dazu: Issues · dotnet/runtime

Dazu sind die Changes von KB5020694 reine Security Features in Sachen SqlClient.
CVE-2022-41064 - GitHub Advisory Database

Daher nein: kann man wohl nicht bestätigen.
Ohne genaue Exception, kann man aber eh nur raten. Im Fall des Threadstarts ist die Anwendung zusätzlich auf einer Netzwerkshare, was sie niemals sein sollte, was das Einschränken von Ursachen weiter erschwert.

Zitat von Economy

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.