peterboulton
20th June 2007 22:33 UTC

NSIS hangs with Group Policy?
Hi,

I've attached my full installer script to this posting so you can see all the gory details! (I'm a bit new to NSIS!)

Basically what's happening is it works beautifully on all my test machines, which are not part of a domain, but I have a customer who has just implemented a Group Policy on their network and the installer hangs as it's trying (I think) to initially stop my service app (if it exists) in System32:

nsExec::Exec '"$SYSDIR\WebUpdateSvc4.exe" -e'

Any ideas? It seems to definitely be an NSIS issue as I made a 'quick and dirty' installer with Inno Setup, doing all the similar things like installing and starting the service and it works for the customer (but is nearly twice the file size!).

I'd really, really like to understand how to make NSIS work correctly in all group policy implementations if that's possible.

TIA,

Pete

peterboulton
21st June 2007 20:29 UTC

My question must be so boring or impenetrable that no one has posted an answer! I still don't understand why my installer hangs, but at least I no longer have the indignity of being the only post on page 1 with zero responses!

Afrow UK
21st June 2007 20:45 UTC

You have to understand that 99% of the users here are in the same position as you and the remaining 1% help on a voluntary basis. You'll have to wait for somebody who has a group policy set to reproduce the problem, or someone with greater expertise than myself in that area.

Stu

peterboulton
21st June 2007 20:50 UTC

Stu, I 100% accept your point and apologise for my impatience!

On the other hand, 99% of us thrashing around and 1% knowing the answers is not exactly encouraging! :-))

Pete

Afrow UK
21st June 2007 20:58 UTC

Currently there are at most 4 of us answering problems at any one time and between us we usually get problems fixed. I recommend sending a message to kichik (the lead developer) or visiting the NSIS IRC channel assuming you have a client such as mIRC, which kichik idles in usually.

Stu

peterboulton
21st June 2007 21:05 UTC

Thanks Stu. I have no right to ask for special treatment, so I will wait. Your comment was perfectly fair - my comment was an attempt at gentle humour, plus a (pathetic) attempt to stimulate interest in my little problem!

I do realise and appreciate that experts are giving their time for free here.

Cheers,

Pete

Anders
21st June 2007 23:40 UTC

try the normal nsis ExecWait instead of nsExec::Exec, if WebUpdateSvc4 is a console application, it will popup a window, but atleast you can narrow it down to a problem with the nsExec plugin if ExecWait works ok

peterboulton
22nd June 2007 17:24 UTC

Anders,

WebUpdateSvc4.exe is a service application and I am using the nsExec plugin to install and start it. The user is running as Administrator when the installer hangs.

Your suggestion to use ExecWait was very helpful and it appears that the installer will work when nsExec is substituted by ExecWait, based on some initial tests with 'dummy' installers on the user's machine.

Conclusion: the problem appears to be nsExec::Exec. My guess is the Group Policy does not like nsExec.dll in the user's 'C:\DOCUME~1\<username>\LOCALS~1\Temp\nsh2F6.tmp' folder launching processes on service applications.

Is this a known issue? Using the installer's built in function appears to resolve it (i.e. no nsExec plug-in), but at the expense of the unsightly command window popping up for each call.

Pete

Afrow UK
22nd June 2007 17:29 UTC

Shouldn't you start it using one of these?
http://nsis.sourceforge.net/How_do_I...heck_a_service

Stu

peterboulton
22nd June 2007 17:40 UTC

Thanks for the link Afrow. Possibly you are right, but my service responds to command line arguments:

WebUpdateSvc4.exe -i <installs the service into services.msc

WebUpdateSvc4.exe -s <starts the service

WebUpdateSvc4.exe -e <stops the service

WebUpdateSvc4.exe -u <uninstalls the service from services.msc

I have a feeling that getting into more plugins will be more complex, and as the 'problem' started with a plug-in....

So really my need comes down now to launching the commands I've listed here from NSIS without the command windows appearing. ExecShell won't do as I need to issue the install and start service commands asynchronously - i.e. one after the other. Maybe a batch file launched from ExecShell is the answer?

Pete

Afrow UK
22nd June 2007 18:32 UTC

You could try the ExecDos plugin as an alternative.
If that does not work, then it may be a problem being caused by not using COMSPEC (command prompt), in which case you can try:

ReadEnvStr $R0 COMSPEC
nsExec::Exec '"$R0" /C "$SYSDIR\WebUpdateSvc4.exe" -x'

Once upon a time somebody found that parts of the net command only worked this way.

Stu

peterboulton
22nd June 2007 18:45 UTC

Thanks Afrow - I'll check out ExecDos.

It's odd, though, that the installer WITH nsExec actually works perfectly in every installation instance (thousands, to the best of my knowledge) for my customers, except in these rare cases where new Group Policies have been set up.

Pete

P.S. I say 'thousands' - not totally sure on the exact number as my software is a bundled component in many other companies' software. I don't want to advertise so I will only post the url if you want me to. :-)

kichik
24th June 2007 22:06 UTC

Can you attach WebUpdateSvc4.exe and some more details on exactly which group policy is changed? The only thing I can think that'd get it to hang is something it waits for on STDIN. But that works with any other program... Try the attached nsExec.dll, it handles stdin a bit differently.

peterboulton
25th June 2007 14:15 UTC

Hi kichik,

Thanks for your kind offer and also for the revised nsexec.zip.

I've uploaded WebUpdateSvc4.exe - you can get it on the following url:

http://www.dataper.demon.co.uk/wuw/WebUpdateSvc41.zip

Unfortunately I am in UK and my customer who is having the problem with Group Policy is in the States. I don't know of a way to capture the Group Policy to a file in order to identify which one is to blame - if there is a way I'll happily ask the customer.

I've now more or less worked around the problem by:

1) I enhanced WebUpdateSvc4.exe so that it can install and start itself as a windows service with a single call -i.e. command line = 'WebUpateSvc4.exe -I'. (Previously installing and starting required 2 calls.)
2) I can then use the built-in ExecShell function in NSIS to install and start the WebUpdateSvc4.exe service with a single (asynchronous) call.
3) Same approach applied to uninstaller.

When updating to a new version there is a slight issue in that ideally I'd be able to tell the service to stop, update it and restart it from NSIS, but as I'm limited to asynchronous operation (because I don't want any command windows popping up and I cannot use plug-ins) I have to use a Sleep to wait for the service to stop itself after ExecShell-ing the stop command. But at worst it means we need a reboot.

Unless this is an NSIS issue which is of interest to others I'm more or less happy to sign off here, as it looks like I have a working solution.

Thanks indeed for the replies - appreciated!

Pete

Afrow UK
25th June 2007 15:38 UTC

ExecShell is for opening non executables. You shouldn't use that. Use Exec or ExecWait.

Stu

peterboulton
25th June 2007 17:15 UTC

Afrow, the NSIS help file suggests ExecShell is in fact a wrapper for the Windows api function ShellExecute, which can be used to launch executables or to launch documents based on their file associations. ("Execute the specified program using ShellExecute").

Moreover, Exec and ExecWait both launch command prompts when they execute my commands to WebUpdateSvc4.exe, which I cannot live with.

ExecShell is the only option for me which can be made to run invisibly and which is not dependent on the nsExec or other plug-ins, which appear to be what's causing the problem for my customer. ExecShell does work in the way I've described, too, despite your assertion to the (implied) contrary, which I don't fully understand.

Personally, I am surprised that NSIS doesn't already have, built in, the option to run Exec and ExecWait with the SW_HIDE option i.e. without the need for plug-ins.

But I do appreciate your time and comments in this thread - unless further discussion helps you and the NSIS developers improve the product I'm very happy to call this thread a day, with thanks!

Pete

Afrow UK
25th June 2007 17:25 UTC

If it works then it should be fine I guess, but as you probably know ExecShell is used for opening general files that have had executables associated with them through the registry.

Stu

peterboulton
25th June 2007 17:34 UTC

Afrow, if ExecShell is a wrapper for the Windows API ShellExecute then it can be used for launching executables or documents via their file extension.

http://msdn2.microsoft.com/en-us/library/ms647732.aspx

To quote: "lpParameters
[in] If lpFile specifies an executable file, this parameter is a pointer to a null-terminated string that specifies the parameters to be passed to the application."

HTH.

Pete

Afrow UK
25th June 2007 17:51 UTC

Sorry, I meant in the context of NSIS. Hence why we have Exec and ExecWait. Like I said, if it works (the second parameter for ExecShell is probably the same as lpFile) then it's fine.

Stu