ZFX + Developia

Montaaaag! Guten Morgen, Jammer-Thread! Fuck Microsoooooft!

Habe auf die neuen PDB-Formate von Visual Studio 2015 umgestellt (/DEBUG:FASTLINK), die ja so viel schneller sein sollen. Ich weiß nicht ob sie’s sind, aber die ganze DbgHelp API (SymGetLineFromAddrW64() usw.) hört auf zu funktionieren (im Sinne von „vier Access Violations pro Aufruf“). Meine Debug-Hilfsfunktionen sind alle kaputt. PIECE OF SHIT, also alles reverten

Javascript-basierte Seiten sind scheiße zu automatisieren....

MasterQ32 hat geschrieben:Javascript-basierte Seiten sind scheiße

fixed that for you

————

Boah hab’ ich wieder ’nen Kragen: LTCG:incremental ist bei Visual C++ seit einiger Zeit Standardeinstellung in Release Builds. FUCK. FUCK FUCK FUCK FUCK FUCK.

Zwei Gründe, das auf keinen Fall zu benutzen:

1. Es ist keine volle Optimierung. Der Optimizer hält sich in dem Modus mit Inlining und Constant Propagation zurück, damit möglichst wenig neu optimiert werden muss, wenn man den Code nochmal ändert. Ihr liefert also keine voll optimierte EXE an die Kunden aus.
2. Ohne Rebuild ist die EXE voller Müll. Der Linker hängt einfach alle Änderungen immer wieder hinten dran bis man Clean oder Rebuild aufruft. Wer also vor der Auslieferung 20 Mal was ändert und weder Clean noch Rebuild aufruft, liefert eine sechs Mal so große EXE aus, in der die 19 letzten Änderungen tot herumliegen.

Boah ist das zum Kotzen. Diese scheiß Mother Fuckers haben mir mit ihrer stillen Änderung das letzte Dutzend ausgelieferter Programme verhagelt.

NATÜRLICH war ich zu faul, die Ursache für den Größen- und Leistungsunterschied (grundsätzlich kleiner weil weniger Inlining; grundsätzlich langsamer aus dem selben Grund) zu ermitteln, weil, fuck, ich kann ja nicht den ganzen Tag optimieren und muss was fertigkriegen und sie haben halt einfach was am Compiler geändert, oder? NEIN SIE HABEN EINFACH ALLES KAPUTTGEMACHT DIE SCHWEINE

Nach Windows-Update sind Compiler-Updates also das nächste, was ich nicht mehr installieren darf. FUCK THIS SHIT

Nachtrag: Sie wollten es für Update 2 beheben, aber es ist immernoch drin?!

fixed that for you

Danke, Recht hast du!

und ich bin grade irgendwie echt froh, hier mit gcc/clang rumzuwerkeln, da rantest du nicht so drüber rum

Die benutze ich ja auch garnicht ;)

Krishty hat geschrieben: Es ist keine volle Optimierung. Der Optimizer hält sich in dem Modus mit Inlining und Constant Propagation zurück, damit möglichst wenig neu optimiert werden muss, wenn man den Code nochmal ändert. Ihr liefert also keine voll optimierte EXE an die Kunden aus.

Das macht das als Default für Releasebuilds reichlich dämlich, denn Releasebuilds sind ja gerade dazu gedacht, erst gebaut zu werden, wenn der Code releasefertig ist und man nicht noch mitten in der Entwicklung eines neuen Features ist.
Auf Entwicklungsrechners sollte man eigentlich nur die Debug Config bauen, außer, man muss akut was optimieren und die Performance testen, aber dann will man ja wieder die volle Optimierung haben.

Krishty hat geschrieben: Ohne Rebuild ist die EXE voller Müll. Der Linker hängt einfach alle Änderungen immer wieder hinten dran bis man Clean oder Rebuild aufruft. Wer also vor der Auslieferung 20 Mal was ändert und weder Clean noch Rebuild aufruft, liefert eine sechs Mal so große EXE aus, in der die 19 letzten Änderungen tot herumliegen.!

Und damit hast du gleich noch einen Grund mehr, warum du nicht in deiner lokalen Codebase, in der du auch entwicklelst, Releases bauen solltest, sondern diese in einem Clean Checkout durchführen solltest, idealerweise via Autaamted Build Script und ausgeführt durch eine spezialisierte Buildsoftware und auf dedizierter Hardware.

kaiserludi hat geschrieben:Und damit hast du gleich noch einen Grund mehr, warum du nicht in deiner lokalen Codebase, in der du auch entwicklelst, Releases bauen solltest, sondern diese in einem Clean Checkout durchführen solltest, idealerweise via Autaamted Build Script und ausgeführt durch eine spezialisierte Buildsoftware und auf dedizierter Hardware.

Bei den großen Programmen wird das natürlich so gemacht; ich habe aber auch ein Dutzend kleinerer Projekte, die quasi Standalone-EXEs sind und für die es weder Source Control gibt, noch wären Build Scripts erforderlich. Und da trifft das natürlich richtig.

Baue gerade Objektnamen in meinen TreeView ein – was man nicht alles in CAD-Dateien findet …

Ich bekomm langsam ein Knoten im Kopf!!!!
SINNLOS hier, echt!!!

CSV-Dateien parsen und die Daten verwenden ist ja nicht sooo schwer.
Diese CSV-Datei hat einen Header.
Nun verändert sich der Header aber immer mal wieder zwischen den Versionen....
Ändert die Anzahl der Einträge, die Reihenfolge der Einträge und manchmal auch die Bezeichnung der Einträge!!!
Muß ich immer in der software anpassen.
Damit es aber richtig behindert wird, soll auch noch die Abwärtskompatibilität erhalten werden!!!! :x :x :x :x

ich kann und will nicht mehr....

Oh, es hat wieder jemand Probleme mit 32-Bit-BMPs. Na sowas.

Die Bilder stammen aus Photoshop, und im Zusammenhang mit BMP ist das übrigens bekannt dafür, dass ihre 32-Bit-Exporte nicht mit der Spezifikation kompatibel sind (ein DWORD zu viel im Header). Das scheint aber nicht ihre Schuld zu sein, sondern ein Microsoft-Techniker scheint ihnen vor Jahrzehnten eine falsche Spezifikation gegeben zu haben und dann konnten sie es nicht mehr korrigieren weil die ganzen Content Pipelines der Spieleentwickler auf das falsche Format zugeschnitten waren. Möglicherweise haben sie es auch mit einem Format verwechselt, das Microsoft für Windows CE 5.0 entwickelt hat (und danach wieder eingestellt hat).

Jedenfalls zähle ich in meinem Code sieben verschiedene Header-Formate und vier verschiedene Kompressionsmethoden, und nothings hat recht wenn er sagt, dass sich BMP immer sehr einfach anhört aber äktschuälly eines der furchtbarsten Formate überhaupt ist.

Wenn man Visual C++ auf Größe optimieren lässt statt auf Geschwindigkeit, arbeitet der Optimizer besser. Insbesondere das alte Problem „ich lese zwei Mal aus einem Member, und der Compiler erzeugt dafür auch tatsächlich zwei Lade-Operationen, statt in einem Register zwischenzuspeichern“ tritt viel seltener auf.

Ich glaube nicht, dass das eine rationale Entscheidung war („wenn wir zwei Mal laden, lässt sich die Ausführung besser parallelisieren“ oder so).

Microsoft empfiehlt seit Jahren, gar nicht mehr auf Größe oder Geschwindigkeit zu optimieren, sondern ausschließlich Profile-Guided Optimization zu nutzen. Die wiederum optimiert nur die inneren Schleifen auf Geschwindigkeit, und den großen Rest des Programms auf Größe. Naturgemäß ist dann das meiste Disassembly, das man sieht, Ergebnis der Größenoptimierung, und vielleicht haben sie deshalb mehr Ressourcen investiert, die zu verbessern.

Sommerzeit. Im Frühling. :shock:

Krishty, das passt doch sicher perfekt in deine Sicht zu VS: https://blog.fefe.de/?ts=a6278e32

MasterQ32 hat geschrieben:Krishty, das passt doch sicher perfekt in deine Sicht zu VS: https://blog.fefe.de/?ts=a6278e32

Lass mich da bitte Ordnung reinbringen:

1. Timing-Attacken nutzen aus, dass Rechenoperationen mit verschiedenen Werten unterschiedlich schnell ablaufen. Klassisches Beispiel: Wenn ein Koeffizient Eins oder Null ist, können wir eine Multiplikation komplett überspringen und das Programm läuft schneller. Wenn ein Wert nicht im CPU-Cache liegt, dann wird es dauern, bis die CPU weiterrechnen kann, und das Programm läuft langsamer.
2. Ein Angreifer kann die Verarbeitungsgeschwindigkeit der CPU messen, während sie Dinge ver- oder entschlüsselt. Durch die feinen Zeitunterschiede kann er sagen, wann im Algorithmus welcher Sprung genommen wurde; wann etwas im Cache lag oder nicht. Da all das abhängig vom Inhalt – also dem Schlüssel und der zu verschlüsselnden Sache – ist, kann man mit ausreichend langer Beobachtungszeit (bei einigen Attacken keine Sekunde) rekonstruieren, wie der Schlüssel aussieht. Das ist eine wirklich beeindruckende Leistung, aber auch eine wirklich beängstigende – es funktioniert durch Sandboxes und über das Internet (wie in fefes Link, dort allerdings mit drei Monaten Beobachtungszeit).
3. Aus diesem Grund versucht man, sicherheitskritische Algorithmen so zu entwerfen, dass sie möglichst keine Sprünge oder Speicherzugriffe beinhalten, die irgendwie abhängig vom Schlüssel oder der zu verschlüsselnden Sache sind. Das Programm im Link nutzt so einen:

   The targeted implementation called Curve25519-donna essentially follows the prescriptions of the informational RFC 7748 Elliptic Curves for Security.

4. Das Programm nutzt 64-Bit-Arithmetik:

   The type limb is a 64-bit integer.
   
     static void fscalar_product(limb *output, const limb *in, const limb scalar) {
       unsigned i;
       for (i = 0; i < 10; ++i) {
         output[ i] = in[ i] * scalar;
       }
     }

5. Das Programm ist ein 32-Bit-x86-Programm und es wurde mit Visual C++ kompiliert.
6. 32-Bit-x86-CPUs können nicht 64·64 Bits multiplizieren.
7. Dennoch kann man in seinem 32-Bit-Programm auto x = 0x123456789ABCDEFull * 0x123456789ABCDEFull; schreiben und es funktioniert. VISUAL C++ IST EINE HEXE! Nein, natürlich nicht: In diesem Fall emuliert Visual C++ 64-Bit-Arithmetik, indem es eine Funktion __allmul() aus der Laufzeitbibliothek aufruft. (Genau so werden übrigens 64-Bit-Divisionen und Shifts emuliert, und für unsigned long long dann nochmal das gleiche.)
8. Diese Funktion ist handoptimierter Assembler-Code. Er prüft, ob die oberen 32 Bits null sind, und überspringt dann einen Großteil der Multiplikations, weil’s so viel viel schneller geht. (Ihr merkt, wohin das führt …)
9. Jemand misst die Ausführungszeit, und …
10. #AUFSCHREI!

Okay. Die Katastrophe ist eingetreten und wir haben rekonstruiert, wie es dazu kommen konnte. Was hätte vermieden werden können?

1. Visual C++ hätte diese Routine nicht „verkacken“ (Zitat fefe) dürfen!
   Ich würde mal dagegenhalten, dass 99,9 % der Fälle, in denen von Visual C++ eine 64·64-Bit-Multiplikation gefordert wird, nicht zeitkritisch sind im Sinne von „wir brauchen Konstante Ausführungszeit damit kein Angreifer unsere Schlüssel erfährt“ sondern zeitkritisch im Sinne von „Warum zur Hölle ist mein Programm mit Visual C++ so langsam; Herrgott warum habt ihr so eine langsame Multiplikation; optimiert doch mal!“. Und das auch nur, nachdem der Code bereits andere Anforderungen à „Stürzt nicht ab“ und „funktioniert auf einem 1993er Pentium I“ erfüllt. Kurz: Die Compiler-Entwickler wären mit jeder Entscheidung die Deppen. Also haben sie einfach den Code dringelassen, der die letzten 10 Jahre gut funktioniert hat (da hat nie jemand über Side Channel Attacks nachgedacht).
2. Visual C++ hätte warnen müssen, dass es eine nicht unterstützte Multiplikation emuliert! Oder es überhaupt erst garnicht tun dürfen!
   Antwort StackOverflow: Wie beseitige ich warning C3999: unsupported MUL has been emulated?! Mein Code ist doch total in Ordnung!
   Antwort aller MS-Hasser: LOL MS kann kein unsigned long long in 32-Bit-Programmen; genau DESHALB bleibe ich bei GCC, n00bs!!!
3. Visual C++ sollte zulassen, dass man eigene Multiplikationsroutinen verwendet!
   Tut es. Man muss die Funktion bloß mit dem richtigen Namen und der richtigen Calling Convention definieren, dann ruft Visual C++ sie auf. (Dass ich sowas ständig tue ist wohl auch der Grund, warum Felix [MasterQ32], nicht fefe {oder sind es die selben? Waren sie schonmal zur gleichen Zeit im selben Raum?}] die Nachricht erstmal auf mich bezogen hat.)
4. Das hätte nie jemand als 32-Bit-Programm kompilieren dürfen!
   Jetzt nähern wir uns des Pudels Kern: Die Punkte 3., 4., und 5. oben stehen im Widerspruch. Da wurde ein Modell theoretisch bewiesen. Die Implementierung folgt dem Beweis. Aber die Implementierung setzt 64-Bit-Multiplikationen voraus, und die CPU kann nur 32 Bits multiplizieren! Natürlich geht das schief!

Wer nun irgendwas bewerten will, muss sich erkundigen:

1. War an dieser Stelle eine 64-Bit-Multiplikation nötig?
   Hätte 32·32=64 gereicht? Das können 32-Bit-CPUs nämlich ohne Emulation. Bei auto x = (unsigned long long)a * (unsigned long long)b nutzt Visual C++ diese Fähigkeit auch, wenn a und b 32-Bit-Zahlen sind. In der Beispielfunktion werden aber explizit 64-Bit-Werte zur Multiplikation reingereicht. Das hier klingt sehr faul:

   In the elliptic curve implementation the 32 MSB of the coefficients are only not zero when they are negative (two’s complement is used to represent the negative numbers).

   Also sind bei allen positiven Zahlen die oberen 32 Bits Null? Und bei Negativen sind alle Eins nicht? Sicher, dass eine 64·64-Multiplikation da unbedingt nötig ist?
2. Setzt der Algorithmus zwingend 64-Bit-Multiplikationen voraus?
   Falls dem so ist, hätte ihn niemand ohne weiteres als 32-Bit-Programm programmieren dürfen!

Ich schiebe das in diesem Fall zu 99 % auf die Implementierung. Entweder

• war den Leuten nicht klar, dass ihre Ziel-Architektur long long * long long nicht kann, und sie haben es aus Unwissenheit trotzdem so hingeschrieben um einen durchgängigen Datentypen zu haben
• oder die Funktion hat früher int als Parameter genommen und jemand hat (long long)in[ i] * (long long)scalar; „optimiert“, indem er die Parameter zu long long umgeschrieben hat, und nicht begriffen, dass er damit dem Compiler die Information nimmt, dass die oberen 32 Bits nutzlos sind.

Der Artikel selber denkt wohl ähnlich. Sie schreiben ja nicht Visual C++ ist scheiße!, sondern Passt mit dieser fehlerhaften Implementierung auf! und Implementierungen müssen noch mehr berücksichtigen als die Spezifikation – nämlich auch Architektur, Compiler, und Optimierungen.


P.S.: Sind Stichpunktaufsätze für euch anstrengend zu lesen? Ich schreibe so, weil ich sie angenehmer als Walls of Fließtext finde (vor allem, wenn es komplex wird, und man mittendrin nochmal oben was nachgucken will, bevor man weiterliest). Wenn’s euch stört, gibt’s das demnächst halt wieder als Aufsatz.

Danke für die ausführliche Antwort! Genau sowas wollte ich hören.

Und zu deinem schreibstil: Das ganze lässt sich so wesentlich besser und häppchenweiser erfassen als mit Fließtext, von daher: top!

Schön zu hören!

Drei noch:

It should be noted that the code of the curve was compiled for 32-bit architectures using MSVC 2015.

every code compiled in 32-bit with MSVC on 64-architectures will call llmul every time a 64-bit multiplication is executed

Den letzten Satz finde ich schwamming: Meinen sie, dass 32-Bit-Code __llmul() aufruft, wenn er auf 64-Bit-CPUs ausgeführt wird? Das wäre grob unvollständig, denn auf 32-Bit-CPUs wird es natürlich ganz genau so aufgerufen.

Oder meinen sie, dass 32-Bit-Code __llmul() aufruft, wenn er auf einem 64-Bit-System kompiliert wurde? Das klingt schrecklich, ist aber nicht abwegig: Visual C++ enthält mindestens fünf verschiedene Compiler (x86 on x86; x64 on x64; x64 on x64 Rewrite; Cross Compilers; IntelliSense) und wenn sie nur einen davon getestet haben, ist das ein wichtiger Hinweis. Wem bei der Aufzählung schlecht wird: Microsoft arbeitet seit einigen Jahren daran, das durch einen einzigen Compiler zu ersetzen, aber es ist natürlich eine Mammutaufgabe.

Was mich persönlich mehr nervt als __llmul() ist _chkstk(). Das lässt sich nämlich nur mit Assembler-Code ersetzen (auch unter x64!) und zwingt damit jedem meiner Projekte eine Assembler-Abhängigkeit auf.

Es wäre schon interessant zu erfahren, wie GCC die Situation (long long auf x86-32) handhabt. Ich habe es nie getestet.

fefe hat geschrieben:Update: OK, also bei näherer Betrachtung stellt sich die Lage anders dar. Es geht um curve25519_donna, ein 64-bit-Port von curve25519 von djb. Das 32-bit curve25519 von djb hat das Problem nicht. curve25519_donna ist für 64-bit und hat dort das Problem auch nicht. Man muss also absichtlich und vorsätzlich das falsche curve25519 auf der falschen Plattform kompilieren. Dann fügt Visual Studio eine Routine ein, die die Multiplikation macht. Das macht gcc übrigens genau so unter diesen Umständen. Ich ziehe daher meine Anschuldigung zurück, dass VS hier was verkackt. Verkackt hat alleine der Typ, der das Advisory geschrieben hat. Ich vermute, der wollte nur mal seine 15 Minutes of Fame abholen. Scheiß Publicity-Scheiß immer.

Ich würde nicht einmal so gegen den Typen wettern, denn „die Kurve erfodert 64-Bit-Arithmetik und darf deshalb nicht auf 32-Bit-CPUs kompiliert werden“ ist nicht jedem offensichtlich. Wenn ich die Leute hätte informieren wollen, hätte ich’s ähnlich geschrieben. Ich vermute, dass das Advisory einfach von einer Armee Leute gepusht wurde, die den Text nur halb gelesen haben, und sensationslustig dachten: BWAHAHA, DA MACHT VISUAL C++ MAL WIEDER ALLES KAPUTT!

Krishty hat geschrieben:Lass mich da bitte Ordnung reinbringen:...

Immer wieder krass was Du für Sachen so nebenbei weisst. Danke!

Mal off-topic, sorry.
Wer ist eigentlich dieser Fefe?
Ich kann den irgendwie schwer einordnen....weiß auch sehr wenig von dem.

Hab den gerade auf FB gesehen. Hat einer meiner Anti-NWO-FB-Freunde da was geliket...ich bin verwirrt :?

Ich glaube nicht, dass Fefe persönlich auf Facebook ist, aber falls du mehr wissen willst: https://de.wikipedia.org/wiki/Felix_von_Leitner

Aha...okay.

Und is das der selbe?
https://www.facebook.com/Fefes-Blog-108 ... ED&fref=nf

Okay, sorry. Hab gerade gelesen:

RSS-Feed des erfolgreichsten deutschsprachigen Blogs! Felix von Leitner kommentiert: Tagespolitik, Verschwörungen & Obskures aus aller Welt, Leaks und Softwareprobleme. Diese Seite ist nicht von Fefe.

Weird:
Auf das Telefon war man stolz, weil man statt telegrafieren über einen Draht nun auch direkt miteinander reden konnte.
Auf das Fax war man stolz, weil man nun endlich Dokumente über den Draht schicken konnte und nicht mehr auf das vergängliche Wort angewiesen war.
Auf den Anrufbeantworter war man stolz, weil man mit jemandem reden konnte, der gar nicht da war, statt ihm schreiben zu müssen.
Auf SMS und Messenger war man stolz, weil man jetzt endlich übers Telefon schreiben konnte und nicht mehr direkt miteinander reden oder Sprachnachrichten auf ABs hinterlassen musste.
Auf Spracherkennung und Vorlesefunktion war man stolz, weil man nun solche zu versendenden Texte diktieren konnte statt tippen zu müssen. Und sich vorlesen lassen statt selber zu lesen. Fast schon so gut, als ob man direkt miteinander geredet hätte.
Auf Voice Messaging in Messenger-Apps ist man seit einer Weile stolz, weil man ja eigentlich viel einfacher "auf Band" reden kann statt Buchstaben zu tippen ...

Und als nächstes? Ich könnte mir evtl. vorstellen, die Messenger-App gibt ein akustisches Signal an den Empfänger, wenn versucht wird eine Sprachnachricht zu senden, und stellt automatisch eine direkte Verbindung her statt Voicebox, wenn der Empfänger dies in einem bestimmten Zeitrahmen bestätigt. Sind die aktuell schon so weit oder steckt diese Funktion noch in den Kinderschuhen?
Ich komme mit diesen rasanten Entwicklungen einfach nicht mehr mit. Ich werde alt.

Profiling mit Visual Studio 2015: Profiling mit Visual Studio 2017: IHR DRECKIGEN FICKER, DA IST JA SLEEPY BESSER

Vielleicht funktioniert das Profiling ja jetzt nur noch mit ihrem neuen tollen inkrementellen Debug-Format, das meine Assertions und meine Memory Leak Detection kaputtmacht … scheiß drauf

Man muss hier klicken um die 2015er Ansicht zu erhalten:Wtf?! Das nützlichste Profiler-Feature standardmäßig ausgeschaltet und hinter einem kleinen blauen Text versteckt, der nur über die Hauptansicht erreichbar ist?! RLY?!

Visual C++ 2017 kommt total durcheinander, wenn eine Solution gleichnamige Dateien in verschiedenen Projekten enthält. Es öffnet bei mir dauernd die falsche main.cpp, wenn ein Fehler drin vorkommt und ich auf den doppelklicke. Absolut zum Kotzen.

Außerdem ist mein Build Output voll mit Scheiße wie

  1>cmd.exe /C "A:\Users\Krishty\AppData\Local\Temp\tmp5269a99b78494f44b47c0ffb0a063844.cmd"

Häh?!

Krishty hat geschrieben:Visual C++ 2017

Und hier sitze ich und muss die gesamte Codebase nach wie vor kompatibel zu Compilern von 2008 halten.

Argh; habe mir mein Windows zerschossen.

Musste einen Thumbnail Handler debuggen. Die lädt der Explorer nicht direkt (aus Sicherheitsgründen) sondern erzeugt einen isolierten Systemprozess (dllhost.exe) dafür. Den wollte ich debuggen.

Irgendwann sprang er auch tatsächlich in meinen Haltepunkt. Ich wollte zum nächsten Haltepunkt und drücke F5. Nichts passiert außer voller CPU-Auslastung und frierendem Visual Studio. Offenbar irgendein Deadlock, wo Visual Studio auf den Explorer wartet, und der wartet auf dllhost, und das wiederum ist von Visual Studio angehalten oder so.

Kacke. Task Manager genommen, Visual Studio beendet. Geht nicht.

Explorer beendet. Starte Explorer via Task Manager nochmal.

Geht nicht; Task Manager hängt sich auf.

An dem Punkt ist die Hälfte meiner Fenster zu; ich habe weder Task Manager noch Explorer, nur Alt+Tab. Die separate Instanz Visual Studio 2015 hängt nun ebenfalls.

Ich hätte einfach den Strom kappen sollen, aber neee, ich wollte noch irgendwie ein sauberes Herunterfahren hinkriegen, um keine Daten zu verlieren. CTRL+ALT+DEL.

Nichts.

Nichts geht mehr.

Blue Screen (wichtiger Systemdienst wurde beendet). Festplatten fahren herunter (tun sie sonst nie). Rechner startet neu.

error 0x000001C4: cannot find ../boot/bcd – nichts geht mehr. Windows-Reparatur nötig.

Ende vom Lied: Festplatte voller Fehler. Search Indexer kann nicht starten weil Index zerschossen. Disk Management startet nicht mehr. Event Log sagt, ursprüngliche Ursache war out of paged pool. Fuck fuck fuck

Nachtrag: chkdsk startet nicht mehr; fsutil spuckt nur aus

Unsupported 16-Bit Application – The program or feature "\??\A:\Windows\system32\fsutil.exe" cannot start or run due to incompatibity with 64-bit versions of Windows. Please contact the software vendor to ask if a 64-bit Windows compatible version is available.

HAHA DIE WINDOWS-DATEIEN SIND SCHROTT, DAS WIRD LUSTIG

chkdsk.exe - Bad Image – A:\Windows\system32\ulib.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.

Aua, Scheiße. Mein Beileid.

So, es geht wieder halbwegs.

Erstmal sollte man die Systemdateien wiederherstellen (sfc /scannow), aber natürlich nicht, so lange das Dateisystem fratze ist. Also über die Recovery Disk die Reparaturkonsole starten, chkdsk /r /f c: ausführen. Komischerweise geht das nur für C: und nicht für andere Partitionen – Biberkacke – aber immerhin ist die Systemplatte dann wieder halbwegs verlässlich.

sfc /scannow muss man dann aus Windows starten, es geht nicht aus der Reparaturkonsole. Wtf?! Wenn ich kaputte Dateien wiederherstellen will, dann jawohl lieber vom Originaldatenträger als aus dem dllcache, der auf der kaputten Festplatte liegt?! Aber egal. Hat funktioniert.

Jetzt kann ich chkdsk aus Windows heraus für die anderen Festplatten aufrufen. In ein, zwei Stunden ist hoffentlich alles in Ordnung.

Nachtrag: Gemäß Event Log ist dem System schon drei Stunden zuvor der Nonpaged Pool ausgegangen. Das ist wirklich merkwürdig.

Viel Glück und Erfolg beim Wiederherstellen!