[GH-ISSUE #91] Upgrade is failing #90

Closed
opened 2026-02-25 21:32:37 +03:00 by kerem · 17 comments
Owner

Originally created by @teknowledgist on GitHub (Sep 11, 2019).
Original GitHub issue: https://github.com/clechasseur/pathcopycopy/issues/91

Originally assigned to: @clechasseur on GitHub.

Hi. The installer is failing (at least sometimes) on upgrade attempts. It kills explorer as it is supposed to and then hangs for a bit. In a manual upgrade, it gives an error about needing to stop the processes using PathCopyCopy (although I don't know what those would be if Explorer is down). In silent mode, it just returns an exit code of '5'.

My testing machine is down at the moment, but this occurred on my personal machine and at least one other.

Is there any way to upgrade without uninstalling and rebooting first?

Thanks

Originally created by @teknowledgist on GitHub (Sep 11, 2019). Original GitHub issue: https://github.com/clechasseur/pathcopycopy/issues/91 Originally assigned to: @clechasseur on GitHub. Hi. The installer is failing (at least sometimes) on upgrade attempts. It kills explorer as it is supposed to and then hangs for a bit. In a manual upgrade, it gives an error about needing to stop the processes using PathCopyCopy (although I don't know what those would be if Explorer is down). In silent mode, it just returns an exit code of '5'. My testing machine is down at the moment, but this occurred on my personal machine and at least one other. Is there any way to upgrade without uninstalling and rebooting first? Thanks
kerem 2026-02-25 21:32:37 +03:00
  • closed this issue
  • added the
    fixed
    bug
    labels
Author
Owner

@clechasseur commented on GitHub (Sep 11, 2019):

I've had problems in the past asking the installer to shut down Explorer… Did you try upgrading but without shutting down Explorer via the installer? You'll have to reboot at the end, but it might work better...

<!-- gh-comment-id:530211780 --> @clechasseur commented on GitHub (Sep 11, 2019): I've had problems in the past asking the installer to shut down Explorer… Did you try upgrading but without shutting down Explorer via the installer? You'll have to reboot at the end, but it might work better...
Author
Owner

@clechasseur commented on GitHub (Sep 11, 2019):

(For a silent install, you can instruct the installer not to shut down applications by passing /NOCLOSEAPPLICATIONS.)

<!-- gh-comment-id:530212611 --> @clechasseur commented on GitHub (Sep 11, 2019): (For a silent install, you can instruct the installer not to shut down applications by passing `/NOCLOSEAPPLICATIONS`.)
Author
Owner

@blackcrack commented on GitHub (Sep 11, 2019):

something named "Unattended Install switches"

for wiki:

Unattended Install switches

if you need switches for Unattended Install this nice Program, try it with these :
PathCopyCopyXX.X.X.exe /VERYSILENT /CLOSEAPPLICATIONS /NORESTART
At example by WinNT fresh install ..

and if you want create a silence install script on running User Session :
PathCopyCopyXX.X.X.exe /VERYSILENT /NOCLOSEAPPLICATIONS /NORESTART

This is a Inno Setup Installer, more about can you read here :

Inno Setup Command Line Parameters



copy n'past:

<h2>Unattended Install switches</h2>
if you need switches for Unattended Install this nice Program, try it with these : 
</br>
<b>PathCopyCopyXX.X.X.exe /VERYSILENT /CLOSEAPPLICATIONS /NORESTART</b></br>
At Example by WinNT fresh install
</br></br>
and if you want create a silence install script on running User Session : <br/> <b>PathCopyCopyXX.X.X.exe /VERYSILENT /NOCLOSEAPPLICATIONS /NORESTART </b>
<br/><br/>
This is a Inno Setup Installer, more about can you read here : <br/> 
[Inno Setup Command Line Parameters](http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline)
<br>
<br>

best
Blacky

<!-- gh-comment-id:530332911 --> @blackcrack commented on GitHub (Sep 11, 2019): something named "Unattended Install switches" for wiki: ><h2>Unattended Install switches</h2> >if you need switches for Unattended Install this nice Program, try it with these : ></br> ><b>PathCopyCopyXX.X.X.exe /VERYSILENT /CLOSEAPPLICATIONS /NORESTART</b></br> >At example by WinNT fresh install .. ></br></br> >and if you want create a silence install script on running User Session : <br/> <b>PathCopyCopyXX.X.X.exe /VERYSILENT /NOCLOSEAPPLICATIONS /NORESTART </b> ><br/><br/> >This is a Inno Setup Installer, more about can you read here : <br/> [Inno Setup Command Line Parameters](http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline) ><br> ><br> __copy n'past:__ ``` <h2>Unattended Install switches</h2> if you need switches for Unattended Install this nice Program, try it with these : </br> <b>PathCopyCopyXX.X.X.exe /VERYSILENT /CLOSEAPPLICATIONS /NORESTART</b></br> At Example by WinNT fresh install </br></br> and if you want create a silence install script on running User Session : <br/> <b>PathCopyCopyXX.X.X.exe /VERYSILENT /NOCLOSEAPPLICATIONS /NORESTART </b> <br/><br/> This is a Inno Setup Installer, more about can you read here : <br/> [Inno Setup Command Line Parameters](http://www.jrsoftware.org/ishelp/index.php?topic=setupcmdline) <br> <br> ``` best Blacky
Author
Owner

@BaWue commented on GitHub (Sep 11, 2019):

The following manual procedure allows to install an update of PathCopyCopy without the necessity of rebooting afterwards:

  1. Run the installer until it complains about "Windows-Explorer" needs to be closed
  2. Close the Windows-File-Explorer App if it is open
  3. Bring up Task Manager using Ctrl+Alt+Del and open the "Processes" tab
  4. Locate "Windows-Explorer" under "Background processes", this actually is not the File-Explorer but the Shell itself
  5. Right click on it and select "End Task", this actually removes the taskbar, the Start button and the desktop contents for the moment
  6. Continue the update installation of PathCopyCopy by clicking "Next"
  7. In Task-Manager Select "File" / "Run new task"
  8. In the "Open" edit field type "explorer.exe" an hit "OK", this starts the shell again and brings up your taskbar, Start button and desktop contents again.

I am using this on an account with local admin rights (but not the Administrator account itself). Not shure if this also works on an account which is not member of "Administrators".

<!-- gh-comment-id:530458580 --> @BaWue commented on GitHub (Sep 11, 2019): The following manual procedure allows to install an update of PathCopyCopy without the necessity of rebooting afterwards: 1. Run the installer until it complains about "Windows-Explorer" needs to be closed 2. Close the Windows-File-Explorer App if it is open 3. Bring up Task Manager using Ctrl+Alt+Del and open the "Processes" tab 4. Locate "Windows-Explorer" under "Background processes", this actually is not the File-Explorer but the Shell itself 5. Right click on it and select "End Task", this actually removes the taskbar, the Start button and the desktop contents for the moment 6. Continue the update installation of PathCopyCopy by clicking "Next" 7. In Task-Manager Select "File" / "Run new task" 8. In the "Open" edit field type "explorer.exe" an hit "OK", this starts the shell again and brings up your taskbar, Start button and desktop contents again. I am using this on an account with local admin rights (but not the Administrator account itself). Not shure if this also works on an account which is not member of "Administrators".
Author
Owner

@clechasseur commented on GitHub (Sep 11, 2019):

something named "Unattended Install switches"
for wiki:

Thanks for the input. I indeed have been planning a wiki section on advanced installation options, including command-line parameters. When this happens, you can check it out also to see if I forgot something.

<!-- gh-comment-id:530575226 --> @clechasseur commented on GitHub (Sep 11, 2019): > something named "Unattended Install switches" > for wiki: Thanks for the input. I indeed have been planning a wiki section on advanced installation options, including command-line parameters. When this happens, you can check it out also to see if I forgot something.
Author
Owner

@clechasseur commented on GitHub (Sep 11, 2019):

The following manual procedure allows to install an update of PathCopyCopy without the necessity of rebooting afterwards:

This indeed works but is a little bit convoluted. The installer's step to shut down and launch apps again afterwards should take care of this, but it seems buggy at the moment... I think I remember reading in Inno Setup's documentation that it uses a Windows API to implement this, so perhaps it's the API that's buggy.

I am using this on an account with local admin rights (but not the Administrator account itself). Not shure if this also works on an account which is not member of "Administrators".

It should, although you might see elevation prompts.

<!-- gh-comment-id:530575840 --> @clechasseur commented on GitHub (Sep 11, 2019): > The following manual procedure allows to install an update of PathCopyCopy without the necessity of rebooting afterwards: This indeed works but is a little bit convoluted. The installer's step to shut down and launch apps again afterwards _should_ take care of this, but it seems buggy at the moment... I think I remember reading in Inno Setup's documentation that it uses a Windows API to implement this, so perhaps it's the API that's buggy. > I am using this on an account with local admin rights (but not the Administrator account itself). Not shure if this also works on an account which is not member of "Administrators". It should, although you might see elevation prompts.
Author
Owner

@teknowledgist commented on GitHub (Sep 12, 2019):

Hi. Thanks for all the feedback.

Note: I first tried the Chocolately package I'm maintaining which uses the /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP- switches. I didn't know about the /CLOSEAPPLICATIONS (or /NOCLOSEAPPLICATIONS) switch. I'll have to try that when I get a chance. I will also try @BaWue 's process but scripted.

@clechasseur Question: Is the installer using a different method than the /CLOSEAPPLICATIONS switch uses? If not, then that should make no difference, right?

<!-- gh-comment-id:530644730 --> @teknowledgist commented on GitHub (Sep 12, 2019): Hi. Thanks for all the feedback. Note: I first tried the [Chocolately package I'm maintaining](https://chocolatey.org/packages/path-copy-copy) which uses the `/VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP-` switches. I didn't know about the `/CLOSEAPPLICATIONS` (or `/NOCLOSEAPPLICATIONS`) switch. I'll have to try that when I get a chance. I will also try @BaWue 's process but scripted. @clechasseur Question: Is the installer using a different method than the `/CLOSEAPPLICATIONS` switch uses? If not, then that should make no difference, right?
Author
Owner

@clechasseur commented on GitHub (Sep 12, 2019):

@clechasseur Question: Is the installer using a different method than the /CLOSEAPPLICATIONS switch uses? If not, then that should make no difference, right?

The installer lets the user decide whether to close applications or not. Not sure what your question mean though - here, we're trying to determine whether NOT closing the applications improves the stability of the update process. If it is determined that closing applications automatically via the installer causes issues, I can turn off this feature when building the installer.

<!-- gh-comment-id:530645177 --> @clechasseur commented on GitHub (Sep 12, 2019): > @clechasseur Question: Is the installer using a different method than the /CLOSEAPPLICATIONS switch uses? If not, then that should make no difference, right? The installer lets the user decide whether to close applications or not. Not sure what your question mean though - here, we're trying to determine whether NOT closing the applications improves the stability of the update process. If it is determined that closing applications automatically via the installer causes issues, I can turn off this feature when building the installer.
Author
Owner

@teknowledgist commented on GitHub (Sep 13, 2019):

What I'm trying to ask is...

When the user chooses to close Explorer in the GUI, does the installer use the same mechanism/call to close the Explorer program/process that the Inno setup uses if the /CLOSEAPPLICATIONS switch is used?

If they are the same, then -- assuming the silent switches also use the same mechanism as the manual choice in the GUI -- there is no point in using /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP- /CLOSEAPPLICATIONS because the process is already being attempted.

Based on my experience with some other Chocolatey packages, it's pretty common for DLLs for shell extensions to be locked (and not replaceable) until Explorer is closed. I'd be fairly surprised if Path-Copy-Copy could be upgraded without closing Explorer.

I'll test when I get a chance.

<!-- gh-comment-id:531054586 --> @teknowledgist commented on GitHub (Sep 13, 2019): What I'm trying to ask is... When the user chooses to close Explorer in the GUI, does the installer use the same mechanism/call to close the Explorer program/process that the Inno setup uses if the `/CLOSEAPPLICATIONS` switch is used? If they are the same, then -- assuming the silent switches also use the same mechanism as the manual choice in the GUI -- there is no point in using `/VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP- /CLOSEAPPLICATIONS` because the process is already being attempted. Based on my experience with some other Chocolatey packages, it's pretty common for DLLs for shell extensions to be locked (and not replaceable) until Explorer is closed. I'd be fairly surprised if Path-Copy-Copy could be upgraded without closing Explorer. I'll test when I get a chance.
Author
Owner

@clechasseur commented on GitHub (Sep 13, 2019):

When the user chooses to close Explorer in the GUI, does the installer use the same mechanism/call to close the Explorer program/process that the Inno setup uses if the /CLOSEAPPLICATIONS switch is used?

It is my understanding, although I have never verified this by reading Inno Setup's code.

If they are the same, then -- assuming the silent switches also use the same mechanism as the manual choice in the GUI -- there is no point in using /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP- /CLOSEAPPLICATIONS because the process is already being attempted.

I believe this is correct - furthermore, I believe that THIS is the reason it hangs during some updates. That's why I recommended you try using /NOCLOSEAPPLICATIONS to see if it allows the upgrade to work.

Based on my experience with some other Chocolatey packages, it's pretty common for DLLs for shell extensions to be locked (and not replaceable) until Explorer is closed. I'd be fairly surprised if Path-Copy-Copy could be upgraded without closing Explorer.

It can't, unless you reboot afterwards.

I'll test when I get a chance.

Let me know if you find a solution.

<!-- gh-comment-id:531056543 --> @clechasseur commented on GitHub (Sep 13, 2019): > When the user chooses to close Explorer in the GUI, does the installer use the same mechanism/call to close the Explorer program/process that the Inno setup uses if the /CLOSEAPPLICATIONS switch is used? It is my understanding, although I have never verified this by reading Inno Setup's code. > If they are the same, then -- assuming the silent switches also use the same mechanism as the manual choice in the GUI -- there is no point in using /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP- /CLOSEAPPLICATIONS because the process is already being attempted. I believe this is correct - furthermore, I believe that THIS is the reason it hangs during some updates. That's why I recommended you try using `/NOCLOSEAPPLICATIONS` to see if it allows the upgrade to work. > Based on my experience with some other Chocolatey packages, it's pretty common for DLLs for shell extensions to be locked (and not replaceable) until Explorer is closed. I'd be fairly surprised if Path-Copy-Copy could be upgraded without closing Explorer. It can't, unless you reboot afterwards. > I'll test when I get a chance. Let me know if you find a solution.
Author
Owner

@clechasseur commented on GitHub (Sep 20, 2019):

@teknowledgist did you have the time to test this? Is there a workaround for the upgrade issue? If disabling the closing of external program works, I'd like to implement this officially in 17.x.

<!-- gh-comment-id:533418830 --> @clechasseur commented on GitHub (Sep 20, 2019): @teknowledgist did you have the time to test this? Is there a workaround for the upgrade issue? If disabling the closing of external program works, I'd like to implement this officially in 17.x.
Author
Owner

@blackcrack commented on GitHub (Sep 20, 2019):

@clechasseur

Question: Is the installer using a different method than the /CLOSEAPPLICATIONS switch uses? If not, then that should make no difference, right?

The installer lets the user decide whether to close applications or not. Not sure what your question mean though - here, we're trying to determine whether NOT closing the applications improves the stability of the update process. If it is determined that closing applications automatically via the installer causes issues, I can turn off this feature when building the installer.

/CLOSEAPPLICATIONS

Instructs Setup to close applications using files that need to be updated by Setup if possible.
/NOCLOSEAPPLICATIONS

Prevents Setup from closing applications using files that need to be updated by Setup. If /CLOSEAPPLICATIONS was also used, this command line parameter is ignored.

it's maybe better, i guess there have a "blacklist" of programs where search for before it install
like explorer-window or totalcommander to close this application for prevent the user to able to show what's happen or so.. ( i guess to be a "security" thing for programmers and do"
so, if this not need, .. , turn it off..

best
Blacky

<!-- gh-comment-id:533433060 --> @blackcrack commented on GitHub (Sep 20, 2019): @clechasseur > > Question: Is the installer using a different method than the /CLOSEAPPLICATIONS switch uses? If not, then that should make no difference, right? > > The installer lets the user decide whether to close applications or not. Not sure what your question mean though - here, we're trying to determine whether NOT closing the applications improves the stability of the update process. If it is determined that closing applications automatically via the installer causes issues, I can turn off this feature when building the installer. >>/CLOSEAPPLICATIONS >> >> Instructs Setup to close applications using files that need to be updated by Setup if possible. >>/NOCLOSEAPPLICATIONS >> >> Prevents Setup from closing applications using files that need to be updated by Setup. If /CLOSEAPPLICATIONS was also used, this command line parameter is ignored. it's maybe better, i guess there have a "blacklist" of programs where search for before it install like explorer-window or totalcommander to close this application for prevent the user to able to show what's happen or so.. ( i guess to be a "security" thing for programmers and do" so, if this not need, .. , turn it off.. best Blacky
Author
Owner

@clechasseur commented on GitHub (Sep 20, 2019):

it's maybe better, i guess there have a "blacklist" of programs where search for before it install
like explorer-window or totalcommander to close this application for prevent the user to able to show what's happen or so.. ( i guess to be a "security" thing for programmers and do"
so, if this not need, .. , turn it off..

It's not a blacklist - there's a Windows API that the installer uses to get a list of running programs that are using any of the artifacts to be installed. That's the list the installer displays, offering you to shut the programs down.

<!-- gh-comment-id:533551715 --> @clechasseur commented on GitHub (Sep 20, 2019): > it's maybe better, i guess there have a "blacklist" of programs where search for before it install > like explorer-window or totalcommander to close this application for prevent the user to able to show what's happen or so.. ( i guess to be a "security" thing for programmers and do" > so, if this not need, .. , turn it off.. It's not a blacklist - there's a Windows API that the installer uses to get a list of running programs that are using any of the artifacts to be installed. That's the list the installer displays, offering you to shut the programs down.
Author
Owner

@blackcrack commented on GitHub (Sep 20, 2019):

what i had already seen .. on an other program .. ehh open-shell .. as example :)

<!-- gh-comment-id:533670670 --> @blackcrack commented on GitHub (Sep 20, 2019): what i had already seen .. on an other program .. ehh open-shell .. as example :)
Author
Owner

@teknowledgist commented on GitHub (Sep 23, 2019):

In various tests with a few different option but not the /NOCLOSEAPPLICATIONS, I was not able to find a pattern for when an upgrade failed. Sometimes it did, and sometimes it didn't. Sometimes it closed Explorer (or Xplorer2 lite - my other test app) and sometimes it didn't re-open it. If the machine was rebooted between the older install and the upgrade (as would likely always be the case), it seemed to be more likely to succeed, but not always.

I never had it fail when I used the /NOCLOSEAPPLICATIONS switch. Often, the new version was working even though it gave a required reboot exit message (using /RESTARTEXITCODE=3010).

IMO, it's better to succeed with the upgrade and give a notice of a need to reboot than fail the upgrade and make the user figure out how to make it work (i.e. uninstall first). All I would ask is that you return a "standard" reboot required exit code (if that is the case) for silent installs.

Thanks.

<!-- gh-comment-id:533947465 --> @teknowledgist commented on GitHub (Sep 23, 2019): In various tests with a few different option but **not** the /NOCLOSEAPPLICATIONS, I was not able to find a pattern for when an upgrade failed. Sometimes it did, and sometimes it didn't. Sometimes it closed Explorer (or Xplorer2 lite - my other test app) and sometimes it didn't re-open it. If the machine was rebooted between the older install and the upgrade (as would likely always be the case), it seemed to be more likely to succeed, but not always. I never had it fail when I used the /NOCLOSEAPPLICATIONS switch. Often, the new version was working even though it gave a required reboot exit message (using /RESTARTEXITCODE=3010). IMO, it's better to succeed with the upgrade and give a notice of a need to reboot than fail the upgrade and make the user figure out how to make it work (i.e. uninstall first). All I would ask is that you return a "standard" reboot required exit code (if that is the case) for silent installs. Thanks.
Author
Owner

@clechasseur commented on GitHub (Sep 23, 2019):

IMO, it's better to succeed with the upgrade and give a notice of a need to reboot than fail the upgrade and make the user figure out how to make it work (i.e. uninstall first). All I would ask is that you return a "standard" reboot required exit code (if that is the case) for silent installs.

I agree. I will thus disable the closing of applications by the installer. (This is the equivalent of always passing /NOCLOSEAPPLICATIONS on the command-line.)

As for the return code, I believe the best way to do this is to use /RESTARTEXITCODE. Not all users calling setup from the command-line or in other ways would want a non-zero exit code in this case - it could fail scripts unexpectedly, etc. If you need to a standardized exit code, this switch should do it.

<!-- gh-comment-id:534025352 --> @clechasseur commented on GitHub (Sep 23, 2019): > IMO, it's better to succeed with the upgrade and give a notice of a need to reboot than fail the upgrade and make the user figure out how to make it work (i.e. uninstall first). All I would ask is that you return a "standard" reboot required exit code (if that is the case) for silent installs. I agree. I will thus disable the closing of applications by the installer. (This is the equivalent of always passing `/NOCLOSEAPPLICATIONS` on the command-line.) As for the return code, I believe the best way to do this is to use `/RESTARTEXITCODE`. Not all users calling setup from the command-line or in other ways would want a non-zero exit code in this case - it could fail scripts unexpectedly, etc. If you need to a standardized exit code, this switch should do it.
Author
Owner

@clechasseur commented on GitHub (Sep 29, 2019):

Starting with version 17.1, installer will no longer offer to close and restart applications. (This can be overridden on the command-line if needed.)

<!-- gh-comment-id:536282909 --> @clechasseur commented on GitHub (Sep 29, 2019): Starting with version 17.1, installer will no longer offer to close and restart applications. (This can be overridden on the command-line if needed.)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/pathcopycopy#90
No description provided.