search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.12k stars 638 forks source link

error in nvda when a message gains focus in outlook #17246

Closed fernando-jose-silva closed 1 week ago

fernando-jose-silva commented 1 month ago

Steps to reproduce:

On a machine where I have Outlook installed, when I open a message box in Outlook, and there is a message receiving focus, an nvda error appears.

Errors in 'nvda_slave.exe'

x

The logfile 'D:\Users\fernando.silva.LARAMARA\AppData\Roaming\nvda_slave.log' could not be opened: [Errno 13] Permission denied: 'D:\Users\fernando.silva.LARAMARA\/ pp .* ata\Roaming\nvda_slave.log'

OK Sorry for the way I copied the error, but at this point NVDA becomes completely inactive. I couldn't copy the error with the narrator. I had to use Seeing a i to take a picture of the computer screen and copy the identified text. The file referenced in the error does not exist.

Actual behavior:

nvda is completely frozen, does not read anything, does not execute a single command.

Expected behavior:

The error does not occur. If the error occurs, nvda should not be completely frozen. I have not noticed this error on any other screen. After closing the error, it is displayed again. After that, everything works correctly until Outlook is closed and reopened.

NVDA logs, crash dumps and other attachments:

System configuration

NVDA installed/portable/running from source:

instaled

NVDA version:

nvda.exe, NVDA alpha-34198,67f6cb99

Windows version:

10.0.19045.4957

Name and version of other software in use when reproducing the issue:

outlook 16.0.5461.1001

Other information about your system:

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 log outlook.txt

Adriani90 commented 1 month ago

cc: @michaelDCurran, @seanbudd, @gerald-hartig for triaging. I saw this error also from time to time, it might be something related to NVDA running without admin privileges on a Windows user account that is not an admin which most usual in corporate environments.

Adriani90 commented 1 month ago

Or there might be partition restrictions and NVDA cannot write its log to the partition...

starfrosch commented 1 month ago

We have the same reproducable issue here with NVDA 24.3.1, Windows 10 22H2, only user rights with roaming profiles and Outlook 365 Semi-Annual Relase. It does not occur with Windows 11 23H2. It only occurs on a Windows 10 22H2 patched with 2024-10 .net, .net security updates and cumulative updates.

Start NVDA...Start Outlook 365...the Error Message appears...NVDA stops reading...Press Enter confirm the Error Message...the Error Message appears second...Press Enter to confirm...now it works.

michaelDCurran commented 1 month ago

It is very likely this is a recent bug in Windows 10 where when a UIAccess process such as NVDA, launchers a second process (E.g. nvda_slave.exe) it does not correctly inherit the needed permissions. This bug is known to Microsoft and we are working with them to find a solution.

Adriani90 commented 1 month ago

Closing as duplicate of #11805.

CyrilleB79 commented 1 month ago

@Adriani90, given that:

I'd say that it's more logical to keep this issue opened and close #11805 as duplicate instead. Or even close #11805 without the duplicate label since these may be two different issues given that they were not reported the same time and with the same frequency.

I'll let you proceed, i.e. reopen this one and close #11805, if you agree.

Adriani90 commented 1 month ago

The old one contains valuable comments on technical side, we need feedback on that one from NV Access on that one before reopening this duplicate. Microsoft is also tagged on the old one, so I would keep this closed in favor of 11805.Von meinem iPhone gesendetAm 21.10.2024 um 16:01 schrieb Cyrille Bougot @.***>: @Adriani90, given that:

The issue has been reported much more frequently recently

11805 was closed for a long time and had only been reopened recently

The current issue has been triaged, given a priority (p1) and labeled by NV Access whereas #11805 has no label at all (no triage, no priority, etc.)

I'd say that it's more logical to keep this issue opened and close #11805 as duplicate instead. Or even close #11805 without the duplicate label since these may be two different issues given that they were not reported the same time and with the same frequency. I'll let you proceed, i.e. reopen this one and close #11805, if you agree.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

michaelDCurran commented 1 month ago

NV access would like to keep this issue open as it is a little more specific than #11805. The older issue more generally talks about nvda_slave.exe not being able to write a log file. But this current issue has been identified to be specifically related to a security permission bug in windows 10. We should keep both open please.

CyrilleB79 commented 1 month ago

@michaelDCurran, while you are working with Microsoft to find a solution, what is the best workaround? This issue is being reported on various lists for some days now.

alexstine commented 1 month ago

I worked for two separate corporations with the same exact environments down to the same Windows 10 build versions. Same hardware as well. Local user account, non-admin. At corporation X, everything worked fine no matter which program I used. Microsoft Word, Outlook, Excel, PowerPoint, and Teams. At corporation Y, eventually the choice was made to simply give NVDA users local admin accounts because no solution could ever be found. One tech suggested that maybe there was a difference in the way Windows sandbox was used but it's far out of my knowledge area. Anyone know if JAWS has the same issue? Would be worth investigating what's up with NVDA if not. In theory, one would assume this would break Narrator as well.

Adriani90 commented 1 month ago

Narator and Jaws do not have this problem. Von meinem iPhone gesendetAm 23.10.2024 um 06:13 schrieb Alex Stine @.***>: I worked for two separate corporations with the same exact environments down to the same Windows 10 build versions. Same hardware as well. Local user account, non-admin. At corporation X, everything worked fine no matter which program I used. Microsoft Word, Outlook, Excel, PowerPoint, and Teams. At corporation Y, eventually the choice was made to simply give NVDA users local admin accounts because no solution could ever be found. One tech suggested that maybe there was a difference in the way Windows sandbox was used but it's far out of my knowledge area. Anyone know if JAWS has the same issue? Would be worth investigating what's up with NVDA if not. In theory, one would assume this would break Narrator as well.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

starfrosch commented 4 weeks ago

Can we have an update for this issue? Are you making any progress in fixing it?

michaelDCurran commented 3 weeks ago

This is definitely a high-impact issue and we are certainly looking into any possible workarounds. However, the core issue is that Microsoft has made a significant change to security permissions in Windows 10 which we, and another AT have depended upon for some time. We will provide further progress updates when we have them.

michaelDCurran commented 3 weeks ago

Unfortunately After much testing on Windows 10 22h2, with all available updates applied, testing with NVDA 2024.4 and latest Alpha, I am unable to reproduce the issue when using Outlook. I also tested both being a member of administrators and not a member of administrators with no difference. So far, it simply looks like that on certain systems (for reasons not understood) nvda_slave.exe when started as a child process of NVDA, is getting a low integrity level, which causes it to fail to do ... something ... which intern causes it to try to write the log file, which fails due to it being a low integrity level. There must be some particular Windows policy, or security software on these machines. At very least, we need a way of detecting this scenario, and avoiding calling nvda_slave.exe at all. As there is no current way for us to be able to change py2exe from trying to write nvda_slave.log, as it happens too early in nvda_slave.exe execution. If anyone affected by this could please share what security software or anti-virus software they have, that would be very useful.

Adriani90 commented 3 weeks ago

I am on Windows 10 22 H2 uild 19045 5011, NVDA 2024.2, Outlook 2016. I cannot reproduce this one particularly, but #11805. That related issue is reproducible since 2 weeks every day, and following software has been updated recently:

This is on a Lenovo laptop, Lenovo system updates have been also performed on 15.10.2024, roughly the date where the issue started to reproduce every day for me.

fernando-jose-silva commented 3 weeks ago

on the computer where this problem occurs and the antivirus in use is bit defender thank you

starfrosch commented 2 weeks ago

We have no signs, that the virus scanner is the problem. We use Win 10 22H2 Pro (Patch level October) with Endpoint Protection (Microsoft Defender) and can reproduce the problem on several machines. When we use Win 11 23H2 (Patch level October) with Endpoint Protection (Microsoft Defender) with exact the same Group Policy settings, we don't have the problem

My guess is, that it is roaming profile in combination with Win 10 22H2 Pro patch level october related.

starfrosch commented 2 weeks ago

@michaelDCurran, while you are working with Microsoft to find a solution, what is the best workaround? This issue is being reported on various lists for some days now.

Our workarounds are

Adriani90 commented 2 weeks ago

Hmm very strange, the issue disappeared on my side at least. Exactly the same environment as described in https://github.com/nvaccess/nvda/issues/17246#issuecomment-2443719304. No system , software or Windows updates. I start to think this is a policy driven issue blocking something in the roaming user config or temp folder. Our admins at work regularly adjust the user and group policies and other security related settings but I never get to know what they exactly change.

Adriani90 commented 2 weeks ago

@starfrosch did you try to collect a network trace to see whether there are any issues from that side? Do you use Microsoft exchange server in MS Outlook?

starfrosch commented 2 weeks ago

@starfrosch did you try to collect a network trace to see whether there are any issues from that side? Do you use Microsoft exchange server in MS Outlook?

We don't have time for further debugging. We use Exchange Online (365) in Outlook 365.

starfrosch commented 2 weeks ago

Hmm very strange, the issue disappeared on my side at least. Exactly the same environment as described in #17246 (comment). No system , software or Windows updates. I start to think this is a policy driven issue blocking something in the roaming user config or temp folder. Our admins at work regularly adjust the user and group policies and other security related settings but I never get to know what they exactly change.

Our issue disappeard too, but without policy change (GPO). There where several updates (Firefox, iTunes) and the highly suspected solution is "Security Intelligence Update for Microsoft Defender Antivirus 1.4.21.148.0 (KB2267602) that solved the problem. Can someone reproduce and confirm? Or is this kind of IT magic :)

michaelDCurran commented 1 week ago

Microsoft believes that this issue was caused by kb5044273: https://support.microsoft.com/en-us/topic/october-8-2024-kb5044273-os-builds-19044-5011-and-19045-5011-a07551f8-e20d-4fd4-87f3-01145a3cd494 This KB has now been reverted. As it looks like the issue has gone away for some or all people on this issue, I'm closing.