Conflict minHook 1.3.3 with UAC on Windows 7

[kvark128]

On Windows 7 32bit, after upgrading minHook to version 1.3.3 in the latest master builds, the User Account Control is not working correctly. Steps to reproduce:

1. Install the master build version 15256,feda37e3 or later.
2. Open the Start menu, type cmd in the search field and press control+shift+enter to run as administrator.
3. In the UAC dialog, press Yes button.
4. The UAC dialog is closed, but cmd.exe does not start. The consent.exe process appears in the task manager, which cannot be terminated. This does not always happen, but often. If the application starts, you can repeat from step 2. If in NVDA replace minHook.dll version 1.3.3 to 1.2.2, then the problem disappears.

[LeonarddeR]

Are you getting any error sounds from NVDA when this happens? If so, could you provide a log file?

[kvark128]

No, there are no errors in the log file.

[LeonarddeR]

In that case, it is likely that something goes wrong in the secure copy. I will fire up a Win7 x86 vm tomorrow in order to try to reproduce the problem.

[LeonarddeR]

I've tried to reproduce the issue at least ten times on a Windows 7 x86 vm, without luck. This was on next, though. Can you reproduce the issue with Next?

Are you familiar with updating the windows registry? You could find instructions on how to enable debugging on the logon screen in section 15.2. "System Wide Parameters" of the user guide. Keep in mind though that this will disable secure mode forNVDA on the logon screen.

[kvark128]

Yes, i see the same problem with next builds. After enabling serviceDebug in the registry, when consent.exe hangs, i have the following not very interesting output in c:\Windows\Temp\nvda.log: INFO - main (00:46:57.403): Starting NVDA INFO - core.main (00:46:57.552): Config dir: C:\Program Files\NVDA\systemConfig INFO - config.ConfigManager._loadConfig (00:46:57.552): Loading config: C:\Program Files\NVDA\systemConfig\nvda.ini WARNING - config.profileUpgrader.upgrade (00:46:57.562): Error saving configuration; probably read only file system INFO - core.main (00:46:57.582): NVDA version master-15338,3fec637f INFO - core.main (00:46:57.582): Using Windows version 6.1.7601 service pack 1 workstation INFO - core.main (00:46:57.582): Using Python version 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:22:17) [MSC v.1500 32 bit (Intel)] INFO - core.main (00:46:57.582): Using comtypes version 1.1.3 INFO - synthDrivers.espeak.SynthDriver.init (00:46:57.882): Using eSpeak NG version 1.49.1 dev INFO - synthDriverHandler.setSynth (00:46:57.963): Loaded synthDriver espeak INFO - core.main (00:46:57.963): Using wx version 3.0.2.0 msw (classic) INFO - brailleInput.initialize (00:46:57.963): Braille input initialized INFO - braille.initialize (00:46:57.963): Using liblouis version 3.5.0 INFO - braille.BrailleHandler.setDisplayByName (00:46:57.963): Loaded braille display driver noBraille, current display has 0 cells. WARNING - core.main (00:46:57.983): Java Access Bridge not available INFO - _UIAHandler.UIAHandler.MTAThreadFunc (00:46:57.983): UIAutomation: IUIAutomation

I also did dump memory for the hung process consent.exe, maybe it will help something: https://yadi.sk/d/VNKZDrqF3YBDJ9

[LeonarddeR]

Could you create another log this way, after setting nvda's log level to debug, saving your configuration and then applying your configuration to the secure screen config? Note that this will also log key presses, including possible passwords you enter. Strange enough, the log does not mention a shutdown of NVDA.

[kvark128]

Tried to install the release 2018.2.1, but also does not mention a shutdown of NVDA in this logfile. Log for master attached to this message. Interface messages in the log in russian. If necessary, i can change the language to english. nvda.log

[LeonarddeR]

@michaeldcurran, this sounds pretty serious. I'm not very familiar with the EOA code, but this minhook issue might force us to revert the update at some point.

[michaelDCurran]

When experiencing the issue, is it possible you had dictationBridge installed in NVDA?

I have experienced something like this with dictationBridge on UAC screens before.

But yes, if we can prove the issue goes away when downgrading minhook, then we must.

[kvark128]

I never installed dictationBridge. In the NVDA configuration on a secure desktop there are no installed addons. Disabling all addons in the user configuration does not solve the problem.

[LeonarddeR]

A last resort to test could be creating a try build that has debug loggging for NVDA Helper. Still, I'm afraid that won't tell us anything new. Actually, I've tried to create such a debug version once, but it did not properly log everything I expected it to.

[LeonarddeR]

I've created a try build that is equivalent to master, but it has NVDAHelper debug logging enabled. Could you please install this copy, than try to reproduce the issue and provide a debug log of the logon screen instance again?

[kvark128]

Done. nvda.log

[LeonarddeR]

@michaeldcurran: I'm too unfamiliar with the hooking process and EOA functionality to give advice here. How is a running secure screens copy of NVDA terminated exactly? Shouldn't it unhook somehow?

@kvark128: The issue you're having is that the command console does not open. however, what happens if you do another attempt? Does NVDA work correctly on the UAC screens in that case, and are you able to start cmd after it once failed to?

[kvark128]

Yes, re-run cmd is successful. But they must be done another way. For example, if i try to run cmd from the start menu and it hangs, the start menu can no longer be used, when press Windows key, the NVDA reports "start menu unavailable". After that i can run cmd from Total Commander, unless of course he also does not hang.

[lukaszgo1]

I'm able to reproduce it almost 100% of the time under Win 7 pro x64 with the following STR.

1. Secure your user account with the password or alternatively create second user the important thing is that NVDA need to speak something on the login screen.
2. Set NVDA to start automatically on your user account.
3. create a text file on your desktop
4. restart your computer
5. Wait for NVDA on the login screen and login into Windows.
6. after NVDA starts move to desktop and open the text file in notepad the file needs to be saved opening notepad from the run box will not be sufficient.
7. With focus in the notepad edit box press Windows key
8. type cmd
9. Press CTRL+SHIFT+enter on cmd.exe
10. When UAC windows appear activate yes button with alt+y without tabbing or navigating the window.
11. If cmd opens close it move focus back to notepad and perform again steps 7 to 10

[LeonarddeR]

@lukaszgo1: Are you able to reproduce this with NVDA 2018.2.1? If not, we should probably revert the Minhook update.

[LeonarddeR]

I can still not reproduce this. However, I'm getting an invalid handle error in the log of the user copy of NVDA 100% of the time I perform these steps.

[tspivey]

I also have this problem under Windows 10 1803 x64.

[zstanecic]

Hi tyler, It's odd, cause i cannot reproduce it on my windows 10 1803.17134 on whatever version it is r

[lukaszgo1]

leonardder wrote

Are you able to reproduce this with NVDA 2018.2.1? If not, we should probably revert the Minhook > update.

I can not reproduce it with NVDA 2018.2.1 I've made another discovery. I have a second machine with Windows 7 Home premium x64 and i was not able to reproduce this bug there. After comparing software installed on this computers the only difference was, that machine affected by this problem has JAWS 2018 installed. I've installed JAWS on my other machine and now i'm able to reproduce the bug on it. JAWS is of course disabled on a login screen and is set not to start for the user account. I've also unchecked it in the ease of access center but it didn't made a difference.

[kvark128]

I have two machines with Windows 7 32bit, the first is installed JAWS 2018, the second JAWS is not installed. The problem is reproduced on both machines.

[LeonarddeR]

I've been able to reproduce it now on two Windows 10 1803 machines. here is a try build that incorporates Minhook 1.2.2 again. Would anyone of you be able to try whether this solves the issue?

[kvark128]

The problem remained. It seems to include minHook 1.3.3.

[LeonarddeR]

Ah yuck, I shared the wrong url, I"m sorry for that.

This build really should contain 1.2.2

[kvark128]

Yes, this build solves the issue. Everything works correctly.

[lukaszgo1]

I can also confirm, that this build fixes it for me.

[josephsl]

Hi, as a follow-up, I propose investigating which Minhook release caused this, similar to what we did with Boost back in 2012. Thanks.

From: Łukasz Golonka notifications@github.com Sent: Thursday, June 28, 2018 1:47 AM To: nvaccess/nvda nvda@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [nvaccess/nvda] Conflict minHook 1.3.3 with UAC on Windows 7 (#8420)

I can also confirm, that this build fixes it for me.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/8420#issuecomment-400960624 , or mute the thread https://github.com/notifications/unsubscribe-auth/AHgLkEFvfEf_P2X5s3kG7HajZrFVQ7u8ks5uBJfxgaJpZM4UtxbZ .

[LeonarddeR]

For reference, Microsoft open sourced detours, their own hooking library. I think hooking is pretty stable at the moment, but minhook seems abandoned for a long time now and we don't seem to be able to update safely.

If we ever need to update minhook, it could be considered to switch to detours, as it has a very long history and is considered much more tested than minhook.

[LeonarddeR]

Had a quick look at the detours API reference. Unfortunately it has no ability to unhook every function that has been hooked, that has to be done manually.