This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Detect and Kill a process
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 29, 2009
01:17 AM
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
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
(11) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 29, 2009
05:13 AM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 29, 2009
10:28 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 25, 2010
01:59 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 25, 2010
08:11 AM
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
in other words:
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
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 27, 2010
03:39 AM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 27, 2010
08:57 AM
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
endif;[/CODE]
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;
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]
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 28, 2010
06:34 AM
Kelter wrote:<-- I don't know what does this exactally mean?
Is the CA scheduled to run as "Deferred execution in system context"?
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 28, 2010
08:47 AM
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:
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.)
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.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 29, 2010
06:25 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 02, 2010
08:12 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 05, 2011
02:53 PM
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!
I was thinking about the 64bit script property, but in the custom actions view, the option is grayed out!
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)