electron-builder: NSIS Installer stuck at "Installing, please wait..."

  • 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

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 33
  • Comments: 52 (10 by maintainers)

Commits related to this issue

Most upvoted comments

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

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

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

If bugs as serious as this still exist after a year, this repository should be marked as unmaintained. Just saying.

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

@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?

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

22.9.1 marked as release.

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

@Slapbox That’s exactly what happened to some of our users. Auto updater fails and then application becomes untouchable be either installer or uninstaller.

This is the problematic commit, which caused breaking change: https://github.com/electron-userland/electron-builder/commit/7518aee8e1abe0516071b350748e84dc47e35cf7

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 👍

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

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

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.

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?

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

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.

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

We just ran into this issue and after spending 20 minutes walking through it with a user (using the solution suggested by @gomorizsolt and @stilettk) and it worked.

Because the registry key is just a bunch of gibberish, it’s impossible for us to even give people reasonable instructions to handle this themselves.

Echoing what’s been said: even an error message would be far better than the current behavior.

@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

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

Can confirm that this still happens for me as well 😦

This still happens for our project as well. @develar

Yea, to me its a pretty critical issue and should be higher prioritized. Would give it a shot myself if I was comfortable with the codebase.

It’s remarkable to me that on this nearly year old issue, there’s a single response from a contributor, and it’s to say that they’re having the issue also…

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

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.

@develar, I ran in to this too and https://github.com/electron-userland/electron-builder/issues/4057#issuecomment-574823454 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.

The workaround by @o2genum and @rlugge worked for me, but interestingly, I needed to explicitly add "include": "build/installer.nsh" in the nsis key of package.json (running v22.7.0 (latest))

@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.

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.

@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.

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.

@EmptyCrown I don’t think working with registry keys on Windows is that hard of a task electron-builder can’t handle. There should certainly be a way to make this automatic, that’s why we have “software”. But the way this issue is ignored is just sad.

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

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.