Brief summary

If something happens on startup of NVDA that causes a crash, and that thing is persistant, NVDA will get itself into a crash loop and will in some cases crash so fast that I cannot even attempt to recover it, since I have it starting on system boot. The recovery process restarts NVDA, which crashes it again, and restarts it. Whatever is happening makes it impossible to run something like taskkill /im nvda.exe /f /t. NVDA needs to be more resiliant to crash loops, and stop attempting a reboot after the nth crash in a session.

Steps to reproduce

1. Before starting the next steps, disable NVDA at system startup. Failure to do this will result in a fun hour or so of recovery.
2. in %appdata%\nvda\addonstore, break the file permissions of _dl. Deny read/execute and/or write. Preferably read/execute. IDK how this happened to me locally b ut it's happened a few times now.
3. Restart NVDA. Observe.
4. Restart NVDA.

Actual behavior

NVDA crashes, then reboots itself, hits the broken file permission, and instead of recovering from the error gracefully, crashes on repeat.

Expected behavior

NVDA shouldn't crash, but furthermore, something crashing NVDA in a boot loop should not crash NVDA on repeat. after the third or so crash, NVDA should simply stay dead.

NVDA logs, crash dumps and other attachments

INFO - main (15:27:09.171) - MainThread (4528):
Starting NVDA version 2025.3 x86
INFO - core.main (15:27:09.224) - MainThread (4528):
Config dir: C:\Users\driem\AppData\Roaming\nvda
INFO - config.ConfigManager.loadConfig (15:27:09.232) - MainThread (4528):
Loading config: C:\Users\driem\AppData\Roaming\nvda\nvda.ini
INFO - core.main (15:27:09.993) - MainThread (4528):
Windows version: Windows 11 24H2 (10.0.26100.6584) workstation AMD64
INFO - core.main (15:27:09.993) - MainThread (4528):
Using Python version 3.11.9 (tags/v3.11.9:de54cf5, Apr 2 2024, 10:00:00) [MSC v.1938 32 bit (Intel)]
INFO - core.main (15:27:09.993) - MainThread (4528):
Using comtypes version 1.4.11
INFO - core.main (15:27:09.993) - MainThread (4528):
Using configobj version 5.1.0 with validate version 1.0.1
CRITICAL - main (15:27:10.109) - MainThread (4528):
core failure
Traceback (most recent call last):
File "nvda.pyw", line 309, in
File "core.pyc", line 748, in main
File "gui\addonStoreGui_init.pyc", line 8, in
File "gui\addonStoreGui\controls\storeDialog.pyc", line 31, in
File "gui\addonStoreGui\viewModels\store.pyc", line 60, in
File "gui\addonStoreGui\viewModels\store.pyc", line 72, in AddonStoreVM
File "addonStore\network.pyc", line 115, in init
File "shutil.pyc", line 787, in rmtree
File "shutil.pyc", line 615, in _rmtree_unsafe
File "shutil.pyc", line 612, in _rmtree_unsafe
PermissionError: [WinError 5] Access is denied: 'C:\Users\driem\AppData\Roaming\nvda\addonStore\_dl'
... then dies annd reboots.

NVDA type

installed copy

NVDA version

2025.3 or below

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

25.2. Haven't tried alpha

Windows version

@Version 24H2 (OS Build 26100.6584)

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

No response

Other information about your system

IDK how this file permission spontaneously combusts, but it brought up the larger issue, NVDA should not hold the system hostage when its in a boot failure that leads to a crash loop.

Does the issue still occur after restarting your computer?

I have restarted my computer and the issue still occurs

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

I have restarted NVDA with add-ons disabled and the issue still occurs

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

I have run the COM Registration Fixing Tool and the issue still occurs