With a corrupted config file, NVDA restarts forever

[CyrilleB79]

Issue found while trying to improve corrupted config debugging.

Steps to reproduce:

• Ensure that you have not NVDA to start when opening your session, else, it may cause you more difficulty.
• With NVDA not running (e.g. with Narrator), edit your nvda.ini config file to create a syntax error in it: e.g. remove the closing bracket (]) from "[general]" section name
• Start NVDA

Actual behavior:

NVDA restarts forever.

Note: Control+alt+delete and reboot your computer or change user session to avoid it to restart forever.

Expected behavior:

Restore the behaviour of NVDA 2023.1, that is:
NVDA should display a message that the config is corrupted and reinitialize it to default.
Note: The goal of this issue is to fix the regression that has occurred in NVDA 2023.2. I think that there is another issue to improve the behaviour existing in NVDA 2023.1, i.e. do not throw away the config file, but I have not been able to find it.

NVDA logs, crash dumps and other attachments:

nvda-old.log

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

NVDA 2023.3rc2

Windows version:

Windows 10 22H2 (AMD64) build 19045.3570

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

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

Bug also present in NVDA 2023.2.
NVDA 2023.1 is fine instead.

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

Not tested; unrelated.

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

Not tested; unrelated.

[XLTechie]

@CyrilleB79 I disagree that the desired behavior should be that a new config is initialized. Forgive me if I am wrong, but that's what I understood you to be saying. What should happen instead, in my view, is that NVDA should load as if an empty config was given (i.e. all defaults), and create a modal message stating that the configuration is potentially corrupt, and NVDA is running with default configuration values. Additionally, it can ask if the user wants to create a new configuration, overwriting the existing file, or leave the configuration unsaved in which case the user will have to manually resolve the problem. If the user chooses manual resolve, then automatic config saving on exit should be disabled. At this point, if the user chooses manual, they can either edit the config (in your example to put the missing bracket back), or start changing config values and manually save, or turn auto save of config on exit back on. Then the user can restart NVDA. If the user chooses initialize a new config, an immediate save of the defaults is done, unless you want to include an extra confirmation step. However this is handled, whether my suggestion or another, I am very opposed to NVDA saving a "corrected" configuration without the user explicitly approving such an action. Otherwise a minor manual edit error could cause the destruction of an otherwise perfect carefully crafted configuration.

[CyrilleB79]

@XLTechie, the goal of this issue is to fix the regression that has occurred in NVDA 2023.2. I think that there is another issue to improve the behaviour existing in NVDA 2023.1, i.e. do not throw away the config file, but I have not been able to find it.
I have updated the initial description to clarify this.

The benefit of keeping two separate issues is that the current one (fixing the regression by restoring the previous behaviour) can be submitted as a PR without any discussion on UX design and will allow to avoid the startup failure. It should go in NVDA ASAP, i.e. in 2024.1.

Changing the behaviour existing in NVDA 2023.1 instead can lead to more discussion about UX. And if there is a separate PR, it can also be reverted if needed without introducing the start-up failure issue.

[XLTechie]

@CyrilleB79 I hadn't realized until I read your PR (which I did a while after posting that comment), that this was a reversion to immediately prior behavior from a recent regression. I will leave my earlier comment visible until we find that other issue you spoke of (which I also remember, vaguely), but I now understand your chosen direction.