Attachment NonResponder.exe added by ianr on 2011-03-09 00:58
Description:

Comment 1 by jteh on 2011-03-09 01:19
NVDA depends on obtaining information from applications. Due to the way that accessibility in Windows works, if an application stops responding (freezes), queries for information from that application will also freeze, and in turn NVDA will freeze. Certain requests can be cancelled, so if we detect this situation, we cancel the request after 10 seconds or if the foreground window changes (e.g. you switched applications using alt+tab). Unfortunately, certain requests cannot be cancelled (without very nasty hacks), so in these cases, NVDA freezes until the application starts responding again. I experimented with some very evil code to try to work around these situations a while ago, but it has the potential to cause nasty problems. (In technical terms, the only way to get around this is to hook some pretty basic Windows API functions and override their behaviour.)

#1189 also addresses this issue, though it was originally specific to applications which freeze on exit, so I've closed it as a duplicate.

Comment 2 by ianr on 2011-03-10 16:51
I wonder if the 10 seconds time limit could be reduced to 5 without causing any problems, it would be ideal to get this as low as is reasonable to improve responsiveness.

I tested with JAWS and it stays responsive when I cause the test application to stop responding so they have obviously found a way to work around this.

If you are willing to take some time to document the experimental code you were working on I am interested in looking at it.

I believe that fixing this problem would make NVDA feel much more stable but I realize that overriding low level windows API functions is not something to be undertaken lightly.

None the less, I am still interested in seeing the experimental code and gaining a better understanding of how this could be solved.

Comment 3 by jteh (in reply to comment 2) on 2011-03-10 21:43
Replying to ianr:

I wonder if the 10 seconds time limit could be reduced to 5 without causing any problems, it would be ideal to get this as low as is reasonable to improve responsiveness.

There are times when the system is just legitimately slow due to load. If we reduce this, the problem is that it might kill off some legitimate calls. This causes real problems in, for example, MS Office, where if we fail to retrieve the native object model, everything falls over rather nastily.

I tested with JAWS and it stays responsive when I cause the test application to stop responding so they have obviously found a way to work around this.

Interesting. I've certainly seen cases where other screen readers freeze as well due to unresponsive applications (the application error dialog is a case that often seems to freeze), but each case is slightly different.

Note that most screen readers work more in-process than NVDA does, which means that their performance in other processes is sometimes unaffected by a freeze in one process. This may explain why JAWS seems to cope better here. This is an architectural difference; NVDA is primarily out-of-process and bringing the entire program in-process is not an option.

If you are willing to take some time to document the experimental code you were working on I am interested in looking at it.

There isn't really much to document. Basically, I hooked !SendMessage and !SendMessageTimeout for oleacc and UIAutomationCore. For !SendMessage, i redirect the call to !SendMessageTimeout and enforce a 1 second timeout. For !SendMessageTimeout, I ensure that the timeout can never be more than 2 seconds, which I do because Windows accessibility uses ridiculous timeouts like 20 seconds.

None the less, I am still interested in seeing the experimental code and gaining a better understanding of how this could be solved.

The code is in this branch: http://bzr.nvaccess.org/nvda/lessFreezing2
You can also view the changelog.
Note that this branch is pretty outdated now; I haven't synced it with main in some time.

Comment 4 by jteh on 2011-03-10 21:50
Btw, one of the big reasons I stopped working on this code is that UIA seems to call !GetComboBoxInfo (or its low level equivalent) on top level windows when you register for events, which happens at startup. This seems to freeze if you call it on an unresponsive window; we proved this in a separate test case. This is why we freeze at startup if there is an unresponsive application on systems with UIA. Unfortunately, this seems to go straight to a kernel call, so we probably can't override this in any useful way. Alas, this means we're stuck with this freeze.

Comment 5 by jteh on 2011-03-11 00:12
Merged main into lessFreezing2: changeset:lessFreezing2,3906.

Comment 6 by jteh on 2011-04-02 10:57
A completely different experimental approach to solving this problem: http://bzr.nvaccess.org/nvda/experimental/cancellableCalls/
At present, this is far from complete and broken in many areas.

Comment by jteh on 2011-05-26 22:19
(In #1528) Is this app free or paid? If paid, we're unfortunately not going to be able to debug this specific case.

Comment 8 by jteh on 2011-06-01 21:48
See also duplicate #1543.

Comment 9 by parham on 2011-06-02 05:10
The application mentioned in #1528 is free, however, the one in #1543 is not. There is still a way though: you could get Visual Web Developer (which is free), or Visual C# Express (which is also free).

Comment 10 by jteh on 2011-06-09 07:18
Changes:
Milestone changed from None to 2011.3

Comment 11 by jteh on 2011-08-29 00:23
We've abandoned the pure cancellableCalls approach for now and instead improved lessFreezing2, including borrowing some code from cancellableCalls.

As of now, snapshots are being generated for lessFreezing2. Anyone experiencing NVDA freezes in various situations should try lessFreezing2 snapshots and report. However, be aware that this is experimental code; the usual warnings apply.

Comment 13 by dwillemv on 2011-08-29 04:05
Where might I download a snapshot of less freezing2? I could not find it on the snapshots page.

Comment 14 by jteh on 2011-08-29 04:21
It's showing up fine for me. Try refreshing the page (and perhaps refreshing the iframe containing the table as well).

Comment 15 by jteh on 2011-09-05 10:34
lessFreezing2 merged in 7366dee. There will doubtless be more things to fix, but these should be filed as separate tickets.
Changes:
State: closed

Comment 16 by jteh on 2011-09-27 00:27
I discovered that until now, these fixes weren't working on Windows XP systems without the UI Automation Client API (part of the Platform Update). See #1817. This has just been fixed.