Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[OT] Taskkill sagt immer "Fehler: Nicht gefunden"
119 views
Skip to first unread message
Sven Lanoster
Jan 6, 2017, 4:07:05 PM1/6/17
to
Moin, moin.
Ich habe eine VM im LAN in einer Domäne mit Win 10 auf der mein User
lokaler Admin ist. Auf dieser Maschine sollen .bpl und .dll ausgetauscht
werden (automatisiert) und dazu muss der Prozess, der die verwendet,
beendet werden. Dafür gibts einen Batch, der
c:\windows\system32\taskkill.exe aufruft. Und nur auf dieser Maschine
funktioniert der Taskkill nicht ("Fehler: Nicht gefunden").
Testaufbau:
- Anmelden als Sven (Administrator)
- cmd.exe "als Administrator" starten (Rechtsklick)
- mit "notepad" den Texteditor starten
- den Task-Manager starten, Notepad hat die PID 4711 (Beispiel)
- "taskkill /IM notepad.exe" -> Fehler: Nicht gefunden
- "taskkill /PID 4711" -> Fehler: Nicht gefunden
- im Task-Manager "Task beenden" klicken und notepad ist weg
Ja, ich weiß, dass es noch die Schalter /F und /T gibt, aber die ändern
leider nichts am Verhalten.
Kann es sein, dass sich ein anderes Taskkill im Pfad vordrängelt, obwohl
ich in der Eingabeaufforderung in "c:\windows\system32\" bin? Obwohl,
mit /? bekomme ich die original Windows-Taskkill-Hilfe.
Der Domänen-Admin guckt zwar unschuldig, trotzdem die Frage: kann das
durch eine Gruppenrichtlinie so eingestellt werden?
Gibt es etwas in der Registry, das verstellt sein könnte?
Als Virenscanner läuft GData, aber obwohl ich den Dingern alles üble der
Welt zutraue, ist der wohl unschuldig.
Sollte ich lieber ein eigenes Konsolenprogramm mit Delphi schreiben,
welches mir den Process killt? ;)
Hat jemand sowas schonmal gesehen, erlebt oder gehört?
Die allwissende Müllhalde mag mich heute nicht. :(
Gruß,
Sven.
--
Seltsam? Aber so steht es geschrieben...
Ich habe eine VM im LAN in einer Domäne mit Win 10 auf der mein User
lokaler Admin ist. Auf dieser Maschine sollen .bpl und .dll ausgetauscht
werden (automatisiert) und dazu muss der Prozess, der die verwendet,
beendet werden. Dafür gibts einen Batch, der
c:\windows\system32\taskkill.exe aufruft. Und nur auf dieser Maschine
funktioniert der Taskkill nicht ("Fehler: Nicht gefunden").
Testaufbau:
- Anmelden als Sven (Administrator)
- cmd.exe "als Administrator" starten (Rechtsklick)
- mit "notepad" den Texteditor starten
- den Task-Manager starten, Notepad hat die PID 4711 (Beispiel)
- "taskkill /IM notepad.exe" -> Fehler: Nicht gefunden
- "taskkill /PID 4711" -> Fehler: Nicht gefunden
- im Task-Manager "Task beenden" klicken und notepad ist weg
Ja, ich weiß, dass es noch die Schalter /F und /T gibt, aber die ändern
leider nichts am Verhalten.
Kann es sein, dass sich ein anderes Taskkill im Pfad vordrängelt, obwohl
ich in der Eingabeaufforderung in "c:\windows\system32\" bin? Obwohl,
mit /? bekomme ich die original Windows-Taskkill-Hilfe.
Der Domänen-Admin guckt zwar unschuldig, trotzdem die Frage: kann das
durch eine Gruppenrichtlinie so eingestellt werden?
Gibt es etwas in der Registry, das verstellt sein könnte?
Als Virenscanner läuft GData, aber obwohl ich den Dingern alles üble der
Welt zutraue, ist der wohl unschuldig.
Sollte ich lieber ein eigenes Konsolenprogramm mit Delphi schreiben,
welches mir den Process killt? ;)
Hat jemand sowas schonmal gesehen, erlebt oder gehört?
Die allwissende Müllhalde mag mich heute nicht. :(
Gruß,
Sven.
--
Seltsam? Aber so steht es geschrieben...
Christian Schmitt
Jan 15, 2017, 4:03:45 AM1/15/17
to
Ich kenne das Problem - allerdings nur unter Windows 7.
Siehe dazu
https://support.microsoft.com/de-de/kb/2798040
Wie sieht es mit den Updates aus? Auf aktuellem Stand? Soweit ich weiß wird in dem o.g. Patch nur die Taskkill.exe ersetzt. Hast du eine andere Maschine (auf der es funktioniert), von der due die Taskkill.exe kopieren kannst?
Gruß
Siehe dazu
https://support.microsoft.com/de-de/kb/2798040
Wie sieht es mit den Updates aus? Auf aktuellem Stand? Soweit ich weiß wird in dem o.g. Patch nur die Taskkill.exe ersetzt. Hast du eine andere Maschine (auf der es funktioniert), von der due die Taskkill.exe kopieren kannst?
Gruß
Sven Lanoster
Jan 16, 2017, 1:40:24 PM1/16/17
to
Christian Schmitt schrieb:
> Hast du eine andere Maschine (auf der es funktioniert), von der due
> die Taskkill.exe kopieren kannst?
Geniale Idee! Bin ich nicht drauf gekommen.
Also erstmal das Original umbenennen in taskkill.exe.defekt *mööp* "Sie
brauchen TrustedInstaller-Rechte!". Äh, ja? Fürchte Dich Kiste, ich bin
hier Admin, ich zeigs dir! Cmd als Admin: ren taskkill.exe
taskkill.exe.defekt *Zugriff verweigert*. WTF?
Nicht ganz zufällig läuft auf der Maschine ein Dienst unter
SYSTEM-Rechten, den ich konfigurieren kann. Ich hatte schon darüber
nachgedacht, wie genau ich die Konfig ändern muss, um das Ding
umzubenennen, als mir ein Kollege empfahl, zuerst einmal die neue
Taskkill.exe als taskkill2 daneben zu legen.
Prima Idee, gesagt, getan! Und tatsächlich der "Fehler:" ist weg!
Jetzt lautet die Ausgabe nur noch " Nicht gefunden". Verblüffend.
> Hast du eine andere Maschine (auf der es funktioniert), von der due
> die Taskkill.exe kopieren kannst?
Also erstmal das Original umbenennen in taskkill.exe.defekt *mööp* "Sie
brauchen TrustedInstaller-Rechte!". Äh, ja? Fürchte Dich Kiste, ich bin
hier Admin, ich zeigs dir! Cmd als Admin: ren taskkill.exe
taskkill.exe.defekt *Zugriff verweigert*. WTF?
Nicht ganz zufällig läuft auf der Maschine ein Dienst unter
SYSTEM-Rechten, den ich konfigurieren kann. Ich hatte schon darüber
nachgedacht, wie genau ich die Konfig ändern muss, um das Ding
umzubenennen, als mir ein Kollege empfahl, zuerst einmal die neue
Taskkill.exe als taskkill2 daneben zu legen.
Prima Idee, gesagt, getan! Und tatsächlich der "Fehler:" ist weg!
Jetzt lautet die Ausgabe nur noch " Nicht gefunden". Verblüffend.
Christian Schmitt
Jan 22, 2017, 1:55:41 PM1/22/17
to
Am Montag, 16. Januar 2017 19:40:24 UTC+1 schrieb Sven Lanoster:
> Prima Idee, gesagt, getan! Und tatsächlich der "Fehler:" ist weg!
>
> Jetzt lautet die Ausgabe nur noch " Nicht gefunden". Verblüffend.
Achso, das "nicht gefunden" stört dich, ich dachte nur der Fehler ;-). Das einzige was mir jetzt noch einfällt ist, dass die PID vielleicht wirklich vom Taskmanager falsch angezeigt wird. Kannst du die PID mal mit der Eingabeaufforderung via "tasklist" anzeigen lassen. Stimmen die beiden überein?
> Prima Idee, gesagt, getan! Und tatsächlich der "Fehler:" ist weg!
>
> Jetzt lautet die Ausgabe nur noch " Nicht gefunden". Verblüffend.
Gruß
Sven Lanoster
Jan 23, 2017, 8:54:47 PM1/23/17
to
Christian Schmitt schrieb:
enttäuscht wurde. Ich nahm an, dass entweder das Programm Taskkill.exe
defekt ist, so dass ein Austausch zum erwarteten Verhalten führt, oder
dass eine der verwendeten Bibliotheken defekt ist, so dass ein Austausch
zu exakt derselben Meldung führen müsste. Und tatsächlich hat sich die
Meldung geändert.
> Das einzige was mir jetzt noch einfällt ist, dass die PID vielleicht
> wirklich vom Taskmanager falsch angezeigt wird. Kannst du die PID
> mal mit der Eingabeaufforderung via "tasklist" anzeigen lassen.
> Stimmen die beiden überein?
Ja. Zumal ja auch /IM fehlschlägt.
Also entweder ist da was bei Windows kaputt, oder mir fehlt die
Berechtigung.
Erinnert sich noch jemand, wie man Windows dazu bringt, seine
Systemdateien gegen das MS-Zertifikat zu prüfen?
Gegen die fehlende Berechtigung spricht, dass ich aus dem Taskmanager
heraus Prozesse beenden kann und darf. Also Absicht ist das (vermutlich)
nicht. Andererseits ist der Taskmanager inzwischen ziemlich höflich
geworden und fragt erstmal per Windows-Message nach, ob das Beenden
genehm ist. Der Taskkill könnte da rabiatere Berechtigungen haben wollen.
Könnte das ein Sicherheitsfeature sein, damit ich nicht "versehentlich"
den Virenscanner oder ein Tool des Domänen-Admins abschiesse?
Dagegen spricht wiederum, dass ich pskill von Sysinternals installiert
habe und das schießt munter alles mögliche ab. Leider auch die dllhost
von SYSTEM, was eher nicht erwünscht ist.
Das sind so die Momente, wo ich mich seufzend feue, nicht MS-Admin
gelernt zu haben, sondern Delphi-Programmierer.
> Am Montag, 16. Januar 2017 19:40:24 UTC+1 schrieb Sven Lanoster:
>
>> Jetzt lautet die Ausgabe nur noch " Nicht gefunden". Verblüffend.
Verblüffend finde ich immer noch, dass meine Erwartungshaltung
>
>> Jetzt lautet die Ausgabe nur noch " Nicht gefunden". Verblüffend.
enttäuscht wurde. Ich nahm an, dass entweder das Programm Taskkill.exe
defekt ist, so dass ein Austausch zum erwarteten Verhalten führt, oder
dass eine der verwendeten Bibliotheken defekt ist, so dass ein Austausch
zu exakt derselben Meldung führen müsste. Und tatsächlich hat sich die
Meldung geändert.
> Das einzige was mir jetzt noch einfällt ist, dass die PID vielleicht
> wirklich vom Taskmanager falsch angezeigt wird. Kannst du die PID
> mal mit der Eingabeaufforderung via "tasklist" anzeigen lassen.
> Stimmen die beiden überein?
Also entweder ist da was bei Windows kaputt, oder mir fehlt die
Berechtigung.
Erinnert sich noch jemand, wie man Windows dazu bringt, seine
Systemdateien gegen das MS-Zertifikat zu prüfen?
Gegen die fehlende Berechtigung spricht, dass ich aus dem Taskmanager
heraus Prozesse beenden kann und darf. Also Absicht ist das (vermutlich)
nicht. Andererseits ist der Taskmanager inzwischen ziemlich höflich
geworden und fragt erstmal per Windows-Message nach, ob das Beenden
genehm ist. Der Taskkill könnte da rabiatere Berechtigungen haben wollen.
Könnte das ein Sicherheitsfeature sein, damit ich nicht "versehentlich"
den Virenscanner oder ein Tool des Domänen-Admins abschiesse?
Dagegen spricht wiederum, dass ich pskill von Sysinternals installiert
habe und das schießt munter alles mögliche ab. Leider auch die dllhost
von SYSTEM, was eher nicht erwünscht ist.
Das sind so die Momente, wo ich mich seufzend feue, nicht MS-Admin
gelernt zu haben, sondern Delphi-Programmierer.
Christian Schmitt
Jan 28, 2017, 3:22:53 AM1/28/17
to
Hmmm, sorry, dann muss ich jetzt auch passen. Aber wenn pskill funktioniert, reicht dir das nicht aus?
0 new messages