New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gracefully handle VirtualAllocEx failure for sysListView32 #2693
Comments
Comment 1 by jteh on 2012-09-29 22:56 |
@jcsteh wrote in #2693 (comment) "We can gracefully return nothing, but the info will still be completely inaccessible." Does this quote imply a cantfix, or is it a less desirable solution we must settle for? Also, since Jamie specifies in the same comment that this issue will require being addressed on a case-by-case basis, may we label this ticket as app-specific? Lastly, we might want to investigate the commonness of the VirtualAllocEx API, frequency of instances in which it fails, in order to properly evaluate the larger impact of this grassroot cause as a whole. |
I can reproduce this problem when I run a management console under a different user, except for that it reports an invalid handle message. Interesting enough, other screen readers, including JAWS, do not seem to suffer from this problem. |
@LeonarddeR can you still see this issue in NVDA last alpha? |
I have changed my workflow and therefore I'm no longer required nor able to impersonate MMC under a different user. I'm however pretty sure that the UIA bridge suffers from the same issues. |
Reported by Palacee_hun on 2012-09-29 14:51
I've noticed this when scanning some files with Eset NOD32 Antivirus. I initiated the scan via context menu. The scan went flawlessly, then the scan results dialog popped up. I tabbed to read the results, and after the first Tab press I heard the NVDA error sound. After examining the log, I saw that VirtualAllocEx produced a Windows error code 5, that is access denied. The API was called from NVDAObjects.IAccessible.SysListView32.getListGroupInfo method.
There are certain processes that do not let other processes access their address space in certain ways or at all. This is quite common for security software, like NOD32 av. VirtualAllocEx won't work with such processes. NVDA uses this API at some places to facilitate a mechanism for retrieving information from the given process for screen reading purposes. This triggers Windows errors with protected processes, that are currently not handled properly.
I note here that the accessibility problems of NOD32 that I have ticketed earlier, are partly due to its self protection mechanisms.
The text was updated successfully, but these errors were encountered: