cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
honlory
Level 3

Detect and Kill a process

Hello guys,

I met a problem when using IS2008.
If I want to detect if there is a process (such as excel.exe) running, if yes, I need to kill it. (remind, not all the process can have a HWND).
How can I do it? Are there as IS frame function can help me ?

Many Thanks & Kind Regards,
Honlory
Labels (1)
0 Kudos
(11) Replies
Johannes_T
Level 6

Hi Honlory,
I usually check if a process is running with is(FILE_LOCKED, file) and if true, i start taskkill (*) from system32 with LaunchAppAndWait. This can kill nearly everything 😉

Greetings,
Johannes

*) taskkill /IM processName /F
0 Kudos
Kelter
Level 10

Another plug for installsite.org!

http://www.installsite.org/pages/en/isp_ext.htm

Look for "List and Shut Down Running Applications" near the bottom. The scripts in the zip files are pretty easy to interpolate for your own purposes.
0 Kudos
NCK816
Level 3

Hi guys,

Does anyone use the code in Installsite?

I use that code in my project to detect process and kill that, and it works well on 32-bit OS.

But it seems often fail on 64-bit OS. (Sometims will work.)

Does anybody suffer this issue, too? How to solve this problem?

Thanks.
0 Kudos
Kelter
Level 10

the code in there is trying to open the 32 bit version of psapi.dll. you know this because the call to UseDll is looking for the file in
WINSYSDIR ^ PSAPI_FILE

in other words:
C:\Windows\System32

What you need to do in your 64 bit build is to look in WINSYSDIR64 instead of WINSYSDIR, so it'll find the version of psapi.dll in
C:\WindowsSysWOW64


Note: If this is a pure InstallScript project type, or an InstallScript MSI type project, you'll definitely want to look at the help topics related to WOW64FSREDIRECTION.
0 Kudos
NCK816
Level 3

Hi Kelter,

Thanks for your reply.

After modifing according to your suggestion, I encounter another porblem.

If I disable WOW64FSREDIRECTION, then loading psapi.dll on 64-bit OS will fail.

Privilege of my installer is admin, so it should not about access rights.

Folllowing is my code in ProcessRunning function :

if(SYSINFO.bIsWow64) then
szDLL = WINSYSDIR64 ^ PSAPI_FILE;;
else
szDLL = WINSYSDIR ^ PSAPI_FILE;
endif;

Disable(WOW64FSREDIRECTION);
if UseDLL(szDLL) < 0 then
// Could not load psapi.dll.
MessageBox("ERROR: Could not load [" + WINSYSDIR ^ PSAPI_FILE + "].", SEVERE);
return FALSE;
endif;

P.S. My project type is Basic MSI
0 Kudos
Kelter
Level 10

Is the CA scheduled to run as "Deferred execution in system context"?

Also, try this so that you can see what error is being thrown.

[CODE]Disable(WOW64FSREDIRECTION);
if UseDLL(szDLL) < 0 then
// Could not load psapi.dll.
nError = Err.LastDllError;
sError = FormatMessage(nError);
SprintfBox(SEVERE,"Error", "Error: %d\n"" %s",sError, nError );
MessageBox("ERROR: Could not load [" + WINSYSDIR ^ PSAPI_FILE + "].", SEVERE);
return FALSE;

endif;[/CODE]
0 Kudos
NCK816
Level 3

Kelter wrote:
Is the CA scheduled to run as "Deferred execution in system context"?
<-- I don't know what does this exactally mean?

Cause originally code may have wrong
I add the code :
SprintfBox(SEVERE,"Error", "Error: %d\n %s",nError, sError);

And it show message about "Error : 193 %1 Not a valid win32 application."

Is it because my installer is a win32 apps and it want to access psapi.dll which it is for 64-bit OS, so I can not load it?

P.S. My project is build under XP 32-bit
0 Kudos
Kelter
Level 10

Judging from your error code, i'd say that you're probably right about the 64bit thing. The help topic "64 Bit Custom Actions" states:
On 64-bit operating systems, Windows Installer version 2.0 may call custom actions that have been compiled for 32-bit or 64-bit systems.

A 64-bit custom action based on Scripts must be explicitly marked as a 64-bit custom action by adding the msidbCustomActionType64BitScript bit to the custom actions numeric type in the Type column of the CustomAction table.


As for the "deferred execution in system context" thing, even if your installation is running with admin privs, your CAs are not run with admin privs, unless the "In-Script Execution" field of yoru custom action's properties (in the Custom Actions view) is set to "deferred execution in system context" or "Rollback execution in system context", or "commit execution in system context". This implies that teh CA must be scheduled between InstalInitialize and InstallFinalize, and that it will run after all the Immediate Execution actions, and that the script will have limited access to the properties table and will have to use the CustomActionData to read in any properties set during the installation.

This page provides a great description of the installation sequences.
http://www.installsite.org/pages/en/isnews/200108/index.htm

There's a ton of info on the CustomActionData thing as well, but let me know if you need a description of it (if your MsiGetProperty calls are returning blanks in a Deferred Execution CA, and they shouldn't be, then you need to use CustomActionData.)
0 Kudos
NCK816
Level 3

Dear Kelter,

Thanks for info you provided, I don't know these details before.

All my CAs exectue as immediate executions, I think I should adjust some of them to deferred execution and add corresponding rollback actions. (Rollback action may not create automatically?)

BTW, orginal problem about detecting process function can not run on 64-bit OS, I think it's becase it doesn't mark as a 64-bit CA.
So I should add another CA for 64-bit OS extra and set it as "commit execution in system context".

About "CustomActionData" topic, I will find some data to study it.

I really appreciate your helps.
0 Kudos
Kelter
Level 10

So here's how this stuff works:

Motivation:
Scripted custom actions execute just like dll custom actions. This is why access to the property table is mostly restricted during deferred execution CAs, and why Immediate Executions CAs (which aren't supposed to modify the user's system) don't execute with admin privileges.

Problem:
How does someone pass property values to a Deferred Execution CA?

Solution:
Every CA has access to a property called CustomActionData. The funny thing is that you don't actually set the value of [CustomActionData]; instead, you set the value of a property with the same name as the custom action from which you wanted to access the value.

In other words, if you have a custom action called "InstallScriptCA1" that runs as a deferred execution CA, then before that CA runs, you need to schedule a Set-A-Property custom action that has its "Target" field set to "InstallScriptCA1", and the "Source" field set to the value that you want passed to InstallScriptCA1. From within your script, call "MsiGetProperty" to retrieve the value of "CustomActionData", and the value returned will be whatever was assigned as the value of InstallScriptCA1.

So how about passing in lots of properties? I use a semicolon-delimited list of key=value pairs. ( in other words, "key1=value1;key2=value2;..." ) I've written some logic to handle parsing data in this format. PM me if you want it.
0 Kudos
Kelter
Level 10

did you find a solution that enabled you to load those DLLs?

I was thinking about the 64bit script property, but in the custom actions view, the option is grayed out!
0 Kudos