Browse mode is not available in some electron apps running on Windows 11 ARM #14397
Labels
feature/browse-mode
feature
p4
https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
platform/Windows11
Issues specific to Windows 11
triaged
Has been triaged, issue is waiting for implementation.
Milestone
Comments
|
Hi, Can you report the results of:
If it says something other than "AMD64" for the app architecture, chances are that this is an emulation compatible (Arm64EC) application with a mixture of x64 and ARM64 code included. CC @michaelDCurran, do you think we should update our building logic to support injecting code into AMD64/Arm64EC processes in Windows 11 on ARM? Thanks. |
|
@josephsl Results from 1password: 1password module is loaded. 1Password.exe is currently running. focus.appModule.appArchitecture: ARM64 Results from the RIM app: Remote Incident Manager.exe is currently running. focus.appModule.appArchitecture: ARM64 |
|
Looking at the devInfo output for 1Password I found the following: appModule: <'1password' (appName '1password', process ID 4760) at address 80feef0> |
|
Yes, we definitely want to support injecting into AMD64 / ARM64EC
processes if we can.
The quickest fix here is to change NVDAHelper.py to start an
nvdaHelperRemoteLoader process for both AMD64 and ARM64 on ARM.
Currently it only starts an ARM64 nvdaHelperRemoteLoader process. This
change will then allow injecting into AMD64 processes on ARM.
As for ARM64EC: just a guess, but I'm pretty sure that starting an
nvdaHelperRemoteLoader process for AMD64, and therefore registering the
needed AMD64 injection winEvents, will also cause us to automatically be
also injected into ARM64EC processes for free, as they are fully
compatible with AMD64. However, for performance reasons we could also
provide ARM64EC builds of our injection DLLs, and use them on Windows 11
for when registering in nvdaHelperRemoteLoader AMD64. Which would
provide greater performance on AMD64 and ARM64EC processes.
However, there is no need, and in deed it would be detrimental to,
provide / run a nvdaHelprerRemoteLoader specific for ARM64EC at the same
time as running an nvdaHelperRemoteLoader for AMD64, as this will cause
us to inject two lots of DLLs into both of those process types at the
same time.
Somewhat related: the appArchitecture property on appModules currently
reports ARM64 for AMD64 processes on ARM which is incorrect. This is
because we only detect WOW64 (I.e. 32 bit emulation). On Windows 11, we
need to instead call GetProcessInformation, giving it the
ProcessMachineTypeInfo constant.
|
|
Hi, As for GetProcessInformation function call, I think it would be best to split this into a separate issue/PR pair (wish we can get Microsoft ARM development kit to test this scenario more fully). Thanks. |
|
Hi, Possible solution based on Mick's comment:
Ideally someone using a Windows 11 on ARM device should come up with a pull request. Thanks. |
|
NV Access has just purchased a 2023 Windows Dev Kit which means we are
now again in a position to be able to test on ARM. So, I'll look into
these changes in the near future.
|
|
I don't feel like I have the skills to send a PR for something like this at this point but I'm happy to test with my Windows ARM VM. I'm running NVDA from source so I can checkout any PR as soon as it become available.
|
|
Hi, thanks. As a starting point, can you test #14404 and see if an AMD64 app is recognized as an AMD64 app on Windows 11 on ARM please? That can provide something for us to look at once a pull request is created to resolve this issue. Thanks.
|
|
Yes, I'm planning on taking on all of this project.
And as I mentioned before, On ARM, AMD64 apps are incorrectly reported
as ARM64 in NVDA. Thus we need to fix AppModule.appArchitecture, as well
as fix the logic with nvdaHelperRemoteLoader.
|
feerrenrut
added
feature
triaged
seanbudd
added
the
p4
6 tasks
6 tasks
seanbudd
added a commit
that referenced
this issue
Dec 21, 2022
Closes #14439 Follow-up to #14397 Follow-up to #14403 Summary of the issue: winVersion.WinVersion class should define processor architecture property to record machine architecture for the current Windows installation. Description of user facing changes At NVDA startup, processor architecture will be logged as part of Windows information. Description of development approach Add "processorArchitecture" property to winVersion.WinVersion class to record machine architecture (currently x86 (32-bit) AMD64 (x64), ARM64). From getWinVer() function, this value will be fetched via Python's platform.machine() function, which itself looks up processor architecture from environment variables. This means NVDA can read the new property instead of consulting environment variables every time it wishes to check machine architecture. Also, added a unit test to see if the processor architecture recorded is indeed the one Windows says. Commits: * winVersion.WinVersion: define processor architecture property. Re #14439. Define 'processorArchitecture' property in WinVersion class to store machine arcthiecture for the Windows installation (x86/32-bit, AMD64, ARM64). This is useful in detecting 64-bit systems and different architectures for use for log output, 64-bit versus 32-bit differences, and testing and debugging. * WinVersion.repr: print processor architecture if defined. Re #14439. Print processor architecture for the Windows installation as part of Windows version output. * winVersion.getWinVer: obtain processor architecture via platform.machine() function. Re #14439. Python's platform module provides platform.machine() function, returning the processor architecture for the system. If Windows is detected, it internally retrieves PROCESSOR_ARCHITEW6432 and PROCESSOR_ARCHITECTURE environment variabls, in that order so it can detect WoW64 (such as x86 program running on an x64 processor). Because winVersion.getWinVer() function caches the current Windows installation, processor architecture string is always available and cached as part of the resulting WinVersion object. The practical implication is that NVDA no longer needs to consult environment variables every time it wants to detect processor architecture as the result is already known at program startup. * Unit tets: add processor architecture test and update copyright header. Re #14439. Add winVersion.getWinVer().processorArchitecture test to see if what it says matches processor architecture (and WoW64 version) environment variable. Python's platform.machine() function is not used because that function consults environment variables itself. * update changes Co-authored-by: Sean Budd <sean@nvaccess.org>
seanbudd
added a commit
that referenced
this issue
Dec 21, 2022
…ows 11 on ARM via kernel32.dll::GetProcessInformation (#14404) Closes #14403 Stems from #14397 ### Summary of the issue: In Windows 11 on ARM, AMD64 apps are seen as ARM64 apps. ### Description of user facing changes Entering "focus.appModule.appArchitecture" in Python Console will say "AMD64" if focused on AMD64 application. ### Description of development approach In app module handler: 1. Defined a process information structure with three attributes: process machine (unsigned short), res0 (double word), machine attributes (double word. 2. Added 0xAA64 to represent ARM64 applications in app architecture property. 3. Refined app architecture property in AppModule class to call kernel32.dll::GetProcessInformation on Windows 11 21H2 (build 22000) or later, with WoW64 detection reserved for Windows 10 and earlier. 4. If GetProcessInformation fails (returns 0), report "unknown" as app architecture to prepare to handle cases where an app (perhaps hosted or an ARM64EC) may report wrong architecture information. 5. Added type information to app architecture property (return type: str). This should inspire efforts to add type information to app module handler odule and classes (later). Commits: * appModuleHandler.AppModule: define process information structure for use when detecting various ap architectures in Windows 11. Re #14403. In Windows 11 on ARM, 64-bit x86 (AMD64) apps are identified as ARM64 when it should say AMD64, traced to a flaw in AppModule.appArchitecture property that relied on WoW64 detection. As part of resolving this, define a process machine info structure to be used in the refined app architecture property getter. * AppModule.appArchitecture: call kernel32::GetProcessInformation to obtain app architecture in Windows 11. Re #14403. Rather than relying on WoW64 detection, call kernel32.dll::GetProcessInformation in Windows 11 (21H2 build 22000 and later) to obtain app architecture. This uses a constant defined in process information class enumeration to obtain machine info (9). The WoW64 method is used if this is Windows 10 or earlier. * AppModule.appArchitecture: recognize 0xAA64 as ARM64 machine type. Re #14403 * AppModule.appArchitecture: winKernel -> ctypes.windll for consistency. Re #14403 * AppModule.appArchitecture: add type information (return type: str). Re #14403 * appModuleHandler.AppModule: handle kernel32.dll::GetProcessInformation returning 0 (error). Re #14403. Comment from Mick Curran (NV Access): GetProcessInformation may say '0' (error) sometimes, therefore treat the app in question has targeting 'unknown' architecture. * App module handler: refine get app module from NVDA object function to set process handle to a valid one if it is 0. Re #14403. Comment from ick Curran (NV Access): GetProcessInformation fials for some apps because process handle is 0 but the handle reported by NVDA object is valid. Therefore, after obtaining app module based on object process Id, see if process handle for the app is 0, and if so, replace process handle with that of the one reported by NVDA object. Also added type information for getAppModuleFromNVDAObject function. * App module handler: catch atribute error of obj.processHandle is undefined. Re #14403. When running unit tests, a placeholder NVDA object is created with process handle undefined. Therefore catch attribute error and move on. * update changes Co-authored-by: Sean Budd <sean@nvaccess.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have observed this problem with the 64 version of 1Password 8, the RIM app by Pneuma solutions and the version of Slack that can be obtained from the Microsoft store running on a virtual machine with Windows 11 ARM. The problem does not occur with the 32 bits version of Slack, the ARM64 version of Visual Studio code or Teams. All the apps work as expected with Narrator. Executing the command focus.devInfo in the Python Console while focus is inside any of the non-working apps shows the IAccessible2 properties related to the object with focus.
Steps to reproduce:
Actual behavior:
Nothing happens. The following gets added to the lock when the electron app receives focus:
DEBUGWARNING - virtualBuffers.VirtualBuffer.prepare (18:55:41.302) - MainThread (4072):
appModule has no binding handle to injected code, can't prepare virtualBuffer yet.
Expected behavior:
NVDA can switch between focus and browse mode.
NVDA logs, crash dumps and other attachments:
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
2022.3.2
Windows version:
Edition Windows 11 Pro
Version 22H2
OS build 22621.819
Experience Windows Feature Experience Pack 1000.22636.1000.0
Name and version of other software in use when reproducing the issue:
N/a
Other information about your system:
Windows is running on a Parallels VM
Other questions
Does the issue still occur after restarting your computer?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
No
If NVDA add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Yes
The text was updated successfully, but these errors were encountered: