.NET-GZIP-Fehler durch Probleme mit Stromversorgung und Erdung
Eine C#-Anwendung, die GZIP-Archive einlas, warf eine InvalidDataException mit der Meldung „Der Archiveintrag wurde mit einer nicht unterstützten Komprimierungsmethode komprimiert.“ Der Fehler trat äußerst sporadisch auf: Manchmal gelang die Extraktion, manchmal stürzte das Programm ab. Die Dateien selbst blieben unverändert, die Prüfsummen stimmten exakt überein, doch wiederholte Leseversuche scheiterten gelegentlich – selbst in der Bash, die dann einen „can’t seek file descriptor“-Fehler auswarf.
Der Stacktrace zeigte direkt auf DeflateStream.ReadCore in System.IO.Compression.dll (.NET Core 3.1.16). Innerhalb von ReadCore ergab die Bedingung if (count <= this._buffer.Length) plötzlich false: count überschritt auf unerklärliche Weise die Puffergröße und löste die InvalidDataException aus.
internal int ReadCore(Span<byte> buffer) {
this.EnsureDecompressionMode();
this.EnsureNotDisposed();
this.EnsureBufferInitialized();
int start = 0;
while (true) {
do {
int num = this._inflater.Inflate(buffer.Slice(start));
start += num;
if (start == buffer.Length || this._inflater.Finished() && (!this._inflater.IsGzipStream() || !this._inflater.NeedsInput()))
goto label_7;
}
while (!this._inflater.NeedsInput());
int count = this._stream.Read(this._buffer, 0, this._buffer.Length);
if (count > 0) {
if (count <= this._buffer.Length) // hier wurde die Bedingung zu false
this._inflater.SetInput(this._buffer, 0, count);
else
break;
} else
goto label_7;
}
throw new InvalidDataException(SR.GenericInvalidData);
label_7:
return start;
}
Weiter unten im Callstack lieferte ZLibNative.Inflate die Rückgabewerte DataError oder StreamError, die von der Laufzeitumgebung als beschädigte Daten oder inkonsistenter Stream interpretiert wurden.
Symptome eines Hardwaredefekts
Die Probleme beschränkten sich schnell nicht mehr nur auf die GZIP-Extraktion. Visual Studio begann mit obskuren Fehlern abzustürzen, die eine Reparatur erforderten, Symbole verschwanden und die Textdarstellung wurde verzerrt. CrystalDiskInfo meldete null fehlerhafte Sektoren, doch sfc /scannow fand und „reparierte“ wiederholt beschädigte Systemdateien.
Das entscheidende Muster zeigte sich: Fehler traten ausschließlich auf, wenn das Gerät am Netzstrom angeschlossen war. Im Akkubetrieb lief das System einwandfrei. Zusätzliche Symptome waren:
- Grüne und rote Bildartefakte auf zwei verschiedenen Monitoren.
- Ein spürbares elektrisches Kribbeln beim Berühren des Trackpads und des Gehäuses eines MacBook Pro 2012 (unter Boot Camp).
- Ein schwaches Glimmen der Wohnungsbeleuchtung, nachdem sie ausgeschaltet wurde.
- Träge Programmstarts und zufällige, unerklärliche Neustarts.
Das Windows-Ereignisprotokoll verzeichnete explizit APIC-Fehler im Zusammenhang mit der Energieverwaltung.
Diagnose der elektrischen Ursache
Ein einfacher Steckdosentester bestätigte eine vollständig fehlende Erdung in den Wandsteckdosen. Die Instabilität korrelierte stark mit hoher Luftfeuchtigkeit, Umgebungswärme und dem laufenden Klimagerät. Spannungseinbrüche (unter 120 V) ließen die USV mit AVR ununterbrochen piepen und protokollierten innerhalb weniger Tage über 20 Stromereignisse.
Der direkte Anschluss des Rechners an eine FI-geschützte Steckdose (im Badezimmer) stabilisierte das System vorübergehend, selbst unter hoher Prime95-Last. Ein Wechsel zurück zur herkömmlichen Mehrfachsteckdose brachte die Abstürze sofort zurück.
Wahrscheinliche Ursachen:
- Fehlender Schutzleiter: Der elektrische Strom hatte keine Ableitung, was zu statischer Aufladung auf Gerätegehäusen führte.
- Spannungseinbrüche durch die Klimaanlage: Schwere Kompressorzyklen zogen die Netzspannung in die Tiefe.
- Hohe Luftfeuchtigkeit: Verstärkte Kriechströme über nicht geerdete Stromkreise.
Lösung und wichtige Erkenntnisse
Die Installation einer ordnungsgemäß geerdeten Steckdose (verbunden mit dem Erdungssystem des Warmwasserbereiters) beseitigte jedes einzelne Symptom. Der Tester bestätigte eine solide Erdungsverbindung. Die GZIP-Extraktion stabilisierte sich vollständig, die Monitorartefakte verschwanden und die Stromschläge hörten auf.
Wichtige Erkenntnisse für die Praxis:
- Sporadische
InvalidDataException-Fehler inDeflateStreambedeuten nicht zwangsläufig beschädigte Dateien – sie können auf Lesefehler auf Hardwareebene hinweisen. - Eine
count > buffer.Length-Bedingung inReadCoreist ein klassisches Symptom für eine Stream-Korruption auf Hardwareebene. - Eine fehlende Erdung führt dazu, dass sich elektrisches Potenzial auf Metallgehäusen aufbaut, was Speicherlaufwerke und Displayausgaben direkt stört.
- Spannungseinbrüche in Kombination mit hoher Luftfeuchtigkeit können stille Datenkorruption verursachen, ohne Warnungen vor fehlerhaften Sektoren auszulösen.
- Schließen Sie Strom- und Erdungsprobleme immer aus, bevor Sie sich in tiefgreifendes Code-Debugging stürzen.
Das Debuggen von E/A-Operationen erfordert einen Blick über die IDE hinaus und die Berücksichtigung der gesamten physischen Kette – bis hin zur Wandsteckdose.
— Editorial Team
Noch keine Kommentare.