Closing command prompt windows with object nav or mouse causes nvda to exit

[nvaccessAuto]

Reported by briang1 on 2011-07-21 15:58
Launch a command prompt. Use nvda keypad 4 to go to the close button. Use nvda/keypad enter to close the command prompt. Nvda will exit along with the prompt.
I understand that this is due to closing the window in this manner of with a mouse causes windows to close all associated running programs, including nvda.
I did not see a warning about this in the manual, but this might well be me!
Maybe it should be mentioned. Why does not closing it in other ways cause the same problem though?

Very short log pasted for ref only.
INFO - nvda (11:54:55):
Starting NVDA
INFO - core.main (11:54:55):
Config dir: C:\Documents and Settings\brian\Application Data\nvda
DEBUG - core.main (11:54:55):
setting language to Windows
INFO - core.main (11:54:55):
NVDA version 2011.2-4568
INFO - core.main (11:54:55):
Using Windows version sys.getwindowsversion(major=5, minor=1, build=2600, platform=2, service_pack='Service Pack 3')
INFO - core.main (11:54:55):
Using Python version 2.7.2 (default, Jun 12 2011, 15:08:59) v.1500 32 bit (Intel)
INFO - core.main (11:54:55):
Using comtypes version 0.6.2
DEBUG - core.main (11:54:55):
Creating wx application instance
DEBUG - core.main (11:54:55):
Speech Dictionary processing
DEBUG - speechDictHandler.SpeechDict.load (11:54:55):
Loading speech dictionary 'C:\Documents and Settings\brian\Application Data\nvda\speechDicts\default.dic'...
DEBUG - speechDictHandler.SpeechDict.load (11:54:55):
15 loaded records.
DEBUG - speechDictHandler.SpeechDict.load (11:54:55):
Loading speech dictionary 'builtin.dic'...
DEBUG - speechDictHandler.SpeechDict.load (11:54:55):
3 loaded records.
DEBUG - core.main (11:54:55):
Initializing speech
INFO - synthDrivers.espeak.SynthDriver.init (11:54:55):
Using eSpeak version 1.45.03 22.Mar.11
DEBUG - speechDictHandler.SpeechDict.load (11:54:56):
Loading speech dictionary 'C:\Documents and Settings\brian\Application Data\nvda\speechDicts\espeak-english.dic'...
DEBUG - speechDictHandler.SpeechDict.load (11:54:56):
file 'C:\Documents and Settings\brian\Application Data\nvda\speechDicts\espeak-english.dic' not found.
INFO - synthDriverHandler.setSynth (11:54:56):
Loaded synthDriver espeak
INFO - core.main (11:54:56):
Using wx version 2.8.11.0 (msw-unicode)
DEBUG - core.main (11:54:56):
Initializing braille
INFO - braille.initialize (11:54:56):
Using liblouis version 2.3.0
INFO - braille.BrailleHandler.setDisplayByName (11:54:56):
Loaded braille display driver noBraille
DEBUG - core.main (11:54:56):
Initializing NVDAHelper
DEBUG - core.main (11:54:56):
Initializing displayModel
DEBUG - core.main (11:54:56):
Initializing GUI
DEBUG - core.main (11:54:56):
Initializing appModule Handler
DEBUG - core.main (11:54:56):
initializing Java Access Bridge support
DEBUG - core.main (11:54:56):
Initializing winConsole support
DEBUG - core.main (11:54:56):
Initializing UIA support
WARNING - core.main (11:54:56):
UIA not available
DEBUG - core.main (11:54:56):
Initializing IAccessible support
DEBUG - core.main (11:54:56):
Initializing input core
DEBUGWARNING - inputCore.InputManager.loadLocaleGestureMap (11:54:56):
No locale gesture map for language en
DEBUGWARNING - inputCore.InputManager.loadUserGestureMap (11:54:56):
No user gesture map
DEBUG - core.main (11:54:56):
Initializing keyboard handler
DEBUG - core.main (11:54:56):
initializing mouse handler
DEBUG - core.main (11:54:56):
Initializing global plugin handler
DEBUG - core.main (11:54:56):
starting core pump
DEBUG - core.CorePump.init (11:54:56):
Core pump starting
DEBUG - core.main (11:54:56):
Initializing watchdog
INFO - core.main (11:54:56):
NVDA initialized
DEBUG - core.main (11:54:56):
entering wx application main loop
IO - speech.speak (11:54:56):
Speaking Prompt terminal'
IO - speech.speak (11:54:56):
Speaking and Settings\brian> '
IO - inputCore.InputManager.executeGesture (11:55:04):
Input: kb(desktop):NVDA+numpad4
IO - speech.speak (11:55:04):
Speaking button Closes the window 5 of 5'
IO - inputCore.InputManager.executeGesture (11:55:18):
Input: kb(desktop):NVDA+numpadEnter
IO - speech.speak (11:55:18):
Speaking [u'Press']

Its in all versions, development and release that I've tried back to the last two.And that is that.
Blocking #4239, #5343

[nvaccessAuto]

Comment 1 by briang1 on 2011-07-21 16:04
Changes:
Changed title from "Closing command prompt windows with object nav or mouse ocauses nvda to exit" to "Closing command prompt windows with object nav or mouse causes nvda to exit"

[nvaccessAuto]

Comment 2 by jteh on 2011-07-21 22:07
When you close it in other ways, NVDA is either notified first or the focus changes before it closes, both of which allow NVDA to detach from the console before it actually closes. Neither of those things happens if you press the Close button at the top of the window.

[nvaccessAuto]

Comment 3 by mdcurran on 2011-07-21 23:54
According to MSDN we can support ctrl_close_event in our routine handler, returning True which will disable the default handler which calls ExitProcess. However, testing shows that this does not seem to work at all, which I think I remember this also back when we first started writing the console code.

[nvaccessAuto]

Comment 4 by briang1 on 2011-07-22 13:43
Well, maybe its that nvda has other links to the command process that thwart your approach?

Seems odd to me that it can not only log the command itself but also that its about to say press.... before it gets terminated.

[jcsteh]

For the record, I tried detaching from the console in the close handler, having two handlers and detaching in the one that gets called first, and having two handlers and removing the second in the first. All of these failed, with the last one causing a crash with an access violation.

[dkager]

Are you even supposed to be able to get out of this killing spree? The idea seems to be that you get a little time to clean up, then right when the handler returns the process 'terminates', either through ExitProcess() if the handler returned FALSE or in some unspecified way otherwise. The loophole of freeing the console when you receive Ctrl+Close may not work on purpose.

[jcsteh]

No, you're not supposed to get out of it. That doesn't change the fact that we absolutely do want to get out of it. :)

[bhavyashah]

@jcsteh From #1682 (comment), I take It that this issue persists at present, right?

[jcsteh]

Yes, this still persists.

[derekriemer]

@jcsteh kind of disgusting, but could we inject into the functions in windows that close the console and detect this, to tell NVDA to detach before the console murders us?

[jcsteh]

Maybe, but I doubt it. As noted in #1682 (comment), detaching from the console within the close handler doesn't help. So, this would have to be done before the close handler, but I'm guessing we don't get notified before the kill unless there's a close handler. I think there's probably a better chance of hooking ExitProcess and making it a no-op for this case, but that is pretty risky and we'd have to be pretty tight about the detection of console exits. Someone would have to do some pretty serious Windows debugging to figure this out.

[Adriani90]

I can still reproduce this issue on Windows 10 with NVDA 2018.2.1.

cc: @feerrenrut

[derekriemer]

I don't think we can fix this. We should long term maybe use UIA.

[feerrenrut]

Having not looked into this at all, I'm hesitant to comment. I don't know what causes NVDA to become "associated" with the command prompt, but if we are not able to "disassociate", then another approach might be to use a proxy process which can safely be killed without affecting the rest of NVDA.

[jcsteh]

@feerrenrut commented on Jul 30, 2018, 4:46 PM GMT+10:

I don't know what causes NVDA to become "associated" with the command prompt,

The only way to read a console programmatically is to "attach" to it, as if we actually wanted to act as a shell or an application. Once you attach to a console, you become beholden to that console's killing whims.

but if we are not able to "disassociate", then another approach might be to use a proxy process which can safely be killed without affecting the rest of NVDA.

That would work, yes. It'd just be tedious to implement the IPC, which is why it hasn't been done yet. :)

Long-term, using UIA might be an option, but only once the console UIA implementation isn't a steaming pile of excrement and only in versions of Windows 10 without said excrement.

[codeofdusk]

Once #9771 is merged, this issue will be resolved on Windows 10 version 1803 and later, as NVDA does not need to attach to consoles when UIA is available. However, the issue is still present on Windows LTSC/Server 2016 (Windows 10 1607), which will remain supported for many years to come. While it may be possible to separate some of the in-process legacy console code into its own process (which would be safe to kill off, therefore not breaking NVDA), doing so would likely degrade performance. Since the issue is resolved for the latest three Windows versions, I vote to close it.

[feerrenrut]

I don't think this should be closed, there are certainly avenues for fixing this, I'd be very surprised if we couldn't get round trip latency below 20ms for IPC.

Given that Windows Server 2016 support "Extended support end date" is 12th Jan 2027, this will be affecting people for a long time to come.

[Brian1Gaff]

I think we have had this bug ever since the start of nvda, yes I go back that far, as long as its noted as a restriction on operating systems prior to the ones mentioned, its probably not worth trying to do anything after all this time. Brian [email protected] Sent via blueyonder. Please address personal E-mail to:- [email protected], putting 'Brian Gaff' in the display name field. Newsgroup monitored: alt.comp.blind-users -----

[TechHorseG]

I inadvertently started a duplicate of this issue recently,and was advised to write here.

It is still the case that in 20H2 closing a running Batch File or Command Prompt via a taskkill command while the console window is in focus, will terminate NVDA also.

This is a bit of a headache for me, as I want to create scripts to auto-close running Batch Files under certain circumstances, and can't easily guarantee that they won't be in focus at the time of their closure.

Clicking the Close button on a Command Prompt also had this consequence when I tried it.

So, just wishing to express an interest in there being a solve for this issue. Thanks.

[codeofdusk]

This is solved (experimentally) in the UIA implementation of Windows Console support. Enable "use UI Automation to access Windows Console when available" in NVDA advanced prefs.

This will be enabled by default in an upcoming Windows release after a bit more polish, see microsoft/terminal#7000 for updates.

[TechHorseG]

Oh that is good to see! I gave that setting a try and it seems to be doing the job of keeping NVDA alive. Great.

One thing though, you mentioned the need for a bit of polish and I did notice something. So I was wondering if there is any established NVDA thread for discussing NVDA's behaviour with this new setting?

once again, I'm so glad we are approaching a full solve :)

[Adriani90]

@TechHorseG how is NVDA last alpha behaving now in this situation? Is it still having this issue when not using UIA in Windows Consoles?

[codeofdusk]

Behaviour here is unchanged: this issue is resolved with UIA enabled, which is set to be the default in a future release of conhost (#10964). This new release will probably be the inbox build either in a cumulative update on top of 11 or I'd think part of SV2 at the latest. However, given plans to ship conhost "out-of-box" there are no guarantees about where the update will be available. Cc @DHowett.

[josephsl]

Hi, for those keeping an eye on Win11 development: I’m guessing sv2 = nickel/copper/zinc dev semesters (way too early to tell). Thanks.