Guten morgen liebe Community!

Ich habe in einer VirtuellenMachine mir ReactOS installiert.
Von einem Freund einen System-Treiber für Ram-Laufwerke bekommen wo er viele Probleme mit hat. (Geschrieben in C/C++.)

Fragen:
1. Kann man überhaupt Treiber die beim Systemstart geladen werden überhaupt debuggen?
2. Was benötige ich wenn 1. = Ja ergab ?

Danke fürs Lesen und Input!

Ist das ein Kernel Mode-Treiber?

Schön wäre es ja, wenn viel mehr als User Mode-Treiber umgesetzt würde und dadurch das System etwas stabiler würde.
Fehler im Kernel rauchen meist schön blau ab.
Und da es hier nicht zu hardwarenah ist, würde nichts gegen den User Mode sprechen.

https://docs.microsoft.com/en-us/win...dows-debugging

Ja, es gibt bestimmt ein paar hier, die bei Treibern helfen können,
aber da man mit Delphi nicht wirklich Treiber erstellen kann, kennt sich hier fast niemand damit aus.
Assarbad dürfte einer der Wenigen sein, die noch aktiv sind oder leben.

Ansonsten darfst dich auch gern nach dem Stichwort "Delphi Driver Development Kit" (DDDK) umsehn.
Vielleicht findet sich dort auch der eine oder andere gute Hinweis.
Aber ich denke da dürfte dann mit FreePascal (z.B. Lazarus) es einfacher sein, mit Pascal einen Treiber zu schreiben, als mit Delphi.

Zitat von himitsu:

Ist das ein Kernel Mode-Treiber?
Fehler im Kernel rauchen meist schön blau ab.

Jupp und jupp. Genau das sind seine Probleme
Treiber Installation führt nach Neustart zu einem BSOD bevor die WindowsGUI geladen wird.

Ps: Dieses Thema hat leider nichts mit unserem geliebten Delphi am Hut.

Ach ja, neben Olliver (assarbad.net) dann gab es noch NicoDE (Nico Bendlin, bendlins.de/nico), aber ich weiß nicht, ob er aktuell wieder im Forum ist.

Wie gesagt, im User Mode würde der Treiber, ähnlich unseren "normalen" Programmen arbeiten, und könnte so das System nicht mehr so einfach verrecken lassen. (seit WinNT ist das alles ja vom System mehr abgetrennt)
Wenn das ein selbstgeschriebener Treiber ist, und der sowieso nicht funktioniert , dann wäre es bestimmt keine schlechte Idee den gleich neu zu schreiben.

Danke himitsu. Das werde ich mal Schritt für Schritt durchprobieren, mal schaun ob ich ans Ziel damit komme. Nun habe ich zumindest einen Ansatz

Und links etwas umschauen.
"Debugging Techniques" klingt auch nett.

Im "Windows Driver Kit" ist/war mal der QuellCode für eine RAM-Disk drin (Ramdisk.sys),
aber ich glaub auch im Kernel Mode.

Und falls man nur in seinem Programm eine "Art" RAMDisk benötigt, dann schaut auch mal nach
CreateFile + FILE_ATTRIBUTE_TEMPORARY + FILE_FLAG_DELETE_ON_CLOSE
und eventuell THandleStream

und/oder Memory Mapped Files (MMF)

Und es wäre auch möglich im Delphi-Programm physischen Speicher im RAM zu reservieren.
Ich war vor Kurzem über die aktivierte Speicherkomprimierung im Windows 10 gestolpert ... fast 60 GB (mit 0 gefülltem) Speicher in nur 16 GB RAM bekommen , ohne Auslagerungsdatei in einem 32 Bit-Delphi-Progrämmchen.

Zitat von himitsu:

Und es wäre auch möglich im Delphi-Programm physischen Speicher im RAM zu reservieren.
Ich war vor Kurzem über die aktivierte Speicherkomprimierung im Windows 10 gestolpert ... fast 60 GB (mit 0 gefülltem) Speicher in nur 16 GB RAM bekommen , ohne Auslagerungsdatei in einem 32 Bit-Delphi-Progrämmchen.

Das finde ich gerade interessanter als meine eigentliche Topic und frage mal nach ob es davon eine frei zugängliche Demo/Quelltext existiert?
Da fallen mir mehrere Sachen ein wo ich's pers. super gebrauchen könnte. Die "üblichen" varianten wie bereits von Dir angeschnitten sagen mir was.
Meine Versuche mehr ausm RAM zu holen sind meist immer in einem MemoryStream geendet mit Komprimierung von den U.P.X. Entwicklern (LZMA).
Bei kleinst Aufgaben klappte das recht gut aber was Du da schreibst hebt das ganze auf ein weit höheres Level.

Mit hab ich jetzt nur die 8 Jahre alte EXE und der Rest liegt (hoffentlich) irgendwo daheim in den Archiven, aber über VirtualAlloc wird man dazu auch was finden können.

Bei sowas muß man aufpassen, denn wenn für das System kein physischer RAM zur Verfügung ist, dann kann es auch komplett hängen bleiben.
Hier ist das einfach nur die Minimalversion von den "angeblichen" RAM-Optimieren.
Windows wird dazu gezwungen allen Speicher auszulagern (MMFs entladen, Programmspeicher in die Auslagerungsdatei und den FileCache leer),
wobei Letzteres zu Testzwecken und für gewisse größere Operationen die eigentliche Funktion dieses Progrämmchens ist.

Für aktive Programme wäre aber physischer Speicher, ein großes WorkingSet und hohe Prozesspriorität meistens nicht Ideeal, für das GesamtSystem.
Ausnahmen sind z.B. der TaskManager oder Sicherheitsfunktionen, wie der Kern des VirenScanners.
Ich würde mir wünschen Windows würde das für den Task-Manager von sich aus standardmäßig so machen, denn nichts nervt mehr, wenn irgendwas ist und man nichts machen kann, weil der Taskmanager ewig garnicht reagiert.

Aber auch für Passwörter/Verschlüsselung könnte man das nutzen, damit sie nicht in der Auslagerungsdatei / auf der Festplatte landen können.
Man kann zwar Windows beim Beenden sagen dass es diese Datei "sicher" löschen soll
und während des Betriebs kann man (eigentlich) nicht auf diese Datei zugreifen,
aber wenn man die Programme zum Auslagern zwingt und dann den Strom abzieht (harter Reset), dann ......

TMemoryStream + TZCompressionStream
oder direkt ein TStream nachfahre, wo man eine den MemoryStream mit einer Block-Komprimierung verknubbelt.

Wie gesagt, inzwischen macht Windows das auch von sich aus (auf Heim-Windows-Versionen standardmäßig seit 2015 aktiv)
Leider wird das mehr an Leistung durch anderen Mist wieder sinnlos vernichtet.
z.B. wird seit einer Weile bei Systemstart (eigentlich bei Start/Neustart der explorer.exe) der blöde Edge gestartet, damit er bei ersten Benutzen schneller da ist. (selbst wenn man diesen Mist garnicht benutzt)
Und auch andere Programme (MS Office und andere Hersteller) machen so einen Scheiß.

Selbst im RAM zu komprimieren bringt also aktuell kaum einen Vorteil.
Falls man Angst hat, dass die Auslagerungsdatei voll wird und nicht reicht, kann man selbst Speicher gegen eine eigene Datei mappen. (MMF)
Oder einen FileStream THandleStream mit CreateFile + FILE_ATTRIBUTE_TEMPORARY verwenden.
Zusätzlich eventuell noch FILE_FLAG_RANDOM_ACCESS oder FILE_FLAG_SEQUENTIAL_SCAN. (auch wenn ich leider hier im Windows seit Jahren keine merkliche Wirkung erkennen kann )

Wer sehr sehr viele Daten rumschaufeln muß, aber den RAM und WindowsFileCache nicht vollmüllen will (Programme nicht zum Auslagern zwingen),
der nutzt eben CreateFile mit FILE_FLAG_NO_BUFFERING und FILE_FLAG_WRITE_THROUGH.
Denn auch wenn man Windows sagt, dass Programme bevorzugt werden sollen (standardmäßig wird der FileCache bevorzugt), werden dennoch zuerst Programme ausgelagert, bevor Windows den Cache leert.
Man kopiere einfach mal paar 100 GB/TB umher.
Besonders krank fand ich grade eben erst, dass FTP über den Explorer durch den Cache des Internet Explorers rauscht.
Obwohl dort 330 MB als Grenze drin stehen, war gestern plötzlich mein SSD übervoll, nur weil ich paar Aufnahmen von meiner VU+ ins NAS verschieben wollte ... und dieser Cache erst ganz am Ende der "gesamten" Kopieroperation nach paar Minuten freigegeben wird.
Das erklärt dann auch, warum der Explorer manchmal "alte" Dateien kopiert, selbst wenn die auf dem FTP inzwischen aktualisiert wurden.



PowerShell (Administrator) :

markieren

Code:

Get-MMAgent
Enable-MMAgent -mc
Disable-MMAgent -mc

https://docs.microsoft.com/en-us/pow...?view=win10-ps

Nja, bisslang gab es den Arbeitsspeicher und die Auslagerungsdatei
und nun dazwischen auch noch die Speicherkomprimierung,
wo Windows den virtuellen Arbeitsspeicher und die MMFs (z.B. den gemappten Code und die Ressourcen der EXE) drin verteilt.
* es wird nicht sofort ausgelagert (erstmal nur komprimiert und so Speicher gespart)
* und beim Auslagern und zurückholen geht es auch schneller, wenn dort das komprimierte gespeichert wird ... weil ja weniger Daten zum, vom und auf dem Datenträger.
Task-Manager > Leistung > Arbeistspeicher > In Verwendung (komprimiert)
Task-Manager > Performance > Memory > In use (Compressed)

Dann gibt es noch Superfetch (im XE der Vorgänger Prefetch), was "oft" genutzte Dateien schon vorläd, damit bei Nutzung es schneller geht.

In jedem Programm gibt es auch einen Teil, die nie ausgelagert wird (WorkingSet).
https://docs.microsoft.com/en-us/sys...loads/cacheset

Und es gibt die Möglichkeiten im physischen RAM etwas Speicher zu reservieren und in den virtuellen Speicher des Programms zu mappen.

Bei Memory-Mappes-Files wird eine Datei in den virtuellen Speicher gemappt.
Wenn möglich lieg der Speicher im RAM (FileCache) oder eben nur in der Datei, wenn noch nicht zugegriffen wurde oder ausgelagert werden musste.
Schreibzugriffe werden dann vom Windows über den FileCache in die Datei weitergeleitet.

Dann kann man im NTFS die HDD/Dateien und sogar Systemdateien komprimieren.
Das ist dan ähnlich einer SpraseFile, da wird blockweise Komprimiert und ungenutzte Teile werden ausgeschnitten (nicht gepseichert).
PS: Die NTFS-Verschlüsselung arbeitet ähnlich, drum kann man das und nicht gleichzeitig verwenden.

So viel Input, wow wow wow

Ich druck mir das mal aus und lese es abends, vielen Dank für Deine Mühe!!!