Meine in Windows 7 enthaltene .NET-Installation (3.5 bis 2.0) scheint ganz leicht und insbesondere beschädigt zu sein und ich versuche, das Problem zu beheben, ohne Windows neu zu installieren oder auf Sicherungen zurückzugreifen.
Alles funktionierte, aber dann begann meine Festplatte, einige Dateien zu beschädigen, und checkdisk fand fehlerhafte Cluster, also habe ich ein Image der Festplatte auf eine neue erstellt. Sobald ich die neue Festplatte gebootet hatte, funktionierte alles.außerProgramme, die die System.Net.NetworkInformation-Methoden innerhalb von .NET 3.5 bis 2.0 aufrufen (wie Ping() und IsNetworkAvailable()), wodurch die App, in der die Aufrufe erfolgen, sofort abstürzt (diese Aufrufe funktionieren in .NET 4.0 einwandfrei). Diese Methoden befinden sich in System.dll und ich gehe davon aus, dass sie native Methoden aufrufen, die sich meiner Meinung nach in winnsi.dll oder iphlpapi.dll oder etwas anderem befinden (ich habe das noch nicht gefunden); ich gehe davon aus, dass es native Methoden aufruft, weil die Ausnahme, die den Absturz verursacht, ein schwerwiegender Execution Engine-Fehler ist, von dem die Leute sagen, dass er normalerweise mit dem Aufruf nativer Methoden und dem Marshalling von Daten zwischen ihnen zusammenhängt.
Ein wichtiger Hinweis auf den Übeltäter liegt wahrscheinlich in der Tatsache, dass die Anwendung einwandfrei funktioniert, wenn ich genau dieselbe abstürzende Anwendung über einen Code-Profiler starte (der die EXE ausführt und Statistiken darüber erfasst, welche Methoden am längsten gedauert haben) und überhaupt nicht abstürzt! Wie kann es funktionieren, wenn man sie innerhalb des Profilers ausführt, aber außerhalb nicht? Das scheint der Schlüssel zum Rätsel zu sein.
- Ich habe procmon verwendet, um alle Registrierungs-, Dateisystem- und Netzwerkereignisse der abstürzenden Ausführung und der erfolgreichen Ausführung durch den Profiler abzufangen, und habe die beiden Ausgaben verglichen, aber nicht viel gelernt (ich sehe den Moment, in dem die nicht profilierte App abstürzt, aber bis dahin verhalten sie sich gleich, haben dieselben Module geladen usw.). Der einzige große Unterschied scheint zu sein, dass der vom Profiler ausgeführte Code im Moment vor dem App-Absturz 4-6 neue Threads erstellt und der direkt ausgeführte Code nur 1-2.
- Ich habe die Dateien/Verzeichnisse verglichen, die am relevantesten schienen (das .NET-Zeug unter Windows und Programme), vor und nach dem Festplattenproblem, und habe keine Änderungen gesehen, wo ich keine erwartet hatte (keine offensichtliche Dateibeschädigung).
- Ich habe die Software- und Systemregistrierungsstrukturen vor und nach dem Festplattenproblem verglichen und keine Änderungen gesehen, die relevant erschienen.
- Ich habe ein neues Benutzerkonto erstellt und alle Umgebungsvariablen bereinigt, falls diese mit der Umgebung in Zusammenhang standen. Keine Änderung.
- Ich habe „sfc /scannow“ ausgeführt und es wurden keine Integritätsprobleme gefunden.
- Ich habe „ngen update“ ausprobiert, um vorkompilierten Code neu zu generieren, für den Fall, dass ich etwas übersehen habe, das beschädigt sein könnte, und sich nichts geändert hat.
Ich gehe davon aus, dass ich meine .NET-Installation reparieren muss, aber da Windows 7 .NET 3.5 - 2.0 enthielt, kann man nicht einfach ein .NET-Installationsprogramm erneut ausführen, um es zu wiederholen. Ich habe keinen Zugriff auf die Windows-Festplatten, um zu versuchen, Windows über sich selbst neu zu installieren (der Computer hat eine Wiederherstellungspartition, aber sie ist unbrauchbar); außerdem verwendet das Laufwerk eine Lösung zur Vollplattenverschlüsselung und eine Neuinstallation wäre schwierig.
Ich möchte hier auf keinen Fall von vorne anfangen und ein neues Windows installieren, Dutzende von Softwarepaketen neu installieren, versuchen, mich an Dutzende von entwicklungsbezogenen Anpassungen usw. zu erinnern.
Angesichts all dessen ... hat jemand einen hilfreichen Rat? Ich brauche .NET 3.5 – 2.0, da ich Entwickler bin und damit bauen und testen muss.
Danke!
Quinxy
Antwort1
Die kurze Antwort ist, dass meine Datei System.ni.dll beschädigt war. Ich habe sie ersetzt und alles ist gut.
Ich erinnerte mich daran, dass ich das chkdsk-Protokoll noch einmal überprüfen sollte. Es listete ständig die Dateien auf, die durch den Laufwerksfehler beschädigt wurden. Nach dem Fehler hatte ich alle aufgelisteten Datei-IDs in Dateipfade/-namen umgewandelt und alle über 100 Dateien ersetzt, die ich aus dem Backup bekommen konnte. Als ich jetzt zurückging und nachsah, fand ich einen Hinweis, dass ich zwar 4 oder 5 .NET-bezogene Dateien erfolgreich ersetzt hatte, es aber eine solche Datei gab, die ich nicht ersetzen konnte, weil sie zu diesem Zeitpunkt „in Verwendung“ war. Diese Datei? System.ni.dll!!! Ich konnte diese Datei jetzt aus dem Backup ersetzen und voilà, meine .NET-Installation ist wieder normal, Apps funktionieren, egal ob sie profiliert sind oder nicht.
Das Frustrierende ist, dass ich beim ersten Auftreten dieses Vorfalls voll und ganz davon ausging, dass das Problem mit einer beschädigten Datei zusammenhängt, und zwar mit einer Datei namens System.dll, die die fehlgeschlagenen Methoden enthielt. Also habe ich alle Dateien mit dem Namen System.dll verglichen und erneut verglichen. Aber ich habe damals nicht erkannt, dass System.ni.dll eine nativ kompilierte Manifestation von System.dll (oder so ähnlich) war. Und weil ich die .NET-bezogenen Verzeichnisse verglichen und erneut verglichen hatte und dies nicht bemerkt hatte (keine Ahnung, wie ich das übersehen konnte), hatte ich diesen Ansatz aufgegeben.
Wie dem auch sei ... um es kurz zu machen, es war eine beschädigte System.ni.dll, die meine Probleme verursachte. Bei einem oder mehreren Clustern darin wurde der Inhalt durch 0x0 ersetzt und so manifestierte sich zufällig das seltsame Problem, das mir auffiel.