kalverson
12th September 2011 14:18 UTC

Error opening File for writing:
Hello,

I am having a strange issue with this error message from a customer. The customer is installing on many systems and only has trouble on three of the systems. There is one specific file (A windows service exe file) that can not be overwritten by the Nullsoft installer. I have checked all the usual things; i.e. - Install is running on an Administrative account. The file is writable and the Administrator account has write permissions. I can rename the file just fine. The service is stopped and not running. Yet, still the install issues the error. The odd thing is it is only for that one exe file. All other files get written if the customer clicks Ignore button. The other thing that is strange, is it is the same file three systems that he is having this issue with. The systems are VM's; could the issue be with the VM software? I am at a lose to figure this one out.

Anders
12th September 2011 14:29 UTC

Try running Process Monitor from Microsoft/Sysinternals and see what the error is...

kalverson
12th September 2011 18:26 UTC

Thank you for your timely suggestion. After downloading the tool and doing some experimentation, I think this will work to find out what is wrong at the customer site. I just need to come up with a procedure that the customer can use to get and return the information now.

Anders
12th September 2011 19:17 UTC

It has some kind of logging IIRC so they just record and you can view the log later (Check the docs for command line parameters and just give them a batch file to execute or something)

kalverson
14th September 2011 19:51 UTC

Our customer used link http://live.sysinternals.com to get and use procexp.exe instead. He did a Process Explore Search for Handle or DLL substrings using the path to our service exe. He did get a match. It was Microsoft program wmiprvse.exe that appears to have a lock. However, my lock detection was not detecting that lock. It also turns out that another person has run into a similar situation during an install and renaming the file was the work around. That also works here for our customer. I could try implementing the lockedlist.zip plugin again, but I am not 100% sure that would catch it either if the exe can be manually renamed. My alternate oninit.nsh check of renaming the product install folder behind the scenes is passing; i.e. the rename works so no locked files detected.

kalverson
16th September 2011 15:44 UTC

Our customer was able to remove the lock on our file by stopping 5 services; the last one was Window Management Instrumentation. There was third party update software involve that was causing the issue. The customer is happy with the solution his windows network administrator provided to remove the lock. Also, thanks to Anders for suggesting the sysinternals tools. The customer also really liked the tool and thinks it will be handy going forward.

MSG
16th September 2011 18:22 UTC

Stopping services just because they're hogging a file... I wouldn't be happy if an uninstaller did that on my system! I strongly recommend reconsidering such a nazi apporach.

kalverson
21st September 2011 15:43 UTC

I think you misunderstood, the customer was trying to update our software not uninstall our software. We do not stop any services that are not ours in our install or uninstall process.