NVDA exits automatically in MS Word when working with this document

[Adriani90]

Steps to reproduce:

1. Open NVDA
2. In any MS Word version, open the attached document
3. Press ctrl+shift+down arrow to select paragraphs of text and tables. Hold down the key stroke for 5 seconds or so.

Actual behavior:

NVDA exits with the following in the log (see comment above). The entire log file is also attached. But note that it is very long. The synthesizer is still working though and some key strokes are still intercepted by the synthesizer.

Expected behavior:

NVDA should not exit.

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2019.1

Windows version:

Windows 10 1809 Update

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

MS Word 2010, MS Word 2016, MS Word 365.

Other questions

Does the issue still occur after restarting your PC?

yes

Have you tried any other versions of NVDA?

yes, the same issues in different versions of NVDA.
ONKYO.docx

[Adriani90]

INFO - core.main (19:03:14.434):
Exiting
DEBUG - core._terminate (19:03:14.434):
Terminating updateCheck
DEBUG - core._terminate (19:03:14.434):
Terminating watchdog
DEBUG - core._terminate (19:03:14.434):
Terminating global plugin handler
DEBUGWARNING - Python warning (19:03:14.434):
C:\Users\adria\AppData\Roaming\nvda\addons\ImageDescriber\globalPlugins\imageDescriber\__init__.py:52: wxPyDeprecationWarning: Call to deprecated item. Use Remove instead.
DEBUG - core._terminate (19:03:14.444):
Terminating gui
DEBUG - fileUtils.FaultTolerantFile (19:03:14.444):
C:\Users\adria\AppData\Roaming\nvda\nvda.ini8wy3jw.tmp
INFO - config.ConfigManager.save (19:03:14.483):
Base configuration saved
DEBUG - core._terminate (19:03:14.483):
Terminating treeInterceptorHandler
DEBUG - treeInterceptorHandler.killTreeInterceptor (19:03:14.493):
Killed treeInterceptor: <virtualBuffers.gecko_ia2.Gecko_ia2 object at 0x055458B0>
DEBUG - treeInterceptorHandler.killTreeInterceptor (19:03:14.493):
Killed treeInterceptor: <virtualBuffers.MSHTML.MSHTML object at 0x05266970>
DEBUG - core._terminate (19:03:14.493):
Terminating IAccessible support
DEBUG - core._terminate (19:03:14.493):
Terminating UIA support
DEBUGWARNING - _UIAHandler.UIAHandler.terminate (19:03:14.713):
Timeout or error while waiting for UIAHandler MTA thread
DEBUG - core._terminate (19:03:14.719):
Terminating winConsole support
DEBUG - core._terminate (19:03:14.719):
Terminating Java Access Bridge support
DEBUG - core._terminate (19:03:14.719):
Terminating app module handler
DEBUG - core._terminate (19:03:14.739):
Terminating NVDAHelper
DEBUG - core._terminate (19:03:14.813):
Terminating touchHandler
DEBUG - core._terminate (19:03:14.813):
Terminating keyboard handler
DEBUG - core._terminate (19:03:14.813):
Terminating mouseHandler
ERROR - stderr (19:03:14.813):
Exception in thread Thread-4:
Traceback (most recent call last):
  File "threading.pyc", line 801, in __bootstrap_inner
  File "threading.pyc", line 754, in run
  File "winInputHook.pyc", line 74, in hookThreadFunc
OSError: could not unregister key hook 66601
DEBUG - core._terminate (19:03:14.844):
Terminating inputCore
DEBUG - core._terminate (19:03:14.844):
Terminating brailleInput
DEBUG - core._terminate (19:03:14.844):
Terminating braille
DEBUG - core._terminate (19:03:14.844):
Terminating speech
DEBUG - core._terminate (19:03:14.844):
Terminating addonHandler
DEBUG - core.main (19:03:14.844):
core done
INFO - __main__ (19:03:15.144):
NVDA exit

[Adriani90]

Here is the entire log file. addons were disabled.
nvda-old.txt

[Brian1Gaff]

What I found interesting was attempting to load it into word 2003, it invoked the document conversion routine and the resulting file, is it german? Did not exhibit the problem, but was very sluggish of course as I do not think nvda is optimised for such an old version of Word. I could highlight loads of paras and the table etc, but as I say it was slow. Windoows 7 here.

[Adriani90]

Interesting, yes it is german.

[DrSooom]

This Word document contains 141 JPEG files. Disable "Editor revisions" and "Comments" in the Document Formatting Settings and try again.

[Brian1Gaff]

That would explain the laggy nature and probably why converting it to an earlier format worked, albeit slowly.

[Adriani90]

Disablind editors revisions etc does not solve this issue. Thanks for the suggestion though.

[Adriani90]

@feerrenrut I saw you assigned P3 to the duplicate issue, however I suggest, if possible, to set a higher priority for this. It is a really big impact when working with big documents, and it is a complete crash.
I also think this should improve already significantly if we exclude some document atributes from being detected when navigating by paragraph. For example spelling errors and gramatical errors could be excluded, as well as comment and editing revisions.
I didn' see a difference when disabling these in the document formating settings, but maybe NVDA tries to fetch them from the object model in MS Word anyway.
cc: @michaelDCurran

[rkingett]

This still happens in 2020.1 and 2019.3.1

[DrSooom]

Just for clarification: NVDA 2020.1 Beta 1 is currently the latest beta build and 2019.3.1 the latest stable build.

[feerrenrut]

@Adriani90 I should have given reasoning on that issue. I assigned P3 because the crash requires selecting a lot of text by holding ctrl+shift+down arrow for X seconds. This doesn't seem like a common use case, though I'm happy to reconsider, what are you trying to do?
Some possible workarounds: selecting all can be achieved with ctrl+a, does it still crash in this case? Can you use NVDA+F9 / NVDA+F10 to copy the text?

[rkingett]

For now, the best workaround is to use NVDA+F9 and NVDA+F10 but that sometimes crashes my beta. 2020.1 Beta 1, when selecting multiple paragraphs with that method. For me, hitting select all wouldn't work because I am a novelist and wouldn't want to select a 80,000 word document when I only need to select chapter 23 only.

[Adriani90]

@feerrenrut this is a very common use case, many people reported this actually in several mail lists.
Usually, in big documents, most people read the document paragraph by paragraph instead of line by line. For sighted people it works in the similar way when you do skim reading. In order to be efficient, you look at the paragraphs and this is also what we do when we select text. For example you want to select only one chapter from a paper or one section from a chapter. NVDA+f9 and NVDA+f10 crashes also, ctrl+a is a totally different thing and does not help as workaround in this case.
Speaking for my case, I face this problem very often at work and it interupts me while working on complex tasks. The selection is ofcourse gone after NVDA crashes because I have to start NVDA again and I have to apply the selection again from the beginning.
Selecting line by line takes many minutes and makes working with NVDA very inefficient in many cases.
If possible, I would ask here for a higher priority.
My understadning was that per definition, events which cause a direct crash in NVDA have higher priority.

[DrSooom]

Is it possible to limit the amount of spoken Unicode characters when selecting or moving paragraphs? In most kind of these cases it is totally enough just to hear the first – let's say – 50 Unicode characters to detect the correct paragraph. Reading the whole paragraph in these situations is in my opinion not really necessary. Well, but may somebody need this – therefore add a checkbox "Only speak the first 50 Unicode characters during selecting/moving paragraphs".

… Wait, I guess that isn't enough. Two text fields might be better: One for the amount of Unicode characters which should be spoken, and one which splits a paragraph into the "short and a large one, because only the large ones should be limited. Reason: News articles on the web could be read also paragraph by paragraph – and not by using SayAll. So in Firefox/Chrome/Edge it should not be limited, but in Microsoft Word or LibreOffice Writer – if the user needs this to correct/edit text. Configuration profiles could of course help here to manage this new function.

So, more brainstorming is welcome.

@rkingett and @Adriani90: Does this issue also occur on pressing Shift+PageDown or Shift+PageUp? I know that this isn't a suitable workaround, but if this is the case, we have to add these hotkeys as well to the limit function I mentioned before.

[rkingett]

No, it does not crash when pressing shift, and page up or down, or CTRL, Shift, page down. Neither the stable, 2019.3.1, nor beta, 2020.1, crash when using page down.

[Adriani90]

@DrSooom I would strongly suggest not to limit the unicode characters spoken because we then run into the issue that people don't know what they are selecting or what they are reading. It must be another way to avoid NVDA crashing without any significant limitations in the user experience.
As I proposed above, for example fetching revisions or spelling errors is not really needed when navigating paragraph by paragraph. Also things like reporting of sections or text columns is not needed here. These should be ignored when navigating paragraph by paragraph and this might already solve this issue.
People looking for revisions, spelling errors, sections, pages etc. would not use paragraph reading but rather quick navigation keys or line by line or page by page navigation.

[Adriani90]

However, it seems the document crashes also when using page up and page down for navigation. So this might need further investigation.

[Adriani90]

After further testing it seems page up and page down also together with ctrl+shift, is not reproducible in a reliable way. But ctrl+shift+down arrow is definitely causing a crash.

[Adriani90]

This is probably the most important part of the log here:

ERROR - stderr (19:03:14.813):
Exception in thread Thread-4:
Traceback (most recent call last):
  File "threading.pyc", line 801, in __bootstrap_inner
  File "threading.pyc", line 754, in run
  File "winInputHook.pyc", line 74, in hookThreadFunc
OSError: could not unregister key hook 66601
DEBUG - core._terminate (19:03:14.844):
Terminating inputCore
DEBUG - core._terminate (19:03:14.844):
Terminating brailleInput
DEBUG - core._terminate (19:03:14.844):
Terminating braille
DEBUG - core._terminate (19:03:14.844):
Terminating speech
DEBUG - core._terminate (19:03:14.844):
Terminating addonHandler
DEBUG - core.main (19:03:14.844):
core done
INFO - __main__ (19:03:15.144):
NVDA exit

However, the termination process might have started before unregistering this key hook. But there is nothing really useful in the log for the time before this.

[bhavyashah]

@feerrenrut I tend to agree with #9463 (comment) in that (a) navigation and selection by paragraph is common, and (b) any scenario where NVDA crashes warrants greater-than-usual priority. Thoughts appreciated.

[rkingett]

Could not agree more. IMO, this should be given more attention.

[Adriani90]

@michaelDCurran could you, if you have time, please look into this? At least for me this is a big problem. I am working very often with the ctrl+shift feature when selecting text in MS Word and in such complex documents, especially if there are multiple text columns, NVDA crashes and exits everytime. It would be really nice if this could get some more priority.

Currently I am on NVDA alpha-20572,124bb02f and Office 365, but I could reproduce this in older Office versions as well.

[rkingett]

It's worth noting this happens in Libro Office too.

[Adriani90]

Still occuring in NVDA alpha-20656,87eee7f4
after #11431 has been merged.

[michaelDCurran]

I am so far unable to reproduce this bug at all I'm sorry.
Can you confirm a few things for me please:

• Does it make a difference with or without a braille display?
• Does the document open in Protected View?
• What document view are you using in MS Word (print layout, draft etc)?
• is UI Automation support for MS Word disabled in NVDA?

Can I please see an entire log using latest NVDA master, from NVDA start to NVDA exit, with add-ons disabled, and log level set to debug, where you reproduce the issue. Please don't cut anything from the log, a part from hiding any file paths if you wish.
Note that the log you originally attached only started from where you first pressed control+shift+downArrow.

Perhaps I require the German proofing tools to be installed for MS Word. I shall also try that and report back.

[michaelDCurran]

Installing German proofing tools makes no difference for me. I can hold down control+shift+downArrow for many many seconds and NvDA never exits or freezes.
I'm assuming that German versionf of Windows act the same as English Windows when pressing control+shift+downArrow, in that it extends the selection down by one paragraph?
And NVDA in this case would report the text of the paragraph followed by 'selected'. Unless the paragraph was more than 500 characters and then NVDA would just report the number of characters selected.
Note that when NVDA does fetch this text, it just uses range.text (in the Word object model) and does not fetch any formatting, spelling information or other content.

[Adriani90]

@michaelDCurran thank you so much for your reply. Hmm it is indeed very strange that it does not reproduce for you. I have tested with a clean portable copy of NVDA, no addons. I have even disabled all kind of settings that could have an impact on performance in MS Word such as reporting of pages, document revisions etc. Still the crash occurs for me. See the complete log attached, the last lines of the file are most relevant I would say. It is strange that NVDA does not show the terminating process in the log file, it's just exiting without logging anything.
nvda-old.txt

[Adriani90]

Enabling UIA support for Microsoft Word seems to fix this issue.

[Adriani90]

Regarding the other points, I am not using a braille display so far, the document is not in protected view and the crash occurs in all view layouts. I tested in reading layout, web layout, print layout and also draft layout.

I'm assuming that German versionf of Windows act the same as English Windows when pressing control+shift+downArrow, in that it extends the selection down by one paragraph?
And NVDA in this case would report the text of the paragraph followed by 'selected'. Unless the paragraph was more than 500 characters and then NVDA would just report the number of characters selected.

To my knowledge your assumption is correct.

[Adriani90]

Here is a log from the current master, the same crash occurs.
nvda-old_master.txt

[michaelDCurran]

@Adriani90 Thank you for the new logs. I now can clearly see why a freeze is occurring. However, I am not sure why previous copies of NvDA were actually exiting by themselves... so I'm not entirely sure if we are seeing one or two issues here. I'm still not sure why on my machine I never see this, but I can certainly see why logically this would happen in the code.
A try build for you to test is coming in a few minutes.

[michaelDCurran]

Technical:
When we send keys from NVDA, we set a flag (global variable) to tell NVDA's keyHook to ignore (our) injected keys while we are sending, as our keyHook will run during sending the keys. As this can happen from multiple threads, we use a lock to protect this gobal variable.
But, there is a situation where the keyHook itself might send keys, which then causes the keyHook to run reentrantly. However, the lock is not reentrant and therefore the keyhook thread deadlocks itself on the lock, and the main thread also waits on the lock for ever.
Either: That lock should be a reentrant lock, and the context function which manages that global variable should detect if it is being called reentrantly (the global variable is already true) and do nothing but yield.
Or: we should not be calling KeyboardInputGesture.send at all in the winInputHook thread. Rather we should call keybd_event directly. The only time we do this in the winInputHook thread is to send the fake VKCode (0xff) to stop keyboard layout changes when certain modifiers are held down... such as control+shift.

[michaelDCurran]

Could people please test the following try build and report if the problem has been fixed:
https://ci.appveyor.com/api/buildjobs/fh6fsasmbra5ns88/artifacts/output%2Fnvda_snapshot_try-i9463-2-20673%2C4bbccf3e.exe

[michaelDCurran]

Just in case people saw the above comment before now, I have replaced the try build with a new one:
https://ci.appveyor.com/api/buildjobs/fh6fsasmbra5ns88/artifacts/output%2Fnvda_snapshot_try-i9463-2-20673%2C4bbccf3e.exe
Please test this one instead and let me know if the freeze / exit no longer occurs.

[Adriani90]

Thanks Mick for the quick follow up. I tested and it seems NVDA does not exit now automatically. However, I am not sure it is sellecting text because it just plays error sounds and does not report what's sellected. I get this error everytime when I press ctrl+shift+ arrow keys. I tested with the try build in your last comment.

ERROR - keyboardHandler.internal_keyDownEvent (20:45:29.454) - winInputHook (16160):
internal_keyDownEvent
Traceback (most recent call last):
  File "keyboardHandler.pyc", line 209, in internal_keyDownEvent
AttributeError: module 'winUser' has no attribute 'VK_NONE'

[rkingett]

I tried the second test build above, and I am getting the same result. See below.

ERROR - keyboardHandler.internal_keyDownEvent (20:45:29.454) - winInputHook (16160):
internal_keyDownEvent
Traceback (most recent call last):
File "keyboardHandler.pyc", line 209, in internal_keyDownEvent
AttributeError: module 'winUser' has no attribute 'VK_NONE'
—

[michaelDCurran]

Sorry about that. I forgot to commit one of the files I changed! a new try build coming very soon. This time I'll test the try build as well :)

[michaelDCurran]

Please test the following try build and report if the issue has been solved:
https://ci.appveyor.com/api/buildjobs/f9u8v9lyuxs7qab3/artifacts/output%2Fnvda_snapshot_try-i9463-2-20678%2Cc518d094.exe

[Adriani90]

Thank you for the try build. I have tested, and yes NVDA does not freeze or exit. But now NVDA does not report anything when I press ctrl+shift+arrow keys.
However, the text is correctly selected, I checked this by copying it to clipboard and pressing nvda+c (laptop layout)

[michaelDCurran]

This is proving quite tricky to fix. Thanks for continuing to test these.
Here is a new try build:
https://ci.appveyor.com/api/buildjobs/a0ly4oqypcxgym2h/artifacts/output%2Fnvda_snapshot_try-i9463-2-20691%2C265d3d4a.exe
Again, let me know how this works for you.

[rkingett]

This last snapshot version, above, seems to fix it for me. Is it fixed for anybody else?

[Adriani90]

The last try build seems to fix it Mick. Thank you very much for the work on this.

[michaelDCurran]

Could people please test another try build for me:
https://ci.appveyor.com/api/buildjobs/24jiit7t57wpw7j2/artifacts/output%2Fnvda_snapshot_try-i9463-3-20706%2C95f7c8a8.exe
This is a slightly different approach, which avoids a few more possibilities for freezing / exiting.
Technical:
this time, send the VK_NONE key from the main thread if the script did not send the gesture itself. Not only does this avoid the deadlock in the keyboard hook, but also ensures that we never deliberately cause the keyboard hook to be re-entrant (I.e. now we never send input from the hook at all) and we also avoid wx.yield from being called... which stops a wx assertion.

[Adriani90]

Thanks Mick, I've tested and it seems the last try build makes it even smoother. The performance is much better when selecting text with ctrl+shift+arrow keys, no matter how manc characters are in a paragraph.
NVDA even reacts faster than compared to pressing only down or up arrow key to navigate through the document. Is it possible to apply this change also for document navigation, i.e. by up and down arrow key or by quick navigation keys in browse mode? Or is this only possible for text selection commands?

[rkingett]

Just ad a chance to test the last build given above, and I think it is far better. Actually, could this apply to general document review navigation? This is much faster than the previous build when selecting multiple paragraphs.

[michaelDCurran]

The performance issues for control+shift+downArrow are different to those for general document navigation. In the case of control+shift+downArrow, the performance cost was having to work around a situation in Windows where if pressing control+shift, alt+shift or alt+windows by themselves with no main key, might perform an action such as changing the input language. I was able to come up with a work around that is much less performance costly.
Any performance issue with general document navigation (downArrow etc) in MS Word is instead to do with how much information we must fetch in order to report the line. Note that with control+shift+downArrow, we only fetch the basic text, and not any formatting information, thus downArrow would be slower. The fix for the current issue does not apply to general document navigation.

[michaelDCurran]

It seems that pr #11478 (which fixed this issue) has caused issue #11587 .
I have come up with a fix for that in pr #11597 and have done some testing of my own. But I'd greatly appreciate if people who originally experienced this issue could test the following try build:
https://ci.appveyor.com/api/buildjobs/91fwnw14dgaggcrs/artifacts/output%2Fnvda_snapshot_try-i11587-20924%2C0df222bd.exe

And confirm that holding down control+shift+downArrow in Microsoft Word is still working as expected. As we do want to get this new pr into NVDA 2020.3.

Thanks.

[rkingett]

It is still fixed for me. Not sure about others, though.