Context:
A similar issue has been described in #16070 and fixed in #16074 thanks to @lukaszgo1.
@lukaszgo1, maybe you would like to have a look to this one?
Steps to reproduce:
Cause an exception in winInputHook.keyboardHook.
Here is a diff to force such exception:
diff --git a/source/winInputHook.py b/source/winInputHook.py
index 26703ae967..860844105a 100755
--- a/source/winInputHook.py
+++ b/source/winInputHook.py
@@ -53,6 +53,11 @@ def keyboardHook(code,wParam,lParam):
if not keyUpCallback(kbd.vkCode,kbd.scanCode,bool(kbd.flags&LLKHF_EXTENDED),bool(kbd.flags&LLKHF_INJECTED)):
return 1
elif keyDownCallback:
+ # Test: For each 20 second period, during 10 seconds (i.e. half of the period) a dummy error is raised
+ # upon each key press.
+ from time import time
+ if int(time()%20) > 10:
+ raise RuntimeError('This is a dummy error')
if not keyDownCallback(kbd.vkCode,kbd.scanCode,bool(kbd.flags&LLKHF_EXTENDED),bool(kbd.flags&LLKHF_INJECTED)):
return 1
return windll.user32.CallNextHookEx(0,code,wParam,lParam)
Apply this diff on top of commit 89e33cd (last master). For each 20 second period you will have:
- 10 seconds during which any keypress will trigger a dummy error in the hook
- 10 seconds where the hook behaves normally, so that you can look at the log.
Actual behavior:
The following errors appear in the log:
ERROR - stderr (15:52:39.987) - winInputHook (16888):
Exception ignored on calling ctypes callback function
ERROR - stderr (15:52:40.003) - winInputHook (16888):
:
ERROR - stderr (15:52:40.018) - winInputHook (16888):
<function keyboardHook at 0x04921D48>
ERROR - stderr (15:52:40.034) - winInputHook (16888):
Traceback (most recent call last):
ERROR - stderr (15:52:40.049) - winInputHook (16888):
File "C:\Users\Cyrille\Documents\DevP\GIT\nvda\source\winInputHook.py", line 60, in keyboardHook
ERROR - stderr (15:52:40.063) - winInputHook (16888):
raise RuntimeError('This is a dummy error')
ERROR - stderr (15:52:40.080) - winInputHook (16888):
RuntimeError
ERROR - stderr (15:52:40.096) - winInputHook (16888):
:
ERROR - stderr (15:52:40.110) - winInputHook (16888):
This is a dummy error
Expected behavior:
Only one message should be logged.
NVDA logs, crash dumps and other attachments:
See Actual behavior section.
System configuration
NVDA installed/portable/running from source:
Running from source
NVDA version:
Last master: commit 89e33cd
Windows version:
Windows 10 22H2 (AMD64) build 19045.3930
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?
Not tested, probably yes.
Have you tried any other versions of NVDA? If so, please report their behaviors.
NVDA 2023.3.3 (from source): issue not present
If NVDA add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Not tested
Context:
A similar issue has been described in #16070 and fixed in #16074 thanks to @lukaszgo1.
@lukaszgo1, maybe you would like to have a look to this one?
Steps to reproduce:
Cause an exception in
winInputHook.keyboardHook.Here is a diff to force such exception:
Apply this diff on top of commit 89e33cd (last master). For each 20 second period you will have:
Actual behavior:
The following errors appear in the log:
Expected behavior:
Only one message should be logged.
NVDA logs, crash dumps and other attachments:
See Actual behavior section.
System configuration
NVDA installed/portable/running from source:
Running from source
NVDA version:
Last master: commit 89e33cd
Windows version:
Windows 10 22H2 (AMD64) build 19045.3930
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?
Not tested, probably yes.
Have you tried any other versions of NVDA? If so, please report their behaviors.
NVDA 2023.3.3 (from source): issue not present
If NVDA add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Not tested