Difficulties installing NVDA 2024.3beta1

[CyrilleB79]

I do not know if these issues are specific to my system. I write them here in case other people experiment the same issues than I.

Steps to reproduce:

• Launch NVDA 2024.2rc2 (the last one)
• When NVDA offers to update to 2024.3beta1, accept it.

Actual behavior:

I get the following dialog:

File in Use
The installation is unable to remove or overwrite a file. Another copy of NVDA may be running on another logged-on user account. > Please make sure all installed copies of NVDA are shut down and try the installation again.

Notes:

• there is no indication in the log of the path/name of the file causing this issue unfortunately.
• during the install, I think that there were a virus scan in the background (Symantec Endpoint Protection); wonder if it was the culprit.

After having closed all other windows and interrupted the virus scan, I press "Retry" in this dialog, without success.

Then I have cancelled the install and tried to restart NVDA with control+alt+N.
Unfortunately, my NVDA 2024.2rc2 is in a broken state. I get the following error message:

C:\Program Files (x86)\NVDA\nvda_slave.exe
Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.

If I restart or just disconnectclose/reopen user session, NVDA starts correctly automatically when the session open. But I cannot restart it with control+alt+N.

No more luck trying to upgrade after computer restart.

Then I have downloaded the installer from the web and launched it manually. I get the following message:

You are attempting to install an earlier version of NVDA than the version currently installed. If you really wish to revert to an earlier version, you should first cancel this installation and completely uninstall NVDA before installing the earlier version.

Note: looking at the code, I can see that the date of nvda_slave.exe is looked at to determine if the install is older or newer. In case of error unfortunately, there is no warning logged.

Finally, I have chosen to install 2024.3beta1 on 2024.2rc1, ignoring the wrong warning. The install seems successful.

Note: I have also had to validate the new certificate ("Run anyway") during this process, but I cannot remember when I did it.

Expected behavior:

NVDA should install normally.

NVDA logs, crash dumps and other attachments:

N/A

System configuration

NVDA installed/portable/running from source:

Installed (or almost)

NVDA version:

2024.2rc2 to 2024.3beta1 (install process)

Windows version:

Windows 10 22H2 (AMD64) build 19045.4529

Name and version of other software in use when reproducing the issue:

N/A

Other information about your system:

N/A

Other questions

Does the issue still occur after restarting your computer?

Yes (at least for part of the process)

Have you tried any other versions of NVDA? If so, please report their behaviors.

No

If NVDA add-ons are disabled, is your problem still occurring?

Yes (for part of the process at least)

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

N/A

[josephsl]

Hi, having encountered similar issues on alpha builds, I found that one way to “resolve” this is to wait until NVDA finishes announcing User Account Control screen content, say “yes”, and wait for the installation to complete. Thanks.

[CyrilleB79]

Thanks for your feedback @josephsl. Have you a link (GitHub or mailing list discussions) where your experience on alpha is described?

My experience is not really similar though.
In any case, I have had to have the UAC announced by NVDA and focused since on this computer, I am running NVDA on an account without admin rights and I have to explicitly enter a user name and a passsword for a speicific local administrator account to start the update installation.
But the root cause may be the same.

[LeonarddeR]

I have seen this with a recent alpha build as well. Thought it was just random. I was able to fix it by executing taskkill /f /im nvda.exe

[Adriani90]

Are you having any braille display connected?
I can imagine following PRs could have an impact:
#16710, #16738, #16771, or #16712.

[CyrilleB79]

No, no braille display was connected.

[michaelDCurran]

I am able to reproduce the issue, with the cause being that nvda_slave.exe is currently running suspended, when it should not be running at all.
The exact commandline line that started it was:

c:\program files (x86)\nvda\nvda_slave.exe launchNVDA -r

The only place this occurs is when starting NVDA from the desktop shortcut or with control+alt+n.
Though nvda_slave.exe should launch nvda.exe with shellExecute and exit straight away. It hsould not stay running nor become suspended. In deed, I'm not even sure how a process generally becomes suspended...

After killing nvda_slave.exe and trying many more installs and restarts of NVDA with control+alt+n, I am unable to reproduce the issue. So, I have no current idea what is causing nvda_slave.exe to sty around suspended.
A possibility may be that Windows is "restarting" it when rebooting for windows updates and auto logging in again... though I'm really not sure.

We may have to consider adding specific code to the installer to kill nvda_slave.exe, though this is pretty drastic.

As to why it is suddenly starting to happen now, and how... Perhaps it is a very recent change in Windows 11?

Also, NVDA seeming to be broken after failed installation I think is more that the Windows shell is confused about nvda_slave.exe being around suspended. I think we can rule out install corruption - installer code added earlier this year ensures that if any of the exe files cannot be replaced, then no changes are made to the existing install.

[CyrilleB79]

@michaelDCurran wonders:

As to why it is suddenly starting to happen now, and how... Perhaps it is a very recent change in Windows 11?

Not at all. As detailed in this issue's initial description, the issue has occurred on Windows 10 22H2 on my end.

[michaelDCurran]

@CyrilleB79 Ah sorry I misread your OS version. Most likely not a new Microsoft issue then.

[Adriani90]

I wonder whether this issue is for a longer time there in other circumstances but now it became more noticeable? Maybe #11553 and #11314 could be related?

[seanbudd]

We are going to try killing the nvda_slave.exe process using psutil if it fails to be deleted. We can also add logs for information on running processes

[CyrilleB79]

I have just had the issue again while installing 2024.3beta2 on the same computer. This time, there were no virus scan in the background.

When the "Retry" dialog appeared, Instead of interrupting the installation of NVDA, I have terminated the process "nvda.exe", as suggested by @LeonarddeR in #16784 (comment), through taskmanager rather than through command line though. Then I have pressed "Retry" and NVDA's installation has been able to complete successfully.

[CyrilleB79]

Same issue with 2024.3beta3 and same solution killing nvda.exe.

It's worth noting that the nvda.exe process account that I kill is launched with the same session user name, so we can eliminate interference from:

• other users, more specifically the local admin used to upgrade NVDA
• the system account on secure screens

Also, after having killed this process, NVDA still speaks without any problem, both on secure screen and in the user session.

@seanbudd or @michaelDCurran, the problem seems 100% reproducible on this machine for any update of 2024.3beta. It would be the opportunity to investigate this if you wish to do so.

By the way, I am able to trigger the issue performing a fake update as follows:

• In Python console, to spoof the current release, type:
  import versionInfo;versionInfo.version = '2024.3beta2'
• From NVDA menu, launch a manual update

[CyrilleB79]

By the way @gerald-hartig why did you change the priority of this issue?

According to triage doc:

A P1 causes the inability to perform a popular task or majority of tasks in NVDA or a popular app.

Installation NVDA 2024.3 is the preliminary step to perform any task in NVDA 2024.3. Thus I'd expect this issue to fall in P1 category.
We cannot expect the average users to kill NVDA's process in task manager as a workaround...

[LeonarddeR]

Note that the executable of NVDA that runs during installation is called nvda_noUIAccess.exe.
It really looks like the NVDA instance that initiates the update doesn't kill itself correctly. In the past, the currently running instance was killed by the updating instance.

[michaelDCurran]

@CyrilleB79 I'm guessing you can also still reproduce this from beta3 to beta3? I.e. by spoofing the version? I ask as several add-on / update notification issues were fixed around installing / exiting. And of course you would have still seen the issue on upgrade from beta2 to beta3 as beta2 still had the issue.
Can you see what the state of nvda.exe is, was it running or suspended?
Can you also verify that you have no crash / debugger windows open at all? Sometimes they are hard to find as they go to the back of the alt+tab queue.
Assuming the process is suspended, I do have code that could kill it off which we could add. But I am very hesitant to kill it off if it is 'running'.

[michaelDCurran]

@CyrilleB79 What do you mean by:
If NVDA add-ons are disabled, is your problem still occurring?
Yes (for part of the process at least)

If you make sure that NVDA is completely exited, no nvda.exe, then start NVDA with add-ons disabled. And then update, do you still see the issue?

[michaelDCurran]

@CyrilleB79 Would you be willing to share your NVDA config? You can send this to me privately if you like. At very least, the config printed at log level debug when NvDA starts.
I'm still having no luck reproducing this.

[CyrilleB79]

After some investigations, it turns out that the issue was caused by an add-on, more specifically an unreleased and incomplete version of my own add-on NVDA Dev & Test Toolbox.
In this add-on, an error in a non-daemon trhead was preventing it to terminate, preventing NVDA from terminating too.
I apologize for the confusion.

Anyway, I think that this issue may be the opportunity to investigate the following points that have been raised during investigation.
When the installer cannot override a file, a retry/abort dialog is shown:

1. Could the name of the problematic file be shown in this dialog? Or at least in the log?
2. When "Retry" is clicked, the UAC elevation is requested again and I am requested to enter again my local admin username and password. Couldn't NVDA installer keep the elevated privileges?

[LeonarddeR]

An error in a non-daemon trhead was preventing it to terminate, preventing NVDA from terminating too.

In my opinion, it is the responsibility of the installer to kill every executable it cannot replace. It should be able to do so when running elevated.

2. When "Retry" is clicked, the UAC elevation is requested again and I am requested to enter again my local admin username and password. Couldn't NVDA installer keep the elevated privileges?

I think this is difficult to do by design. The installer process starts nvda_slave elevated to perform the actual install. When nvda_slave fails, the error is shown. When retry is clicked, nvda_slave needs to be restarted and re-elevated.

[seanbudd]

@CyrilleB79 - is this still an issue?

[CyrilleB79]

@seanbudd, the problem was due by an add-on in dev stage on my side, as explained in #16784 (comment).

Though, @LeonarddeR wrote in #16784 (comment):

In my opinion, it is the responsibility of the installer to kill every executable it cannot replace. It should be able to do so when running elevated.

This was not the case in July, and I have not heard of something done in that matter since then. So I have not tested again but the problem should still be here, I guess.

[XLTechie]

@CyrilleB79

In my opinion, it is the responsibility of the installer to kill every executable it cannot replace. It should be able to do so when running elevated.

That may be a more intricate problem than anticipated. See the discussion in #16933.

[Adriani90]

@CyrilleB79 I think that build of Windows 10 was problematic and caused other similar issues too. Are you still having this issue with NVDA 2024.4.1 on a newer build of windows 10?

[seanbudd]

Closing as invalid - this was caused by third party software