[Windows XP Embedded]Taskkill error: Generic failure

[Arethusa]

Op een Windows XP Embedded image wil ik een draaiend proces (On Screen Keyboard) afsluiten middels taskkill.

Ik gebruik dit in combinatie met OSKGina om een on screen keyboard te gebruiken tijdens het aanmelden op de Thin Client. Deze client is namelijk verbonden met een Touch Screen.

Het proces osk.exe blijft draaien op de achtergrond (het toetsenbord zelf is niet meer zichtbaar) na aanmelden en is daarom niet nog een keer op te starten.

Dit probleem is bekend, zie ook dit topic.

Ik gebruik hiervoor het volgende commando:

c:\Document and Settings\Administrator>Taskkill /F /IM /osk.exe

Dit resulteert echter in de volgende fout:

c:\Document and Settings\Administrator>Taskkill /F /IM /osk.exe
Error: Generic failure

Dit topic bracht me erop om mijn systeem variabelen na te kijken.

Dat leverde het volgende op:

PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem

Volgens dat topic moeten deze variabelen %SystemRoot%\system32;%SystemRoot%; in het lijstje voorkomen en dat doen ze.

De applicatie rechtstreeks vanuit de map c:\windows\system32 starten levert dezelfde fout op.

Mijn Windows XP Pro installatie kan overigens Taskkill prima uit voeren, het lijkt toch een probleem binnen het Windows XP Embedded image te zijn.

Deze image heb ik niet zelf gemaak, hooguit wat aangepast op gebruikersbeheer gebied. Dit image is afkomstig van de HP Thin Client t5730.


Heeft iemand een idee hoe ik Taskkill op het systeem werkend kan krijgen? Ik kan natuurlijk ook pskill gebruiken maar ik wil het graag via Taskkill oplossen gezien het feit dat dit standaard in het image zit ingebakken.

[ Voor 23% gewijzigd door Arethusa op 20-05-2009 13:20 ]

[Arethusa]

Ik heb tot op heden nog geen oplossing voor dit probleem gevonden. Is iemand bekend met Taskkill?

[Poltergeist]

pskill hoeft niet geinstalleerd te staan, die kun je gewoon kopieren vanaf een server. Maar werkt het daarmee wel dan?. En kun je wellicht tskill gebruiken (is dacht ik ook standaard). Onder welk account draait OSK?

[Arethusa]

Het process osk.exe draait onder het SYSTEM account.

Pskill heb ik gehaald uit het Sysinternals pakket.

Pskill is wel bruikbaar in combinatie met een registry key welke de EULA accepteerd (de EULA moet ik bij de gebruiker Operator telkens opnieuw accepteren) maar dan krijg ik met het volgende command nog een Acces denied melding:

pskill osk.exe

Overigens maakt het niet uit of ik in dit commando ook de gebruikersnaam en password van de Administrator meegeef.

Ik heb deze gebruiker aan de power users groep toegevoegd. Ik kan deze via een omweg wel aan de Administrators groep toevoegen maar dat wil ik niet. Full control toekennen aan de gebruiker operator op osk.exe haalt ook niets uit. Pskill kan dan het proces osk.exe niet killen.

Onder de Administrator gebruiker werkt het allemaal prima.

Het probleem is eigenlijk dat de gebruiker Operator waaronder pskill draait niet gemachtigd is om een proces van de gebruiker SYSTEM te sluiten.

[alt-92]

Arethusa schreef op maandag 25 mei 2009 @ 10:59:

Het probleem is eigenlijk dat de gebruiker Operator waaronder pskill draait niet gemachtigd is om een proces van de gebruiker SYSTEM te sluiten.

Dat is geen probleem, dat hoort zo
Je kan er natuurlijk omheen werken door een andere post-logon job te gebruiken (running als local system) die een check doet of user Operator is ingelogd en dan alsnog het proces afsluit.

Beetje scripten moet dan wel kunnen

[Arethusa]

Dit is de eerste keer dat ik met batch scripts bezig ben maar ik zal proberen of ik zulks in elkaar knutselen kan. Ik moet dus een post-logon job (een batch file?) gebruiken die onder local system draait (hoe doe ik dat?). Ik wil alleen wat tips in die richting, geen kant en klare oplossing gezien het feit dat het dan weer een script request word.

[mhoogendam]

Probeer eens(de extra slash is weg):

code:

Taskkill /F /IM osk.exe /T

/T Tree kill: terminates the specified process and any child processes which were started by it.

Eventueel kan je taskkill nog uit laten voeren onder een andere user.

[ Voor 30% gewijzigd door mhoogendam op 26-05-2009 14:08 ]

[Arethusa]

Ik mag vanuit de Operator niet in de Adminstrator komen. Taskkill werkt niet op het embedded systeem. Ik krijg dan de fout Generic failure. Ook onder uitvoeren Taskkill os.exe.

[ Voor 54% gewijzigd door Arethusa op 25-05-2009 12:05 ]

[alt-92]

Wat heb je ter beschikking, Takenplanner, werkt die? Of is die niet aanwezig?

[Arethusa]

De taken planner is niet beschikbaar als ik als Operator ingelogd ben. Wel kan ik via de Administrator een taak aanmaken en dan het batchbestand aanwijzen. Vervolgens geef ik de log in gegegevens van de Operator gebruiker mee. Dat resulteert nog steeds in een Acces denied melding.

Overigens levert het utivoeren van Tasklist ook een generic failure fout op.

[alt-92]

Arethusa schreef op maandag 25 mei 2009 @ 13:22:
De taken planner is niet beschikbaar als ik als Operator ingelogd ben. Wel kan ik via de Administrator een taak aanmaken en dan het batchbestand aanwijzen. Vervolgens geef ik de log in gegegevens van de Operator gebruiker mee. Dat resulteert nog steeds in een Acces denied melding.

Ja duh

Ik snap niet waarom je volhardt in het gebruiken van die Operator useraccount terwijl je de hint al hebt gekregen en de middelen wel beschikbaar hebt
Laat die taak (die je desnoods als Admin aanmaakt > gebruik schtasks.exe daar maar eens voor op de commandline) runnen onder (local)System dan?

offtopic:
Dat je een generic fail krijgt zal hoogstwaarschijnlijk komen omdat zelfs debug info/error info niet onder de rechtenset van je Operator usert valt - die kan je gewoon niks laten zien

[ Voor 12% gewijzigd door alt-92 op 25-05-2009 19:11 ]

[Arethusa]

Ok, ik zal je tips eens ter hand nemen. Hiermee moet het wel lukken.

[mhoogendam]

Je geeft aan dat taskkill wel onder de admin werkt.

quote: Taskkill.exe /?

TASKKILL [/S system [/U username [/P [password]]]]
{ [/FI filter] [/PID processid | /IM imagename] } [/F] [/T]

Description:
This command line tool can be used to end one or more processes.
Processes can be killed by the process id or image name.

Parameter List:
/S system Specifies the remote system to connect to.

/U [domain\]user Specifies the user context under which the command should execute.

/P [password] Specifies the password for the given user context. Prompts for input if omitted.

/F Specifies to forcefully terminate process(es).

/FI filter Displays a set of tasks that match a
given criteria specified by the filter.

/PID process id Specifies the PID of the process that has to be terminated.

/IM image name Specifies the image name of the process that has to be terminated. Wildcard '*' can be used to specify all image names.

/T Tree kill: terminates the specified process and any child processes which were started by

/? Displays this help/usage.

Filters:
Filter Name Valid Operators Valid Value(s)
----------- --------------- --------------
STATUS eq, ne RUNNING | NOT RESPONDING
IMAGENAME eq, ne Image name
PID eq, ne, gt, lt, ge, le PID value
SESSION eq, ne, gt, lt, ge, le Session number.
CPUTIME eq, ne, gt, lt, ge, le CPU time in the format
of hh:mm:ss.
hh - hours,
mm - minutes, ss - seconds
MEMUSAGE eq, ne, gt, lt, ge, le Memory usage in KB
USERNAME eq, ne User name in [domain\]user
format
MODULES eq, ne DLL name
SERVICES eq, ne Service name
WINDOWTITLE eq, ne Window title

NOTE: Wildcard '*' for the /IM switch is accepted only with filters.

NOTE: Termination of remote processes will always be done forcefully
irrespective of whether /F option is specified or not.

Examples:
TASKKILL /S system /F /IM notepad.exe /T
TASKKILL /PID 1230 /PID 1241 /PID 1253 /T
TASKKILL /F /IM notepad.exe /IM mspaint.exe
TASKKILL /F /FI "PID ge 1000" /FI "WINDOWTITLE ne untitle*"
TASKKILL /F /FI "USERNAME eq NT AUTHORITY\SYSTEM" /IM notepad.exe
TASKKILL /S system /U domain\username /FI "USERNAME ne NT*" /IM *
TASKKILL /S system /U username /P password /FI "IMAGENAME eq note*"

Dan zou dit toch moeten lukken.

code:

TASKKILL.exe /U username /P password /F /IM osk.exe /T

[alt-92]

Maar dan geef je een Admin logon inclusief password weg.

Baaaad mental image.
Zet dan gewoon de voordeur wagenwijd open Geef me ook effe een belletje, kom ik de zooi wel ophalen, ok?

[ Voor 40% gewijzigd door alt-92 op 26-05-2009 19:23 ]

[mhoogendam]

alt-92 schreef op dinsdag 26 mei 2009 @ 19:22:
Maar dan geef je een Admin logon inclusief password weg.

Baaaad mental image.
Zet dan gewoon de voordeur wagenwijd open Geef me ook effe een belletje, kom ik de zooi wel ophalen, ok?

Daar zijn natuurlijk weer oplossingen voor te vinden, het commando in een .VBE script verwerken bijvoorbeeld.

[alt-92]

Nog beter: zorgen dat je dat voorkomt

Script Encoder is een eenvoudig obfuscating ding, geen industry grade tool en is heel makkelijk de decoderen.

[ Voor 58% gewijzigd door alt-92 op 27-05-2009 10:15 ]

[Arethusa]

Een taak aanmaken ging prima ook met de runas gebruiker NT AUTHORITY\SYSTEM. Alleen werd dan het proces niet gestopt. Dat werd alleen gestopt als ik de Administrator gebruiker nam. Daarnaast was er in het operator account geen taak bekend wanneer ik in de command paramters gebruikte van schtasks om te zien of er taken waren.

De optie die mhoogendam aandroeg vereiste naast een gebruikersnaam en wachtwoord ook een computernaam. Deze is verplicht. Ook dit werkte niet vanwege die Generic failure.

Ik heb nu binnen de group policy onder Run These Programs at logon een verwijzing gemaakt naar een batch bestand. In dat bestand heb ik staan:
C:\windows\system32\pskill -t osk.exe

Ook heb ik de gebruiker Operator aan de Administrators moeten toevoegen om pskill te laten werken. Je zou zeggen dat dit een grote beveiligingsfout is maar het image is zo ingericht dat de operator alsnog niets kan uitvoeren. Het is namelijk zo dat in het geval van het HP Image dat een andere gebruiker dan de Administrator in de Administrator niet de rechten krijgt.
Zie ook dit topic op het HP Forum. Het komt erop neer dat je user.dat moet overzetten naar het account van de gebruiker die je Administrator rechten wil geven. Pas dan heb je dezelfde opties als de Administrator.

Dit werkt prima voor zowel de Administrator als ook de Operator gebruiker. Wanneer ik middels het On Screen Keyboard op het touch panel op de thin client ingelogd ben wordt het osk proces gestopt. Daarna kan ik via een icoontje op het bureaublad osk.exe weer starten en zo is het toetsenbord weer zichtbaar.

[alt-92]

Is ook een optie inderdaad.

Arethusa schreef op woensdag 27 mei 2009 @ 11:01:
Een taak aanmaken ging prima ook met de runas gebruiker NT AUTHORITY\SYSTEM. Alleen werd dan het proces niet gestopt. Dat werd alleen gestopt als ik de Administrator gebruiker nam.

Roep je dan taskkill/PSkill rechtstreeks aan of met een script om het proces te beëindigen?
Ik heb het hier af en toe moeten inzetten voor bepaalde applicaties en het werkt namelijk wel (al zijn dat servers - het idee is hetzelfde).

Daarnaast was er in het operator account geen taak bekend wanneer ik in de command paramters gebruikte van schtasks om te zien of er taken waren.

Die account was/is een gelimiteerde account die dat ook niet kon zien toch?

[Arethusa]

alt-92 schreef op woensdag 27 mei 2009 @ 11:36:
Roep je dan taskkill/PSkill rechtstreeks aan of met een script om het proces te beëindigen?
Ik heb het hier af en toe moeten inzetten voor bepaalde applicaties en het werkt namelijk wel (al zijn dat servers - het idee is hetzelfde).

Je hebt pskill/taskkill werkend gekregen binnen een gelimiteerd account?
Ik heb zowel rechstreeks pskill aangeroepen maar ook via een batch file. In beide heb ik hetzelfde commando gebruikt om het proces te stoppen.

Die account was/is een gelimiteerde account die dat ook niet kon zien toch?

Dat is waar, even niet aan gedacht.

[ Voor 10% gewijzigd door Arethusa op 27-05-2009 13:22 . Reden: Mijn laatste vraag was offtopic ]

[alt-92]

Juist niet onder een limited user maar via een pollend script onder SYSTEM. De task zelf is dan overigens een (VB)script en niet enkel de losse commandline util.

Dat omdat je dan ook te maken hebt met complete paden die én door je batchscript én door de Runas user moet worden uitgelezen (en dat levert op onze systemen met strikte ACLs weer problemen op).

[ Voor 39% gewijzigd door alt-92 op 27-05-2009 13:48 ]