nsProcess plugin

[Instructor]

Features:
- Find/kill a process by name
- Kill all processes with specified name (not only one)
- The process name is case-insensitive
- Win95/98/ME/NT/2000/XP support
- Small plugin size (4,5 Kb)

Source function FIND_PROC_BY_NAME based upon the Ravi Kochhar code
Thanks iceman_k (FindProcDLL plugin) and
DITMan (KillProcDLL plugin) for direct me


"nsProcess" plugin v1.0

[JasonFriday13]

You just keep churning out the plugins. Good one.

[Comm@nder21]

you just rock, man.
this will revolutionize my installers

maybe i should collect all the good plugins into a package on day, so everyone may download and setup them easily ...

[Instructor]

Thanks

[onad]

Good to see "Win95/98/ME" support, thanks man!

[deguix]

you just rock, man.
this will revolutionize my installers

maybe i should collect all the good plugins into a package on day, so everyone may download and setup them easily ...

Another good idea would be making function standards and to include those in a global header for easier and pratical use.

[Comm@nder21]

... and include this header file together with the plugins into the package ...

[Instructor]

Fixed: removed CRT dependency (Windows 95 by default does not have msvcrt.dll)


"nsProcess" plugin v1.1

[Instructor]

Changed: Now plugin used header "nsProcess.nsh" for custom user variables and
              better compile errors check.

Update from previous versions:
         - Insert line in script:
            !include "nsProcess.nsh"
         - Replace:
            nsProcess::FindProcess -> ${nsProcess::FindProcess} ...
         - Replace:
            .r0 -> $0, .r1 -> $1 ... .R0 -> $R0, .R1 -> $R1 ...

"nsProcess" plugin v1.2

[{_trueparuex^}]

What is the benefit of using PSAPI for WinNT/2000/XP? Shouldn't the Win95/98/ME method work just as fine in this case?

Edit: Never mind. It's the Toolhelp32.dll what Windows NT does not have.

[{_trueparuex^}]

Hmm in Win95/98/ME method the hSnapShot HANDLE leaves open if the process was found and bTerminate is FALSE.

[Instructor]

Hmm in Win95/98/ME method the hSnapShot HANDLE leaves open if the process was found and bTerminate is FALSE.

You are right, fixed.

[Instructor]

Fixed: removed memory leak.


"nsProcess" plugin v1.3

[rxs2k5]

hmm I do not understand, can this plugin kill current open notepad ???

Is this able to find notepad that is currently running and kill it immediately ???

[{_trueparuex^}]

Originally posted by rxs2k5
hmm I do not understand, can this plugin kill current open notepad ???

Is this able to find notepad that is currently running and kill it immediately ???

Yes and yes.

[rxs2k5]

How do I create the following thing
1. remove the loop
2. find the processes to find notepad , wordpad means in mutiple form and single finding
3. kill all the following process after finding it existence

Section /o "Kill process" KillProcess
loop:
${nsProcess::FindProcess} "NoTePad.exe" $R0
StrCmp $R0 0 0 +2
MessageBox MB_OKCANCEL|MB_ICONEXCLAMATION 'Close "notepad" before continue' IDOK loop IDCANCEL end

${nsProcess::KillProcess} "NoTePad.exe" $R0
MessageBox MB_OK "nsProcess::KillProcess$\n$\n\
Errorlevel: [$R0]"
Exec "notepad.exe"
Exec "notepad.exe"
Exec "notepad.exe"
BringToFront
MessageBox MB_OK "Press OK and 3 notepad's windows will be closed"

${nsProcess::KillProcess} "NoTePad.exe" $R0
MessageBox MB_OK "nsProcess::KillProcess$\n$\n\
Errorlevel: [$R0]"

end:
${nsProcess::Unload}
SectionEnd

[oleksa]

I'd downloaded this plugin and had tested it. Test install script always returns Error level 603. If I run script single or with calc.exe

Help me please! What does this error mean? Where I can find error code list?

Thank you.
I have Windows XP prof x64.

[Instructor]

Help me please! What does this error mean? Where I can find error code list?

In the Readme.txt Unfortunatelly I can't test it on WinXP x64.

[oleksa]

I've found that EnumProcessModules fails when is called for 64 bit applications (calc.exe is 64-bit application) on 64 bit OS with error

299
ERROR_PARTIAL_COPY
Only part of a ReadProcessMemory or WriteProcessMemory request was completed.

I will try to find solution for this problem.

[oleksa]

Hello Instructor.
It's me again.

Have you tried CreateToolhelp32Snapshot, Process32First, Process32Next functions on NT platforms? It works fine at my comp (I'm administrator). This functions are located in kernel32.dll as MSDN says - no psapi is required and should work on Win95/98, WinNT, Win2000 and Windows XP.

Why OpenProcess and EnumProcessModules are used for NT like OS now (Windows 2000, XP, 2003)? Only for Windows NT 4.0 support?

[{_trueparuex^}]

@oleksa
Could you try this. I removed the PSAPI and OS check and now it's using only the "Win95/98" method.

[oleksa]

Hello {_trueparuex^}

Yes - that sample code (based on CreateToolhelp32Snapshot, Process32First, Process32Next functions) works fine on my comp. To save Windows NT 4.0 compatibility I suggest rewrite OS check from

code:
if (osvi.dwPlatformId == VER_PLATFORM_WIN32_NT)

to

code:
if (osvi.dwPlatformId == VER_PLATFORM_WIN32_NT && osvi.dwMajorVersion <= 4)

This check should be true only on Windows NT (as MSDN says). So on NT will work code that gets processes name with PSAPI.
Windows 95, 98, Me, 2000, 2003 and XP should support Tool help functions.

[{_trueparuex^}]

Good. I have my own NSIS unrelated stuff based on the same code... But there is one major disadvantage in CreateToolhelp32Snapshot method. It doesn't work with file names longer than 15 characters. So trying to kill process with name like this "ThisIsPrettyLongName.exe" won't work. One solution would be simply to limit the file names to 15 characters, but that could cause kill of unintentional processes.

So let's see what Instructor gets up to with.

[Instructor]

oleksa can you test it on the x64

Fixed: WinNT 4.0 by default doesn't have PSAPI.DLL. Code for WinNT/2000/XP has
          been rewritten (using NTDLL.DLL). Note: on WinNT 4.0 process name limited
          to 15 characters.
Changed: error codes.


"nsProcess" plugin v1.4

[oleksa]

Instructor works fine, thank you.
looks for calc.exe (603 if process hasn't been started and 0 if process has been started)
checks does notepad.exe running and closes all three notepads succesfully.

Thank you.

[oleksa]

But there is one major disadvantage in CreateToolhelp32Snapshot method. It doesn't work with file names longer than 15 characters. So trying to kill process with name like this "ThisIsPrettyLongName.exe" won't work.

2 {_trueparuex^}
How could wou know that CreateToolhelp32Snapshot method won't work?

I have test it and all works fine:

code:
PROCESS NAME:  AcroRd32.exe

PROCESS NAME:  devenv.exe

PROCESS NAME:  mspdbsrv.exe

PROCESS NAME:  ThisIsPrettyLongName.exe

I could post test code (from MSDN) here or send you e-mail as you wish.

Good bye.

[{_trueparuex^}]

Originally posted by oleksa
2 {_trueparuex^}
How could wou know that CreateToolhelp32Snapshot method won't work?

I have test it and all works fine:

code:
PROCESS NAME:  AcroRd32.exe

PROCESS NAME:  devenv.exe

PROCESS NAME:  mspdbsrv.exe

PROCESS NAME:  ThisIsPrettyLongName.exe

I could post test code (from MSDN) here or send you e-mail as you wish.

Good bye.

I wasn't aware of this before, but that 15 characters name limitation is only in win2k or older.


@Instructor
That 15 characters name limitation is also in Windows 2000 when using NTDLL.DLL PSAPI didn't have that limitation.

[dienjd]

Instructor,
There is a spyware app with a DLL that has the same name as this plug-in:
http://www3.ca.com/securityadvisor/p...x?id=453097507

This is too bad...I don't know of a way around having your plug-in associated with adware other than renaming it.

Those of you who are already using it may want to rename it to avoid having your installer raise anti-virus/spy flags when running.

[Instructor]

Fixed: removed memory leak in WinNT/2000/XP method.


"nsProcess" plugin v1.5

[CharlesB2]

Originally posted by Instructor
Fixed: removed memory leak in WinNT/2000/XP method.


"nsProcess" plugin v1.5

Hey,

Since recent update of McAfee VirusScan, the use of a previous nsProcess version was detected as a Trojan (generic prockill.a)!! The last version (1.5) does not cause the problem. Thanks a lot!

Cheers

[jpodtbc]

problem trying to kill a service process. i can find the process but when i try to kill it i get return code 601 (no permission to kill process). i am running the installer as an administrator and can kill the process manually.

please help.

[{_trueparuex^}]

Killing service like that is really not very smart. Rather try to stop it with some of these methods.
http://nsis.sourceforge.net/How_do_I...heck_a_service

[jpodtbc]

thanks but i already have service control implemented in the installer. the problem is when the service is unresponsive and cannot be shut down any other way. i think we can all agree that it is bad to have the installer hang indefinitely.

[jpodtbc]

i found a solution by modifying the nsProcess source code and using code provided here:
http://www.alexfedotov.com/articles/killproc.asp?pane=0

[hbatista]

Hi jpodtbc, I'm having the exact same problem as you.
Could you be so kind to post your solution here?
Thanks a lot

[hbatista]

I ended up changing it myself. Here is the source code and dll if someone wants to use it.

[jpodtbc]

thanks man...i was about to put up my modified source but you beat me to it.

[hbatista]

No problem, I was facing a really tight deadline so I had to go for it.

[Whizz]

Originally posted by CharlesB2
Hey,

Since recent update of McAfee VirusScan, the use of a previous nsProcess version was detected as a Trojan (generic prockill.a)!! The last version (1.5) does not cause the problem. Thanks a lot!

Cheers

This is still happening, even with 1.5 of nsProcess. It is being detected as HackTool.ProcKill.A by several AV packages.

Is there any chance of a major change with this DLL to prevent this detection? The DLL itself is really useful, but it looks like someone has used it for less than honest purposes .

I have had to take it out of several of my installers for until this can be fixed.

[CharlesB2]

Originally posted by Whizz
This is still happening, even with 1.5 of nsProcess. It is being detected as HackTool.ProcKill.A by several AV packages.

Is there any chance of a major change with this DLL to prevent this detection? The DLL itself is really useful, but it looks like someone has used it for less than honest purposes .

The best way to handle the problem is to recompile the DLL by removing the function that kills a process, since I believe it is the one that is used by trojans. I have done it myself, if you're interested I can put it on the wiki...

Cheers