Closed AAClause closed 3 years ago
Probably microsoft/terminal#6986
I encountered something similar today, but I'm not sure if the underlying cause is the same because my keyboard and NVDA locked up so badly that I was forced to do a hard reboot, losing unsaved files in the process.
I was interacting with the console via WSL 1 and the command was just a curl which did not produce a lot of output. Unfortunately, NVDA just stopped speaking and most keyboard commands wouldn't work so I couldn't recover at all. This occured right after I pressed enter to execute the command so I'm fairly sure this is a problem with NVDA.
Inbox console recently received some UIA fixes (notably microsoft/terminal#7530). Could you please re-test on the latest insider dev build (or download OpenConsole.exe
from the terminal repo by extracting it from the msix)?
@codeofdusk thanks for the information. Unfortunately my WSL is currently broken due to https://github.com/microsoft/WSL/issues/5902 I'll retry ASAP.
I suspect that microsoft/terminal#7677 will fix many of the remaining crashes.
Could users experiencing this issue please test the OpenConsole.exe in this build with UIA console enabled and report back? On my system, I'm running OpenConsole as the default (follow the steps in microsoft/terminal#1817, and note that you'll also need to take ownership of conhost.exe in advanced security properties before adding/changing permissions), but you can also just run this build for testing while leaving your default console untouched.
Also CC @carlos-zamora (Microsoft dev), @DHowett (Microsoft dev lead), and @simon818 (user who reported some crashes to me directly).
cc: @derekriemer, @josephsl
I get the following traceback with NVDA version alpha-21096,c61eb42d and Windows 10 Insider (64-bit) build 20226.1000 when I open a file with nano (addons disabled):
Traceback (most recent call last):
File "eventHandler.pyc", line 220, in executeEvent
File "eventHandler.pyc", line 96, in __init__
File "eventHandler.pyc", line 105, in next
File "NVDAObjects\behaviors.pyc", line 197, in event_caret
File "editableText.pyc", line 348, in detectPossibleSelectionChange
File "editableText.pyc", line 355, in _updateSelectionAnchor
File "NVDAObjects\UIA\__init__.pyc", line 776, in compareEndPoints
File "comtypesMonkeyPatches.pyc", line 26, in __call__
_ctypes.COMError: (-2147467259, 'Unspecified error', (None, None, None, 0, None))
I'm assuming that NVDA/the console continues working normally though? If so, this will be fixed in #11039.
@codeofdusk yes apart this traceback, no problem.
Assuming the crash has been resolved, could this issue please be closed?
I've just reproduced the original issue (one of my instance of cmd crashed completely during a compilation through a SSH connection). So the issue doesn't seem fully solved yet. However I used UIA in Windows Consoles intensely these last days and it's the first crash. (alpha-21126,7df2560a, Windows 10 Insider (64-bit) build 20231.1000)
That's not good. CC @carlos-zamora.
@andre9642 Could you please respond to this issue? The Windows bug deadline is fast approaching and Microsoft would like to fix any remaining crash bugs. Thanks.
@codeofdusk unfortunately the bug is very rarely (only occurred 2 times last week with an intensive usage of cmd). So I'm unable to reproduce it on request. I remember that I used SSH, Emacs and nano during these 'cmd.exe' instances. Besides these instances were open for several hours (at least 5). Sorry, I can't give more detail for now.
OK, so you were using the cmd included with Windows? Or my test build?
Yes, the cmd included with Windows. I'll try with your test build soon.
OK, thanks for letting me know.
Inbox is a little behind, there were a few more crashes solved since the latest console in Windows, so I suspect it has been fixed. It's just a matter of waiting for you to receive the fix in a future build.
@codeofdusk Thanks for this precision. I'm sorry for not testing OpenConsole before. So I consider that this issue is solved. Thanks for your great job with @carlos-zamora! :-)
Windows insider build 20236 contains many additional crash fixes!
I can't find anything related to the crashes in regards to Console in the change log of 20236?
On 10/15/2020 2:17 AM, Bill Dengler wrote:
Windows insider build 20236 https://blogs.windows.com/windows-insider/2020/10/14/announcing-windows-10-insider-preview-build-20236/ contains many additional crash fixes!
β You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/11428#issuecomment-708651253, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQWBM6BZRXBHDCJ7QAVNLLSKYE7PANCNFSM4PIPK3EA.
@akash07k if we put every team's changes in the changelog, people would stop reading after the first 500! I integrated these changes from our open-source version myself. They're definitely there! π
Yes bro, you are absolutely right. So, is there any way/path where we can read all the change log of every time/component of every latest insider windows release?
@akash07k if we put every team's changes in the changelog, people would stop reading after the first 500! I integrated these changes from our open-source version myself. They're definitely there! π
Hi, Iβm thinking not, as engineers need to balance between publishing really technical information that is passed amongst team members, among multiple teams, and the organization as a whole versus highlighting very high impact changes that will be (and can be) noticed by new users or seasoned Insiders. Besides, there are hundreds of Git branches used inside Windows organization at Microsoft, along with some of them having features on or off, all of which will be merged into a single rsprerelease branch every day at Microsoft. Add it to the fact that more branches exist to service six versions of Windows10 (th1 for 1507, rs1release for 1607, rs4release for 1803, rs5release for 1809, 19h1release for 190x, vbrelease for 20Hx), some of which contribute to WIP builds in one way or another, and you get the idea. Thanks.
From: Akash Kakkar notifications@github.com Sent: Wednesday, October 14, 2020 11:05 PM To: nvaccess/nvda nvda@noreply.github.com Cc: Joseph Lee joseph.lee22590@gmail.com; Mention mention@noreply.github.com Subject: Re: [nvaccess/nvda] UIA in Console and WSL: crashes in some contexts (#11428)
Yes bro, you are absolutely right. So, is there any way/path where we can read all the change log of every time/component of every latest insider windows release?
@akash07k https://github.com/akash07k if we put every team's changes in the changelog, people would stop reading after the first 500! I integrated these changes from our open-source version myself. They're definitely there! π
β You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/11428#issuecomment-708919702 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4AXEDKI5IJBBOFAH5LOGTSK2GKHANCNFSM4PIPK3EA .
Thanks Joseph, You're right. Publishing every change log can be quite complicated
On 10/15/20, Joseph Lee notifications@github.com wrote:
Hi, Iβm thinking not, as engineers need to balance between publishing really technical information that is passed amongst team members, among multiple teams, and the organization as a whole versus highlighting very high impact changes that will be (and can be) noticed by new users or seasoned Insiders. Besides, there are hundreds of Git branches used inside Windows organization at Microsoft, along with some of them having features on or off, all of which will be merged into a single rsprerelease branch every day at Microsoft. Add it to the fact that more branches exist to service six versions of Windows10 (th1 for 1507, rs1release for 1607, rs4release for 1803, rs5release for 1809, 19h1release for 190x, vbrelease for 20Hx), some of which contribute to WIP builds in one way or another, and you get the idea. Thanks.
From: Akash Kakkar notifications@github.com
Sent: Wednesday, October 14, 2020 11:05 PM
To: nvaccess/nvda nvda@noreply.github.com
Cc: Joseph Lee joseph.lee22590@gmail.com; Mention mention@noreply.github.com
Subject: Re: [nvaccess/nvda] UIA in Console and WSL: crashes in some contexts (#11428)
Yes bro, you are absolutely right.
So, is there any way/path where we can read all the change log of every time/component of every latest insider windows release?
@akash07k https://github.com/akash07k if we put every team's changes in the changelog, people would stop reading after the first 500! I integrated these changes from our open-source version myself. They're definitely there! π
β
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/11428#issuecomment-708919702 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4AXEDKI5IJBBOFAH5LOGTSK2GKHANCNFSM4PIPK3EA .
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/nvaccess/nvda/issues/11428#issuecomment-708924486
@codeofdusk Today I was able to reproduce the crash 2 times. The second time, I enabled debug mode with UIA events. Not tested with add-ons disabled. I used cmd directly (not openconsole). Here's the log after pressing enter (my command was emacs <file>
):
(NVDA alpha-21196,4840e5fb, Windows 10, build 20236)
This is really odd. Can you please test again with add-ons disabled?
(I can run emacs just fine in OpenConsole).
OK, I'll try this during this weekend. The bug is random. Before the crash I was able open Emacs about 10 times with no issue.
I can reproduce the issue with Openconsole. Occurred just now (add-ons enabled).
I apologize -- I miscounted the fixes that went into 20136 and osme of the crash fixes are stuck in a later build.
@Andre9642 This means the crashes have been fixed, but the fixes still aren't available to you. They should come out in another build or two (probably by the end of November) but @DHowett would know more.
Also, sometimes I get the following error:
ERROR - comtypes._comobject.call_without_this (15:15:19.553) - Dummy-2 (27800):
Exception in IUIAutomationEventHandler.HandleAutomationEvent implementation:
Traceback (most recent call last):
File "comtypes\_comobject.pyc", line 147, in call_without_this
File "_UIAHandler.pyc", line 447, in IUIAutomationEventHandler_HandleAutomationEvent
File "comtypesMonkeyPatches.pyc", line 26, in __call__
_ctypes.COMError: (-2147220991, 'An event was unable to invoke any of the subscribers', (None, None, None, 0, None))
Build 20241 was recently released with additional fixes (confirmed offline with @DHowett).
@Andre9642 Could you please retest on the new build and report back on the crash?
Unfortunately, the issue is not solved for me. I am able to reproduce it in a few minutes easily now.
Here's what I Did during this NVDA session until the crash:
I kept this (full) log if you need more details.
I can now reproduce the crash, however only with my physical Braille display connected (i.e. not with Braille viewer running).
Your log suggests that the console is crashing in moveEndPointByRange
: line 789 of uia/__init__.py
reads:
self._rangeObj.MoveEndpointByRange(src,other._rangeObj,target)
Since this crash happens during a switch to/from the alt buffer, I suspect it is an uncaught fail fast in conhost, but see the following lines in the console source code (starting at around line 677 of types/UiaTextRangeBase.cpp
:
IFACEMETHODIMP UiaTextRangeBase::MoveEndpointByRange(_In_ TextPatternRangeEndpoint endpoint,
_In_ ITextRangeProvider* pTargetRange,
_In_ TextPatternRangeEndpoint targetEndpoint) noexcept
try
{
_pData->LockConsole();
auto Unlock = wil::scope_exit([&]() noexcept {
_pData->UnlockConsole();
});
const UiaTextRangeBase* range = static_cast<UiaTextRangeBase*>(pTargetRange);
if (range == nullptr)
{
return E_INVALIDARG;
}
// TODO GH#5406: create a different UIA parent object for each TextBuffer
// This is a temporary solution to comparing two UTRs from different TextBuffers
// Ensure both endpoints fit in the current buffer.
const auto bufferSize = _pData->GetTextBuffer().GetSize();
const auto mine = GetEndpoint(endpoint);
const auto other = range->GetEndpoint(targetEndpoint);
if (!bufferSize.IsInBounds(mine, true) || !bufferSize.IsInBounds(other, true))
{
return E_FAIL;
}
So that must not be it...
@carlos-zamora or @DHowett, Is there a way I can collect a stack trace to see where in the console code this is breaking? (since it only crashes with a display connected and not when using the Braille viewer, I'd be willing to let you remotely connect to my machine for data gathering/debugging purposes if necessary).
Can you please try this build and let me know if the crash is fixed?
I can still reproduce the issue. However it seems to happen after a longer period. I was able to open/exit nano ~40-50 times before crash (based on 4 tests).
I cannot reproduce the issue with the linked build, even when running/exiting Nano over 100 times.
Just for consistency in setup, could you please run the following in the Python console (nvda+control+z) and put the output here?
{k: v for k,v in config.conf["documentFormatting"].items()}
>>> {k: v for k,v in config.conf["documentFormatting"].items()}
{'reportTableCellCoords': True, 'reportClickable': True, 'reportTableHeaders': True, 'reportTables': True, 'autoLanguageSwitching': 'False', 'reportArticles': True, 'reportFontAttributes': True, 'reportSuperscriptsAndSubscripts': True, 'reportColor': False, 'reportEmphasis': True, 'reportStyle': False, 'reportLinks': True, 'reportBorderStyle': False, 'reportBorderColor': False, 'reportAlignment': True, 'reportLineIndentationWithTones': False, 'reportParagraphIndentation': True, 'reportLineSpacing': True, 'reportLineNumber': False, 'detectFormatAfterCursor': False, 'reportLineIndentation': False, 'reportFontName': False, 'reportFontSize': False, 'reportRevisions': True, 'reportHighlight': True, 'reportSpellingErrors': True, 'reportPage': True, 'includeLayoutTables': False, 'reportGraphics': True, 'reportComments': True, 'reportLists': True, 'reportHeadings': True, 'reportBlockQuotes': True, 'reportGroupings': True, 'reportLandmarks': True, 'reportFrames': True}
I've just created a portable version of NVDA (without my configuration) and I'm unable to reproduce the issue (running/exiting Nano over 100 times too).
I've copied your exact config, using:
With a Braille display connected, in that build of UIA console, I still can't reproduce the crash running over 100 times. So it must not be formatting settings.
Could you please paste the contents of your nvda.ini file in %appdata%\nvda?
Sorry, I forgot to enable "Use UI Automation to access the Windows Console when available" on my fresh copy of NVDA. I can reproduce the issue with no personal customization.
Also during a test, I received a serious freeze (about 30 seconds)...
For reference, here's my minimal configuration (on this copy):
schemaVersion = 4
[update]
autoCheck = True
startupNotification = True
allowUsageStats = False
askedAllowUsageStats = True
[general]
language = en
saveConfigurationOnExit = True
askToExit = True
playStartAndExitSounds = False
loggingLevel = DEBUG
showWelcomeDialogAtStartup = False
[development]
enableScratchpadDir = False
[upgrade]
[speech]
synth = espeak
outputDevice = Mappeur de sons Microsoft
[[oneCore]]
voice = HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Speech_OneCore\Voices\Tokens\MSTTS_V110_frFR_HortenseM
volume = 100
[[espeak]]
voice = fr
variant = max
rate = 70
pitch = 40
inflection = 75
volume = 100
[braille]
[[noBraille]]
[[baum]]
[keyboard]
keyboardLayout = laptop
useCapsLockAsNVDAModifierKey = True
speakTypedCharacters = False
[vision]
[[NVDAHighlighter]]
highlightFocus = False
highlightNavigator = False
highlightBrowseMode = False
[[screenCurtain]]
[UIA]
useInMSWordWhenAvailable = True
winConsoleImplementation = UIA
[debugLog]
UIA = True
OK, please try the following:
%localappdata%\CrashDumps
and send the most recent .dmp file for OpenConsole.
Also going to CC @miniksa on this issue.
I'm not familiar with dmp files and I don't know if can contain sensitive data. So I prefer to avoid publicly sharing this. Sent to @codeofdusk in DM.
Windows 10 Insider 21301.1000, NVDA alpha-21685,90dd4e9a: I'm no longer able to reproduce the crash. Closing.
Steps to reproduce:
Unfortunately I don't have a precise scenario. The bug is random but it sometimes occurs when I want to edit a file (with nano for instance).
Actual behavior:
The following traceback is raised in the log and WSL/cmd sometimes crash completely (window is closed):
Expected behavior:
No such crash
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
alpha-20601,3a9484fb
Windows version:
10 Insider (64-bit) build 20175.1000
Name and version of other software in use when reproducing the issue:
WSL
Other information about your system:
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.
Yes, the bug is present since UIA was introduced in Windows Console. I don't usually use UIA in Windows Console because I can't accept such bugs, I've just retested it.
If addons are disabled, is your problem still occuring?
Yes
Did you try to run the COM registry fixing tool in NVDA menu / tools?
Yes
CC @codeofdusk