Konsolenprogramm und Shutdown verhindern

[xpmd]

Hi,

ich habe folgendes Szenario: Ich habe einen Dienst der normal unter SYSTEM-Account läuft. Auf diesen Dienst habe ich Codetechnisch keinen Zugriff. Dieser Dienst startet allerdings eine von mir geschriebene Konsolenanwendung. Nun muss diese Konsolenanwendung die Fähigkeit haben, wärend sie läuft, den Shutdown zu verhindern.

Da ich ja kein Fenster habe, und die Konsolenanwendung auch vom Dienst unter SYSTEM gestartet wird, kann ich die Lösung über WM_QueryEndSession vergessen.

Bleibt mir quasi noch die SetConsoleCtrlHandler und dort CTRL_SHUTDOWN_EVENT abfangen. Klappt soweit gut, Nur weiß ich jetzt nicht wie ich innerhalb dieses Events den Shutdown tatsächlich verhindern kann, so wie es über WMQueryEndSession gehen würde. Weiß jemand eine Lösung?

Grüße,
xpmd

[new32]

Unter nt4-xp:

mit NtSetInformationProcess (und NtCreateToken) allen Prozessen das SeShutdownPrivilege entziehen.

Achtung: Die Funktion ist nicht von ms dokumentiert und funktioniert nicht mehr unter vista!


Und noch ne Lösung [einfacher und besser]:

Mit SuspendThread alle Threads von winlogon auf eis legen. dann dürfte das system erst runterfahren, wenn winlogon wieder mit ResumeThread aufgetaut wird.

[Muetze1]

Moin!

Es gibt aber gute Literatur dazu:

MfG
Muetze1

[new32]

Ein sehr gutes Buch!
Aber wie der Titel schon sagt nt/2k!

Unter vista lässt sich das AccessToken nicht mehr ändern wenn der Prozess läuft (wie ich letztens erfahren musste).

Von daher ist es besser Winlogon einzufrieren.

[Luckie]

Zitat von new32:

mit NtSetInformationProcess (und NtCreateToken) allen Prozessen das SeShutdownPrivilege entziehen.

Warum schon wieder eine undokumentierte API-Funktion? Einfach beim Abfangen der Nachricht den entsprechenden Wert zurück geben. Allerdings kann man unter Vista das Runterfahren nicht mehr so einfach verhindern.

Warum darf der Rechner denn nicht runtergefahren werden, wenn dein Programm läuft?

[Zacherl]

Die Lösung über WM_QUERYENDSESSION geht doch nicht, weil er einen Service verwendet.

Mach doch einen Hook auf ExitWindowsEx.

[Apollonius]

Was spricht gegen einen zusätzlichen Thread mit einem Fenster, über das man die Nachricht erhält?

[new32]

Zitat von Luckie:

Warum schon wieder eine undokumentierte API-Funktion?

Sorry mir is in dem Moment keine andere Lösung eingefallen.
Aber ich hab ja auch davon noch abgeraten; ich wollte es nur nicht komplett löschen, weil es ja auch ne Lösung ist.

Aber was spricht gegen die Methode mit winlogon?

[new32]

2x auf absenden gedrückt sorry. Ich dachte der Browser würde hängen

[xpmd]

Zitat von new32:

Zitat von Luckie:

Warum schon wieder eine undokumentierte API-Funktion?

Sorry mir is in dem Moment keine andere Lösung eingefallen.
Aber ich hab ja auch davon noch abgeraten; ich wollte es nur nicht komplett löschen, weil es ja auch ne Lösung ist.

Aber was spricht gegen die Methode mit winlogon?

Hmm alle Winlogon-Threads schlafen lassen? Ist das nicht etwas brachial? Der PC sollte in der Zeit eigentlich ganz normal weiter arbeiten können. Im Hintergrund läuft währenddessen eine Software-Installation.

Zitat von new32:

Unter nt4-xp:

mit NtSetInformationProcess (und NtCreateToken) allen Prozessen das SeShutdownPrivilege entziehen.

Achtung: Die Funktion ist nicht von ms dokumentiert und funktioniert nicht mehr unter vista!


Und noch ne Lösung [einfacher und besser]:

Mit SuspendThread alle Threads von winlogon auf eis legen. dann dürfte das system erst runterfahren, wenn winlogon wieder mit ResumeThread aufgetaut wird.

Wär für XP ne Lösu8ng. Undokumentierte API-Funktionen will ich aber eigentlich vermeiden. Für Vista gibts ja die neue Shutdown-API. Mit der könnt ich mir schon ne Lösung vorstellen. Aber Vista hat auch eine undokumentierte CancelShutdown Funktion

Zitat von Zacherl:

Die Lösung über WM_QUERYENDSESSION geht doch nicht, weil er einen Service verwendet.

Mach doch einen Hook auf ExitWindowsEx.

Hab mich noch überhaupt nicht mit Hooks beschäftigt. Wär evtl ne Lösung aber wie gesagt noch ein absolut unberührtes Thema für mich.

Zitat von Apollonius:

Was spricht gegen einen zusätzlichen Thread mit einem Fenster, über das man die Nachricht erhält?

Hatte ich schon probiert. Komischerweise erhielt das Fenster keine Message. Lags evtl daran dass das Konsolenprogramm eben von einem Dienst unter SYSTEM gestartet wurde, und das Fenster unsichtbar ist.? Oder hab ich da was im Code verpeilt, werds mir nochmal anschaun.