Comment 1 by brandon15 on 2015-10-15 01:35
Hi,

The log file is too big to attach. How can I provide the log?

Thanks,

Brandon

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
Hello,

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?

Thanks,

Brandon

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
Hello,

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.

Thanks,

Brandon

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
Hello,

1. I am on Windows 10 preview 10565.
2. 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.

Thanks,

Brandon

Comment 9 by mdcurran on 2015-11-01 22:37
In the end, it was found to be a flaw in nvdaHelperRemote:
Technical:
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
Changes:
State: closed

Comment 11 by jteh on 2015-11-01 23:14
Changes:
Milestone changed from None to 2015.4

Comment 12 by brandon15 on 2015-11-02 15:40
Hello,

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.

Thanks,

Brandon

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
Hello,

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.

Thanks,

Brandon