• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 827
  • Last Modified:

Wise Installation 9: Problem Killing Processes

In their infinate wisdom, M$ has deemed that some processes are only allowed to be killed by users if
they were not started by the SYSTEM account.

We have several processes that may be started by SQLSERVERAGENT service and they are started
using the SYSTEM account and we need to kill them in order to install new versions. Let me say that
we have tried the Replace In-Use Files option and it doesn't work because we also want rollback
capabilities; we attempt to rename the directory that these utilites are in so we may rollback in case
of errors.

Now, the rename isn't happening because of the in-use file(s) and we need to kill these processes if
they are running but none of the Kill Process scripts from the script library work. I have stepped
throught them and found that the error returned when trying to open the process to get the
process handle is "Access denied".

BTW, I am able to kill it using Task Manager because TM runs in the SYSTEM account.

Any thoughts on a solution or how to impersonate the SYSTEM account to kill these processes?
Eddie Shipman
Eddie Shipman
  • 5
  • 4
1 Solution
Hi EddieShipman,

pskill from http://www.sysinternals.com/
Or, if you need more flexibility, psexec from the same location.

Eddie ShipmanAll-around developerAuthor Commented:
Already tried that, does not work.
Seems I have to AdjustTokenPrivileges and enable the SeDebugPrivilege
in order to do this. Know how to do that in Wise script?
If Task Manager is capable of killing the process, then psexec -s pskill process should also be capable of doing so, as the -s option of psexec causes it to run with system privileges.  Are you receiving an error message?  If so, could you post it here?

If accomplishing this from within WISE is the ultimate goal, you might benefit from posting a pointer to this question in the Applications forum.  And maybe the appropriate Windows OS forum as well.
What Kind of Coding Program is Right for You?

There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.

Eddie ShipmanAll-around developerAuthor Commented:
psexec -s pskill myprocessname won't run at all.
Both psexec and pskill are loaded into memory but it ain't running.

I don't think pskill is "accepting" the commandline option there.

If you can show me how to make it work, that would be great...
Eddie ShipmanAll-around developerAuthor Commented:
If I try to run it here is the ouptput:

C:\>psexec -s c:\pskill.exe EditPad.exe

PsExec v1.72 - Execute processes remotely
Copyright (C) 2001-2006 Mark Russinovich
Sysinternals - www.sysinternals.com

PsKill v1.11 - Terminates processes on local or remote systems
Copyright (C) 1999-2005  Mark Russinovich
Sysinternals - www.sysinternals.com

and it just hangs...I have to kill both processes in TM.
OH, BTW, you must supply the path to pskill, too.
I see what you mean...  Having to supply the path is a known issue -- apparently the search path as defined in the PATH environment variable isn't checked by psexec when running as system.  However, I find it bizarre that pskill doesn't run correctly under psexec -s ...  I tried psexec -s cmd.exe, and it started the command prompt just fine in interactive mode.  However, pskill won't run correctly like that, either.  It just hangs, as you described.  I traced the progress of the file in ProcMon, and there's nothing to indicate that it did anything illegal...  It just seems to stop executing.

I suppose the alternative is to write a program that will generate a security token with the appropriate privileges and terminate the process...  I'll look into it and see if it can be done easily.  Hopefully I'll have some code to post for you tomorrow.
Eddie ShipmanAll-around developerAuthor Commented:
No need, I have Delphi code to do that already. I just need to get the
authorization to include this in our installs. It seems that mgmnt doesn't
want to include things like this because we formerly had an "InstallHelper"
DLL that did a lot of work that we now do in the Wise script and they
wanted all that type of stuff (extra files) removed.

My thought is that there were some other things that tooks us weeks to
figure out, in Wise, that we could have done in a few minutes with another
programming language, like Delphi (our main dev environment), yet we
have not been able to use this. We know we can also do this in Wise, but
don't know how to do the API calls in wise script.

The new version of Wise, which is still in beta, allows you to use VBS to do
a lot of things and that would help a lot but we are not going to build our
installs with a beta product, either.

Ah, now I understand your problem a bit better.  In that case, I'm afraid I can't help.  )c:
Eddie ShipmanAll-around developerAuthor Commented:
We have written a DLL that will kill the processes in question.

Thanks for helping.
PAQd, 500 points refunded.

CS Moderator
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now