Anwendung 100%ig garantiert beenden (lassen)?

[Furtbichler]

Hallo Leute,

Ich habe hier eine Anwendung, die beim Beenden manchmal im Speicher hängen bleibt. Das liegt an einer DLL, die offenbar schlampig programmiert ist.

Manchmal bleibt also die Anwendung im Speicher kleben. Da sie als "Singleton-EXE" umgesetzt ist, d.h. nur einmal gestartet werden kann, blockiert diese Leiche alle Versuche, die Anwendung neu zu starten (logisch, sie ist ja noch 'da').

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.

Das blöde Ding will manchmal auch über den Taskmanager nicht weichen. Da hilft dann nur "abmelden", wobei Windows es irgendwie hinbekommt, das Teil entgültig zu vernichten.

Meine Fragen:
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.
2. Gibt es eine 100% sichere Möglichkeit eine EXE aus dem Speicher zu entfernen?
3. Wie schafft Windows es beim Abmelden / Runterfahren, jede EXE aus dem Speicher zu kicken. Welche API-Funktion ist das (außer "Shutdown" )
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?

[Sir Rufo]

Probier mal den Prozess mit dem pskill von SysInternals zu entfernen, evtl. schafft der das.

Warum Windows das beim Abmelden schafft (oder auch der Debugger von Delphi) liegt wohl darin begründet, dass dort beim Beenden dem Prozess die Grundlage entzogen wird, also der Ast abgesägt wird, auf dem der sitzt

[Uwe Raabe]

Vielleicht hilft es, wenn du eine Art Wrapper-Anwendung um die eigentliche Exe legst, die diese mit CreateProcess zum Leben erweckt. Als Owner dieses Prozesses müsste man den mit TerminateProcess eigentlich immer beendet bekommen.

[Assarbad]

Zitat von Furtbichler:

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.

Zitat von Furtbichler:

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.

Zitat von Furtbichler:

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.

Zitat von Furtbichler:

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 ...

Zitat von Furtbichler:

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.

Zitat von Furtbichler:

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?!

[Delphi-Laie]

Viele Köche verderben eben den Brei. Die Frage, ob eine bereinigte Version der DLL zu bekommen ist, wage ich gar nicht erst zu stellen.

Kann man das Programm nicht mit Debugprivilegien wahrscheinlicher beenden? Ich habe keine Ahnung, ob die nur "von außen" möglich sind, oder ob das Programm selbst mit solchen Privilgien sich wahrscheinlicher selbst beenden kann, ist nur so eine Idee von mir.

[Assarbad]

Zitat von Delphi-Laie:

Viele Köche verderben eben den Brei. Die Frage, ob eine bereinigte Version der DLL zu bekommen ist, wage ich gar nicht erst zu stellen.

Keine Ahnung was du mit bereinigt meinst. Ich meinte nur, daß du dem Programm eine eigene DLL unterschieben könntest, der du dann ggf. mitteilst, daß sie ExitProcess aufrufen soll. Welcher Code innerhalb einer Anwendung diese Funktion aufruft ist nämlich im Endeffekt egal.

Zitat von Delphi-Laie:

Kann man das Programm nicht mit Debugprivilegien wahrscheinlicher beenden? Ich habe keine Ahnung, ob die nur "von außen" möglich sind, oder ob das Programm selbst mit solchen Privilgien sich wahrscheinlicher selbst beenden kann, ist nur so eine Idee von mir.

Warum wahrscheinlicher? Die Privilegien sollten hier allerhöchstens für jemanden von außen eine Rolle spielen. Das Programm selber kann sich normalerweise immer beenden. Kannst ja nochmal mit dem Process Explorer nachgucken welche ACEs gesetzt sind, also welche Rechte außenstehende Entitäten an dem Prozeß haben.

[Delphi-Laie]

Zitat von Assarbad:

Zitat von Delphi-Laie:

Viele Köche verderben eben den Brei. Die Frage, ob eine bereinigte Version der DLL zu bekommen ist, wage ich gar nicht erst zu stellen.

Keine Ahnung was du mit bereinigt meinst.

das:

Zitat von Furtbichler:

Ich habe hier eine Anwendung, die beim Beenden manchmal im Speicher hängen bleibt. Das liegt an einer DLL, die offenbar schlampig programmiert ist.

[jaenicke]

Es kann sich auch lohnen die aktuellen Warteschlangen anzuschauen um herauszufinden, ob es nur ein Deadlock oder so ist. Denn in so einem Fall könnte man (wie es auch Windows 7 anbietet, wenn es das bei einem Prozess erkennt) den Deadlock auflösen und dem Prozess so die Beendigung ermöglichen.

Typisch sind solche Fehler bei Verwendung von Threads, z.B. mit den Indy Komponenten.

Die Warteschlangen kannst du am einfachsten (aber nicht vollständig) über den Process Explorer sehen und auch Delphi bringt entsprechende Möglichkeiten im Thread-Fenster mit.

[Assarbad]

Zitat von jaenicke:

Die Warteschlangen kannst du am einfachsten (aber nicht vollständig) über den Process Explorer sehen und auch Delphi bringt entsprechende Möglichkeiten im Thread-Fenster mit.

... oder WinDbg