Reported by brandon15 on 2015-10-15 01:32
NVDA doesn't always focus the search box correctly in the start menu when first opening NVDA.
It seems to freeze for a few seconds, then randomly it places me in the tiles on the start screen, causing me to have to press left arrow to get back to the menu portion, then if I up arrow I can't get to the search box.
Pressing escape, to exit the menu, then opening it again, lands me in the search box. By this point, however, attempting to do a search causes the search results to not be read automatically. This also causes notifications to not read automatically either, requiring at least 1 restart of NVDA, if not more in some cases, to finally get it working.
Steps to reproduce:
1. Open a program like Windows Media Player, or Firefox or any desktop program.
2. Exit NVDA.
3. Restart it and you will notice that you land in what it says is the task bar.
4. Press alt+tab to get to the running programs and focus the program you were last in.
5. Press the windows key.
6. At this point you may notice a major (about 5 to 10 second delay) before it even recognizes that you pressed the windows key, and by that time, it may say pane, or start apps, list, list.
7. Try to find the search box located just above your account picture. You will notice that you can't up arrow to it.
8. Press escape to exit the menu.
9. Press the windows key again and you should hear "Cortana window. Search box edit, blank."
10. Type in a search result. NVDA seems not to read the results automatically as it should be.
Note that, in order to see this behavior you may have to attempt this multiple times. It always happens after updating to a new snapshot of NVDA.
After restarting NVDA, going to the last program I was in and pressing the windows key, NVDA should recognize the press of the windows key immediately and place me in the search box, and it should read the results automatically.
This is a very frustrating issue.
Also note, this sometimes happens where it has the delay when opening the start menu, but sometimes the search results still read. It all happens at a random point.
Thank you very much for your time and I look forward to any assistance you are willing to provide.
Comment 1 by brandon15 on 2015-10-15 01:35
The log file is too big to attach. How can I provide the log?
Comment 2 by jteh on 2015-10-15 02:01
I've certainly seen this issue, though I can't reproduce it as often as you seem to be able to. As far as I can tell, the Windows Search UI is actually crashing or at least failing for some reason. I haven't been able to figure out any further details yet.
Comment 3 by brandon15 on 2015-10-15 10:57
In some testing I've previously done, I've never seen this issue with Narrator.
If the search UI does crash, is it possible that NVDA could be doing this?
Comment 4 by jteh on 2015-10-15 11:03
It's unlikely, but not impossible. More likely is that NVDA legitimately queries something that Narrator doesn't and Search UI doesn't handle it correctly. Still, it's interesting to know that you can't reproduce this with Narrator. That is going to make this much harder to track down/report. :(
Comment 5 by brandon15 on 2015-10-15 11:14
Because it said my log file was too big I couldn't attach it, but I do have a log where, when I pressed the Windows key, it says "Trying to recover from freeze".
I can paste the log in here if you want, but the ticket system said it was too big to attach.
Comment 6 by jteh on 2015-10-15 11:21
I've seen the warning you're talking about. It's just telling us that Search UI is refusing to respond to our queries (probably because it froze), but it doesn't tell us any more than that unfortunately.
Comment 7 by brandon15 on 2015-10-15 17:55
I am on Windows 10 preview 10565.
I tested this both with my external monitor on and off, and it seemeto happen only when the monitor was off.
I turned off the monitor by pressing the button on the monitor itself, not from within Windows. Could this have anything to do with it? The reason I ask is that whenever the monitor was off I could almost always reproduce the issue, whereas when it was on I couldn't reproduce it at all.
Comment 9 by mdcurran on 2015-11-01 22:37
In the end, it was found to be a flaw in nvdaHelperRemote:
When setting up a new inprocThreadMgr thread, the thread waits on a mutex to guarentee that only one of these threads runs at any given time. However, the application's UI thread (where the initial injection winevent came from) waits until this mgr thread is initialized. But, if an old thmgrThread is currently terminating, that old mgrThread at some stage tries to send a window message to the UI thread (specifically to terminate IAccessible2 support). Therefore we end up in a deadlock. This also causes UIAHasServersideProvider (called from NVDA itself) to block.
The main reason why we see this deadlock so frequently in the searchUI is because the searchUI process is suspended when it is not on screen. However, Windows does not bother unloading DLLs or breaking rpc connections while suspended. Therefore, if the process suspends, you then switch copies of NVDA, once the process resumes, rpc breaks, a winEvent is fired which injects the new nvdaHelperRemote, it waits on the old mgr thread to terminate... deadlock.
The tempoary fix will be to not enable IAccessible2 support at all for suspendable (modern app) processes.
Eventually we will want to rewrite nvdaHelperRemote to not deadlock.
Comment 10 by Michael Curran <mick@... on 2015-11-01 23:07
In commit 5b80ee2:
Disable IAccessible2 support in NVDAHelperRemote if the process is suspendable (a modern app). Stops a deadlock after switching copies of NVDA and then bringing up searchUI on Windows 10. Fixes #5417
Comment 11 by jteh on 2015-11-01 23:14
Milestone changed from None to 2015.4
Comment 12 by brandon15 on 2015-11-02 15:40
I just updated to the latest next snapshot from master to next, so I'm on the latest next now.
When I opened start, there was a long delay like before, then I heard:
start window, start apps list, cortana.
Has this also been corrected after opening Skype? For example when I open Skype from the run box before searching from start, it makes search results and notifications not read as well.
Comment 13 by mdcurran (in reply to comment 12) on 2015-11-02 20:02
Replying to brandon15:
As the fix was made in the termination code for NVDAHelper, you'll only see an improvement when switching from a copy of NVDA that already has the fix. As you switched from one that did not have the fix to one that did, you will still see the freeze.
Comment 14 by brandon15 on 2015-11-02 20:18
That makes sense.
My next question is, when I first start NVDA, I had this problem in the NVDA that had the freeze where when I loaded skype from the run box by pressing windows+r, after opening Skype, but before using the search box caused search results not to read.
Steps to reproduce:
1. Press windows+r, and type in Skype.
2. When Skype opens, minimize it to the system tray (I do this by having keep skype on taskbar when signed in, option unchecked in Skype options).
3. Do a search from the start menu. Does it still read results for you? I'm on Skype version 7.12.
Disable IAccessible2 support in NVDAHelperRemote if the process is su…
…spendable (a modern app). Stops a deadlock after switching copies of NVDA and then bringing up searchUI on Windows 10. Fixes #5417