Ich habe hier eine Anwendung, die beim Beenden manchmal im Speicher hängen bleibt. Das liegt an einer
DLL, die offenbar schlampig programmiert ist.
Sprich: die Anwendung wird garnicht beendet. Vielleicht wird das zugehörige Fenster geschlossen, aber die Anwendung ja offenbar nicht. Denn aufgrund des Speicher- und Prozeßmodells in Windows ist es ein Ding der Unmöglichkeit, daß da etwas zurückbleibt.
Ich habe also diverse Dinge probiert, u.a. schickt die Anwendung einer anderen EXE (=der Wächter) eine Message, die daraufhin mit Killprocess versucht, das Teil zu entfernen. Klappt nicht immer.
Unter welchen Bedingungen klappt es denn? Seit Vista können Anwendungen selber entscheiden ob sie Fensternachrichten von außen annehmen und wenn ja welche.
1. Gibt es eine 'best practice', um mit DLLs umzugehen? z.b. nicht statisch (eh blöd), kontrollierter Shutdown (d.h. die
DLL entladen) usw.
"Nicht statisch"? Du könntest die
DLL teils ersetzen. Wenn sie nur wenige Funktionen exportiert und es sich um keine wohlbekannte (System-)
DLL handelt, ist das trivial. Bekannt sein dürfte dir ja der Begriff "
DLL placement attack" - die von mir vorgeschlagene Methode ist eine Variante davon. Man kann sie benutzen um die eigene
DLL in den Zielprozeß zu befördern welche dann wiederum die echte
DLL lädt und die Funktionen weiterleitet soweit das nötig ist. Für alles andere kann die eigene
DLL dann die Kontrolle übernehmen und bspw.
ExitProcess aufrufen, womit der Prozeß dann auch das zeitliche segnen würde.
2. Gibt es eine 100% sichere Möglichkeit eine EXE aus dem Speicher zu entfernen?
Nein. Wenn du die Frage so stellst lautet die einzige (aber nicht sinnvolle) Antwort: bei Zimmertemperatur den Rechner mehrere Minuten vom Stromnetz trennen.
Wenn es dir um die EXE als Abbild für den Prozeß geht, dann reicht einfaches Beenden des Prozesses. Schließen des zugehörigen Fensters reicht nicht immer ...
3. Wie schafft Windows es beim Abmelden / Runterfahren, jede EXE aus dem Speicher zu kicken. Welche
API-Funktion ist das (außer "Shutdown"
)
Erstens gibt es einige APIs die zum Umfeld der Terminal Server
API gehören, welche brutalere Geschütze auffahren und zweitens noch die Native
API. Beim Shutdown dürfte der Fall aber meines Wissens nach anders liegen. Hier dürfte wohl der Session Manager (smss.exe) das Sagen haben und ohne weiteres in der Lage sein die Prozesse abzuschießen, denn der Session Manager ist es auch der bspw. das
Win32-Subsystem startet.
4. Wenn ich die Anwendung in der Delphi-
IDE ausführe und sie mal wieder bockig ist, schafft Delphi das mit Strg-F2. Was steckt dahinter?
Der Debugger?!
