Why can't I launch installers from previous versions of NVDA?

[harun-342]

I'm using NVDA 2025.2. I needed NVDA 2023.3. I downloaded it from NV Access. When I run the installer, for some reason, it opens with my existing NVDA instead of the 2023.3 installer. Why is this happening? No matter what I did, I couldn't get the 2023.3 installer to work. I finally found a solution: completely uninstalling 2025.2 and running the 2023.3 installer.

[hwf1324]

Hi,

NVDA does not officially support downgrade installations.

Thanks!

[CyrilleB79]

Hello

@hwf1324 wrote:

NVDA does not officially support downgrade installations.

True. But here @harun-342 just launches the launcher.

I guess the following use case should be supported:
I have 2025.2 installed. I need 2023.3 for a specific task (e.g. use a specific add-on, test a regression, etc.). I should be able to launch NVDA 2023.3 to copy a portable copy and use it.
Today, this use case is not supported.

I cannot reproduce with 2025.3rc1 installed and 2023.3 launcher. Though, I can reproduce something quite similar, but not identical, with 2019.2.1 launcher. I get the following errors;

• First:

ERROR - brailleInput.BrailleInputHandler.__init__ (14:12:53.776):
Invalid table: auto

• then:

CRITICAL - __main__ (14:12:53.776):
core failure
Traceback (most recent call last):
  File "nvda.pyw", line 231, in <module>
  File "core.pyo", line 284, in main
  File "brailleInput.pyo", line 48, in initialize
  File "brailleInput.pyo", line 70, in __init__
  File "brailleTables.pyo", line 52, in getTable
KeyError: 'en-us-comp8.ctb'

Not very sure why NVDA 2019.2.1 canot initialize with this default braille table. But the consequence is that NVDA 2019.2.1 finishes with this critical error. In my case, 2025.3rc1 has not been restarted in replacement.

But in some cases, when NVDA crashes, Windows automatically restarts the installed version. Maybe that's what happens to you @harun-342.

It should be noted that NVDA launcher uses the user's default configuration (in Roaming folder). So technically, the launcher may try to use a configuration file with a more recent schema, what may create issues.

@harun-342 you may want to open an issue to report this bug. Though, if the problem comes from the old version, it will never be fixed for already released versions. But it may be fixed for future use cases, e.g. trying to create a 2026.1 portable from the launcher while 2027.1 is installed on the system.

As a workaround, I'd suggest you to run the launcher with a -c %tmp%\nvdaEmptyFolder flag, so that you use a brand new empty config folder. If the issue was caused by a config incompatibility, this trick may solve it.

[SaschaCowley]

This is most likely a config or add-on compatibility issue. Could you provide a log file of the behaviour? Ensure your log level is set to debug in general preferences. Note that you'll need to send nvda-old.log.

[harun-342]

Hi, I was going to report this as an issue, but since it happened right when NVDA was closing and restarting, I don't know if I can log it. If so, I can reproduce the issue and post it. Since I'm not using any plugins, I'm confident this isn't a plugin incompatibility.

[SaschaCowley]

NVDA starts logging extremely early on. Any errors it encounters before it starts logging should bring up a dialog box. If you are concerned that the logs may contain sensitive information, you can reproduce the issue and send nvda.log and nvda-old.log to info@nvaccess.org and mention that they relate to this discussion.

The log files are stored in the user temporary files folder. You can get there by opening Run (Windows+r), and entering "%temp%" without the quotes. Make sure you copy the logs before restarting NVDA.

[harun-342]

See #18905.