Skip to content
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

Open
nvaccessAuto opened this issue Sep 29, 2012 · 5 comments
Open

Gracefully handle VirtualAllocEx failure for sysListView32 #2693

nvaccessAuto opened this issue Sep 29, 2012 · 5 comments
Labels
bug p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority

Comments

@nvaccessAuto
Copy link

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.

@nvaccessAuto
Copy link
Author

Comment 1 by jteh on 2012-09-29 22:56
It's very difficult to know what to do when this occurs, as NVDA depends on this working to get some info. We can gracefully return nothing, but the info will still be completely inaccessible. Also, I think this should be handled on a case by case basis because handling this everywhere is a lot of work and because this shouldn't fail in many cases; e.g. scintilla and akelEdit.
Changes:
Changed title from "VirtualAllocEx API can fail e.g. due to process protection, so exceptions thrown by it should be handled properly" to "Gracefully handle VirtualAllocEx failure for sysListView32"

@bhavyashah
Copy link

@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.

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Oct 11, 2017

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.

@feerrenrut feerrenrut added the p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority label Oct 23, 2017
@Adriani90
Copy link
Collaborator

@LeonarddeR can you still see this issue in NVDA last alpha?

@LeonarddeR
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug p4 https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
Projects
None yet
Development

No branches or pull requests

5 participants