1

Context

We are using NSIS 3.05 with Unicode true (this is important later).

We need to check if a certain process is running, let's call it "processToFind.exe".

In order to do that, we have been using nsProcess Plugin, which is set up correctly, found and integrated just fine.

We include Plugins from our git repository like this:

!addincludedir "C:\pathToRepo\NSIS\Include"
!addplugindir "C:\pathToRepo\NSIS\Plugins"

where pathToRepo is of course a valid path. We also tried using the default Plugin Directories (NSIS-Dir\Plugins\x86-unicode) to no avail (see below).

Documentation says, nsProcess (v 1.6) does suppport unicode. That's why we chose to use it.

NSIS UNICODE support (just rename nsProcessW.dll into nsProcess.dll)

When setting Unicode false or leaving the setting out (so default is ansi), it is working fine, too. ( = running processes found, not running processes not found )

The Installer is 32 bit, we are running on 64 bit Windows 10 machines.

Code

${nsProcess::FindProcess} "procexp.exe" $R0
MessageBox MB_OK "procexp: [$R0]"

which is defined in nsProcess.nsh (provided by plugin, not own code)

!define nsProcess::FindProcess `!insertmacro nsProcess::FindProcess`

!macro nsProcess::FindProcess _FILE _ERR
nsProcess::_FindProcess /NOUNLOAD `${_FILE}`
Pop ${_ERR}
!macroend

Problem

When having set Unicode true , nsProcess will always return 603 ("Process was not currently running").

That's the same, regardless if we try to find 32-bit or 64-bit processes.

That would be expected for 64-bit processes (they cannot be found from 32-bit installers, which is ok for us).

But I do expect it to find 32-bit processes.

Alternatives already explored:

Going through the list found at Check whether your application is running ...

  • Processes Plugin : Seems outdated, only sourcecode found.

  • "FindProcess.nsh" : Naming collision, didn't work, neither. Same symptoms.

  • DDE Server / Win32 Sync / Registry: Not an option.

  • "tasklist" command: Same symptoms. When executed in cmd, it works but not from installer. nsExec::ExecToStack '"%SystemRoot%\System32\tasklist" /NH /FI "IMAGENAME eq ${processName}" | "%SystemRoot%\System32\find" /I "${processName}"' always returns "error". (* it's clear now why, see edit below)

  • "FindProcDLL" Plugin : skipped because

    As of NSIS 2.46 this plugin no longer works...

Seemingly related Stackoverflow Questions explored:

I am sure, we are making some "stupid" mistake since I cannot bring myself to believing we are the only ones with that requirement. So, any hints, suggestions and alternatives that are not listed above (or corrections to the above) are welcomed.

Edit

We totally messed up the tasklist call. As @Anders pointed out in comment: nsExec does not support pipes and on top of that, the syntax was also messed up.

Fildor
  • 14,510
  • 4
  • 35
  • 67
  • 1
    ExecToStack does not support `|`. You have to invoke `cmd.exe /C ...` – Anders Jan 15 '20 at 08:12
  • @Anders Excellent point! I have been suspecting something like that. Luckily, I can use nsProcess now instead. But that may be useful to others, thanks! – Fildor Jan 15 '20 at 08:13

2 Answers2

2

Does official example work for you? It works on my machine.

Try this:

0) Delete all nsProcess.dll files (in NSIS, in your include folders, everywhere)

1) Remove line !addplugindir "C:\pathToRepo\NSIS\Plugins" from your script to use plugins in NSIS directories

2) Copy file nsProcessW.dll into **c:\Program Files (x86)\NSIS\Plugins\x86-unicode**

3) Rename file c:\Program Files (x86)\NSIS\Plugins\x86-unicode\nsProcessW.dll -> nsProcess.dll

4) Compile your script with Unicode true

I believe there is some file mismatch. To understand NSIS plugins structure see NSIS - check if process exists (nsProcess not working) .

Slappy
  • 5,250
  • 1
  • 23
  • 29
  • So embarrassing. I deleted the dll, fetched a fresh download of the zip and copied the nsProcessW.dll, rename and Ta Ta! It worked. Somehow in the process, the dll must have been reset to the ansi version ... :( – Fildor Jan 15 '20 at 07:45
  • Of the possible causes, I didn't take _this_ into account ... shame on me, bwahhh. – Fildor Jan 15 '20 at 07:47
1

I'm still using ANSI because I'm using some other plugins that don't have a Unicode variant, so nsProcess works for me, and I'm not sure how to answer your main question.

However, re: the tasklist command alternative you listed, the syntax isn't quite right. You're missing a closing quote after "IMAGENAME eq ${processName}["] and an opening quote before ["]${processName}" in the pipe to find.exe.

Also FYI note that if you use %SystemRoot%\System32\, a 32-bit process will be redirected to C:\Windows\SysWOW64\, and some programs have no 32-bit equivalent (e.g., pnputil). In this case, it doesn't really matter, but in any event to get around this, you should use $WINDIR\SysNative instead. You can also use ${DisableX64FSRedirection} from x64.nsh, but there are apparently some potential pitfalls there.

EDIT: Ah yes, and there's the issue with pipe and ExecToStack mentioned by Anders in the comments to the original question, requiring the call to be prefixed with cmd.exe /C

Nutty
  • 81
  • 4
  • Thank you for your effort. Indeed, the syntax was messed. I didn't follow through, though, because we prefer nsProcess anyway. – Fildor Jan 15 '20 at 08:03