UIA in Console and WSL: crashes in some contexts #11428
Comments
|
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 |
|
@codeofdusk thanks for the information. Unfortunately my WSL is currently broken due to microsoft/WSL#5902 |
|
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): |
|
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. |
|
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). |
|
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
<#11428 (comment)>,
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.
|
|
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 rs_prerelease branch every day at Microsoft. Add it to the fact that more branches exist to service six versions of Windows10 (th1_* for 1507, rs1_release_* for 1607, rs4_release_* for 1803, rs5_release_* for 1809, 19h1_release_* for 190x, vb_release_* for 20Hx), some of which contribute to WIP builds in one way or another, and you get the idea. Thanks.
From: Akash Kakkar <[email protected]>
Sent: Wednesday, October 14, 2020 11:05 PM
To: nvaccess/nvda <[email protected]>
Cc: Joseph Lee <[email protected]>; Mention <[email protected]>
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 <#11428 (comment)> , 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 ***@***.***> 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 rs_prerelease branch every day at
Microsoft. Add it to the fact that more branches exist to service six
versions of Windows10 (th1_* for 1507, rs1_release_* for 1607, rs4_release_*
for 1803, rs5_release_* for 1809, 19h1_release_* for 190x, vb_release_* for
20Hx), some of which contribute to WIP builds in one way or another, and you
get the idea. Thanks.
From: Akash Kakkar ***@***.***>
Sent: Wednesday, October 14, 2020 11:05 PM
To: nvaccess/nvda ***@***.***>
Cc: Joseph Lee ***@***.***>; Mention
***@***.***>
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
<#11428 (comment)> , 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:
#11428 (comment)
|
|
@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 Log (excerpt)(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: |
|
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. Log (snippets)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 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 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). Log (snippets) |
|
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()} |
|
|
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: d = {'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}
for k, v in d.items():
config.conf["documentFormatting"][k] = vWith 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? |
ghost
pushed a commit
to microsoft/terminal
that referenced
this issue
Oct 27, 2020
In nvaccess/nvda#11428 (comment), Andre9642 reported a Conhost crash when switching to/from the alt buffer a few times with a Braille display connected. Upon further investigation, @carlos-zamora and I discovered that the FailFast was in `GetText`: more checks similar to #7677 were needed for this case. Tested with NVDA using a [Focus](https://www.freedomscientific.com/products/blindness/focus40brailledisplay/) Braille display. Improves nvaccess/nvda#11428
DHowett
pushed a commit
to microsoft/terminal
that referenced
this issue
Oct 28, 2020
In nvaccess/nvda#11428 (comment), Andre9642 reported a Conhost crash when switching to/from the alt buffer a few times with a Braille display connected. Upon further investigation, @carlos-zamora and I discovered that the FailFast was in `GetText`: more checks similar to #7677 were needed for this case. Tested with NVDA using a [Focus](https://www.freedomscientific.com/products/blindness/focus40brailledisplay/) Braille display. Improves nvaccess/nvda#11428 (cherry picked from commit 60437b8)
|
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)... Log extractFor reference, here's my minimal configuration (on this copy): |
|
OK, please try the following:
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
The text was updated successfully, but these errors were encountered: