NSIS Installer stuck at "Installing, please wait..."

[ticarexbbl]

• electron-builder Version: 21.0.15

• Target: win10 nsis

Package.json:

"build": {
    "asar": false,
    "win": {
      "target": "nsis"
    },
    "nsis": {
      "runAfterFinish": false,
      "artifactName": "${productName}-${version}-instalador.${ext}",
      "oneClick": true
    }
  }

installer.nsh:

!macro preInit
  SetRegView 64
  WriteRegExpandStr HKLM "${INSTALL_REGISTRY_KEY}" InstallLocation "C:\${COMPANY_NAME}\${PRODUCT_NAME}"
  WriteRegExpandStr HKCU "${INSTALL_REGISTRY_KEY}" InstallLocation "C:\${COMPANY_NAME}\${PRODUCT_NAME}"
  SetRegView 32
  WriteRegExpandStr HKLM "${INSTALL_REGISTRY_KEY}" InstallLocation "C:\${COMPANY_NAME}\${PRODUCT_NAME}"
  WriteRegExpandStr HKCU "${INSTALL_REGISTRY_KEY}" InstallLocation "C:\${COMPANY_NAME}\${PRODUCT_NAME}"
!macroend

Installer gets successfully built but when executed gets stuck at "Installing, please wait..." forever

[Morgahl]

Generally the only time I see this behavior is when an existing install has been deleted rather then explicitly uninstalled via Add Remove Programs or the uninstaller itself.

[ticarexbbl]

Yes, the existing install was indeed deleted instead of being uninstalled properly, but the installer should be able to handle this fairly common situation and install it anyway or at least show some kind of error

[kebugcheckex]

Generally the only time I see this behavior is when an existing install has been deleted rather then explicitly uninstalled via Add Remove Programs or the uninstaller itself.

For whoever run into this situation, use CCleaner to manually remove the entry from Windows Program list. Then re-run the installer.

For reference, see this page

[freewind]

This is quite confusing for end users, is it able to force re-install new versions?

[gomorizsolt]

We've also encountered with the exact same situation. After removing the app's folder manually, the installer kept hanging around nearly half of the process.

but the installer should be able to handle this fairly common situation and install it anyway or at least show some kind of error

Even though it's supposed to be the expected behavior, it's not the case here. We could eliminate the issue by removing the so-called UninstallString registry from the system, for which you should:

• open Registry Editor
• click on Edit/Search and search for your application's name
  • (1) note: you could create a backup of your registries by clicking on File/Export
  • (2) note: pay attention to use the exact same name, otherwise the system won't find the appropriate registry

It's quite cryptic why it actually works this way and I'm also not familiar with this whole registry system at all, but hopefully someone will find it useful until there's no explanation/ultimate solution for this issue.

Please also refer to @kebugcheckex's comment. There's a URL which roughly explains how apps can be purged from the system.

[o2genum]

@develar This is a rather critical bug. Users who delete the app folder manually or with some weird tools cannot reinstall the app. Is this fixable with a custom NSIS script?

[Christilut]

Just ran into this, kind of surprised the installer is completely stuck on this...

[stilettk]

We have found that the issue was because of old registry key at Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall, which had the same guid, but without curly braces.
So we had {308cc20e-7a56-5705-91f7-e9a0f443a5cd} as correct one, and 308cc20e-7a56-5705-91f7-e9a0f443a5cd as incorrect one. Deleting 308cc20e-7a56-5705-91f7-e9a0f443a5cd solved the issue.

This is worth noting that we didn't change the appId. it seems like the installer bug in some old version? We currently use electron-builder v22.1.0

[stilettk]

This is the problematic commit, which caused breaking change: 7518aee

I suggest developers to handle this situation in code so that users of electron-builder won't have to send .reg files to their users 👍

[damianszk]

We have found that the issue was because of old registry key at Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall, which had the same guid, but without curly braces.
So we had {308cc20e-7a56-5705-91f7-e9a0f443a5cd} as correct one, and 308cc20e-7a56-5705-91f7-e9a0f443a5cd as incorrect one. Deleting 308cc20e-7a56-5705-91f7-e9a0f443a5cd solved the issue.

This is worth noting that we didn't change the appId. it seems like the installer bug in some old version? We currently use electron-builder v22.1.0

OMG. This has worked. I don't know what I've actually done.

[o2genum]

Removing the old incorrect Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\{308cc20e-7a56-5705-91f7-e9a0f443a5cd} does not work for me. I do this in my custom script, so that users don't see duplicate uninstall entries.

But this does not help when the app folder is manually deleted.

[o2genum]

My workarounds for this issue:

!macro customInit
  ; Workaround for installer handing when the app directory is removed manually
  ${ifNot} ${FileExists} "$INSTDIR"
    DeleteRegKey HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\{${UNINSTALL_APP_KEY}}"
  ${EndIf}

  ; Workaround for the old-format uninstall registry key (some people report it causes hangups, too)
  ReadRegStr $0 HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\${UNINSTALL_APP_KEY}" "QuietUninstallString"
  StrCmp $0 "" proceed 0
  DeleteRegKey HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\${UNINSTALL_APP_KEY}"
  proceed:
!macroend

[rlugge]

@o2genum could you explain how to use that workaround? I'm getting what appears to be this problem (though we haven't manually removed the files), but I don't understand how to debug or fix it.

[rlugge]

For future googlers, to addendum my previous comment: I created an installer.nsh file in my build directory, and filled it with the contents of @o2genum 's post:

!macro customInit
  ; Workaround for installer handing when the app directory is removed manually
  ${ifNot} ${FileExists} "$INSTDIR"
    DeleteRegKey HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\{${UNINSTALL_APP_KEY}}"
  ${EndIf}

  ; Workaround for the old-format uninstall registry key (some people report it causes hangups, too)
  ReadRegStr $0 HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\${UNINSTALL_APP_KEY}" "QuietUninstallString"
  StrCmp $0 "" proceed 0
  DeleteRegKey HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\${UNINSTALL_APP_KEY}"
  proceed:
!macroend

[DalderupMaurice]

@develar This is a rather critical bug. Users who delete the app folder manually or with some weird tools cannot reinstall the app. Is this fixable with a custom NSIS script?

IMO this is pretty critical indeed. Tried to install an electron-based application, but our company policy didn't allow the installation at first.

After it being allowed and me trying to install it again it got stuck due to this issue

[alexandermckay]

Something that helped me was running CCleaner as recommended by @kebugcheckex and then setting "artifactName": "${productName}.${ext}".

The default artifactName was creating a slightly different installer name each time, which led to auto updates not overwriting the pre-existing program.

[Nantris]

I never saw this issue with 20.39.x - I'm pulling my hair out over this bug on literally day 2 after upgrading to the latest electron-builder. If this happened to a user, I can be pretty sure they're never getting this fixed, giving up, and lost to us forever as a user.

THIS IS A CRITICAL BUG

[yafp]

Something that helped me was running CCleaner as recommended by @kebugcheckex and then setting "artifactName": "${productName}.${ext}".

The default artifactName was creating a slightly different installer name each time, which led to auto updates not overwriting the pre-existing program.

Thanks, good to know.
But on the other hand this is not a perfect fix, as the installer now has a name which isn't clearly pointing out the version number.

How do you handle this situation, as i assume all your other builds do feature the version number in the filename

[adamwdennis]

I just ran into this using electron-builder v22.3.2.
The only fix is to remove the specific registry keys under
HKCU "Software\Microsoft\Windows\CurrentVersion\Uninstall\

[Stanzilla]

@develar hey there, any official plans/workarounds for this?

[viktorgullmark]

Any updates on this? This is reported very frequently from our users and we dislike telling them to manually remove a registry key..

[makidoll]

We're having this problem too and it's very frustrating

[Nantris]

Nightmare issue remains a nightmare.

I think the best part of this issue is probably the fact that the key name is lost, so the entry appears like .../Software/Microsoft/Windows/Uninstall/b8d41b55-5f1c-5d6e-90b0-b704a2b8ba67 - Extremely user friendly for laymen to fix.

[Numbergod]

I've just run into the freezing installer problem too.

New to Joplin. Trying to re-install after the old directory got damaged. Seem to remember not being able to originally install it either, but finding an older version that did eventually install, so I assumed it was that.

Back to today.
(Joplin-Setup-1.0.232.exe Win7 SP1) Didn't have a clue where to begin to troubleshoot it. (Did it still support Win7)

Eventually found my way here via Google. Scanned the fix and searched "Joplin" in regedit) only found two entries. One under
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall

Removed (both) as suggested.

So. It seems like a trivial fix to me.

1. Go to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall
2. Scan it's children for "Joplin"
3. Delete the node.
4. Continue the install

Or am I missing something?

Either way I think something needs to be done. Even down to a searchable error message or number to give people a clue as to what the problem is.

Apart from that. It looks interesting, and I look forward to having a play with it.

Don.

[gilhrpenner]

Some of my users have been complaining about this issue, though I tried to explain how to manually delete the registry some of them don't feel comfortable in doing it themselves.

We need a fix for this bug

[o2genum]

@Numbergod, this fix works when the install dir is removed entirely:
#4057 (comment)

The bug occurs when the uninstaller in the install directory is missing/damaged/fails for some reason.

That fix works in most cases, except the most subtle ones when the uninstaller is present, but fails due to mysterious reasons.

[Numbergod]

Thanks for that. But I've managed to install it last week. And the fix is useless to people unless they know why it's failed and can research the fix to find it. Which they can't at present as the installer "just stops" with no information as to why.

As outlined above;
#4057 (comment)

I think coding a solution that looks for this issue before proceeding is the way to mark this bug as fixed, and help everyone in the future.

Thanks for your assistance, but if the installer checked for, and fixed the issue, I would never have had to spend hours looking into this, fixing my copy, and attempting to get the issue resolved properly.

I'm not sure how this isn't the completely obvious way to fix this issue?

Anyway. Good luck with your project. I look forward to spending more time using it, than I currently have, trying to fix it.

[Nantris]

Hit the bug yet again.

Google electron builder "critical bug" and this is the first result.

Could we get any comment on this very serious problem?

[o2genum]

This seems to have been fixed by #3782 and #4674

Works with missing/fake broken uninstaller (with random bytes) and with installation dir emptied/removed.

[Nantris]

@o2genum #3782 was merged over a year ago and the issue persists.

[o2genum]

@slapbox Sorry, my bad, with the latest electron-builder 22.8.0 issue persists indeed.

I updated my electron-builder and it worked for me only onсу because they changed the Uninstall\{GUID} registry key back to Uninstall\GUID. Looking into the sources.

[o2genum]

Apparently, in assisted mode the installer is meant to get stuck until cancelled.

It says "Installation Aborted" and "Setup was not completed successfully" and offers a "Cancel" button.

[amiller-gh]

@develar, I ran in to this too and #4057 (comment) resolved it for me.

Are you interested in a PR to make this part of the default nsis install script? Happy to work on that.

[develar]

@amiller-gh Yes, PR is welcome.

[ryanrocket]

Do we have any sort of fix on the software side of this? Like a setting that can be changes in package.json? Im surprised this has been open for more than a year now.

[develar]

22.9.1 marked as release.