Automatische DLL suche modifizieren

[Schnepel83]

Hallo,

hiermit nun zu meinem Problem: Mein Windows 2000 Pro hat ein Ramdrive Z:, also eine Ramfestplatte. Da diese natürlich nach dem Start keine Daten habe kann, werden per Gruppenrichtlinie und einer Batch alle Daten von der C: auf die Z: kopiert. Dieses geschieht bevor der Nutzer angemeldet wird, so das dieser bereits von Z: geladen werden kann.

Nun allerdings das Problem der Geschichte, denn Windows greift immer noch Primär auf die C: zu, also zum starten den explorer sowie für spätere von Z: geladenen Programme auch die dll's. Dabei geht das Suchsystem automatisch folgende Ordner nacheinander durch: C:\Windows, C:\Windows\System32, Z:\Windows, Z:\Windows\System32... Somit wird leider primär die C: durchsucht, worauf aber nicht zugegriffen werden soll, weil es eine CF-Karte ist, welche nicht besonders schnell ist und der Ram ist nun mal locker 10x schneller.

Somit bräuchte ich nur eine Möglichkeit, erst die Z: zu durchsuchen und später die C:, somit würde das System alle Daten, welche vor dem Kopieren nicht auf der Z: sind gefunden werden und später primär von der Z: geladen werden.

Möglichkeiten zu Modifikation wie Regedit, Reshack und Hexedit sind vorhanden.

Vielen Dank.

[EBFE]

Wenn man diesem Artikle glauben darf:
Von Windows verwendeter Suchpfad zum Auffinden einer DLL (http://msdn.microsoft.com/de-de/library/7d83bc18.aspx)
wird man wohl nicht drumherum kommen, die Umgebungsvariablen (http://de.wikipedia.org/wiki/Umgebungsvariable) wie "WINDIR"/"SystemRoot"/"SystemDrive"/"PATH" usw (einfach in der Konsole "SET" eingeben und sich diese anzeigen lassen) zu ändern.
Das sollte sich über die Registry (RegKey: HKCU\Environment\bla) setzen lassen.
D.h die ganzen "C:\WINDOWS" Dinge ersetzen + "SystemDrive" nicht zu vergessen.

Mögliche Vorgensweise: z.B in dem man einmal die Einträge per Hand im RegEdit ändert und dann diese in eine REG-Datei exportiert. Die REG Dateien lassen sich dann beim Starten z.B über Batch automatisch "einbinden".

[Hu5eL]

hätte ich auch behauptet wenn du die ganzen umgebungsvariablen umschreibst dann sollte das meiste "umgelenkt" sein, aber alle zugriffe wirst du nicht auf dien z umlenken können, glaube kaum das man alle links etc findet.

[EBFE]

@Hu5el: jep, es gibt "hardcodierte" Pfade in der Registry (sind afaik auch öfters als "\\?\Volume{bla}\" oder so ähnlich kodiert).
Jedoch kann man sich damit ganz schnell das System zerschießen, weil es dann beim Booten nicht die Daten vorfindet.
Solange man nur den HKCU Registryzweig modifiziert, ist der Schaden, den man anrichten kann, relativ klein.
Zudem sollte der Großteil der "Kernsachen" (die man nicht umbiegen kann) schon beim Booten geladen werden. Der "Kernel" wird eher soweit es möglich ist im RAM gehalten.

[Schnepel83]

Hallo,

Vielen Dank, ich habe dank Eurer Hilfe einen guten Kompromiss gefunden.

1. Globale Umgebungsvariable war leider nicht erfolgreich, wie befürchtet... denn Klar, alle Dienste etc müssen weiterhin auf der C: laufen...

2. User Umgebungsvariable war leider ebenfalls weniger erfolgreich, weil er leider immer noch primär auf C: zugegriffen hat.

3. Sperren der Festplatte C: für den betroffenen User inc. User Umgebungsvariable: Damit ist es dem User nicht möglich auf die C: zuzugreifen... nachdem alle Links etc angepasst waren ist es relativ erfolgreich... Somit laufen alle Dienste auf C: und der User nur auf Z:

Ein umkehren des Suchverhaltens wäre mir lieber gewesen, aber so kann ich damit grenzwertig mit leben.
Falls jedoch jemand eine neue Idee hat, gerne her damit.