other apps may crash or cause errors when an NVDA installation is updated #7563
Steps to reproduce:
The apps should not crash.
One or more of the apps crash.
Windows version: 10.0.16278 64-bit
We forget to unhookWinEvent in NVDAHelperRemote
NVDAHelperRemote injects into applications with foreground and focus winEvents. In inprocMgrThreadFunc, it then registers another winEvent limited to that process (inproc_winEventCallback) that listens for all possible winEvents. On termination, the injection winEvent is unregistered, but the process-specific winEvent is not. This leaves NVDAHelperRemote.dll in the process for ever. It will also respond to winEvents even though nvdaHelperRemote is terminated which may cause instability or a crash. It is necessary that inproc_winEventCallback be unregistered before inprocMgrThreadFunc exits.
Accidentally execute invalid memory
It is possible to accidentally cause Windows to execute incorrect memory in an in-context winEvent hook and thereby crash the injected process, when using a valid dll and a valid executable function pointer from that dll.
Normally when updating an NVDA installation, as nvdaHelperRemote.dll did not change its layout, things go okay. However, if nvdaHelperRemote is changed in any dramatic way (such as a segment being removed or code moved around such as with the mentioned Next snapshot) then if the old nvdaHelperRemote takes a long time to unload from an app, and in deed it is still there when the new NVDA tries to inject, Windows will refuse to load in the new copy as it thinks it already has it, and then executes from the wrong memory location.
We should place all NVDA dlls in a version-specific directory, so that the path to any NVDA dll changes for each version.
The text was updated successfully, but these errors were encountered:
Blimey.. Anyway, this might explain why sometimes programs vanish or nvda appears to hang but explorer has gone away. I wonder if something similar but delayed is what is crashing various versions of Outlook as I've noted on the user list? They do not say they specifically did an update but presumably this can also happen on a reboot or of a switch to and from a portable to an installed version as well? I don't quite get how you can have a different folder for dlls every time though. Brian email@example.com Sent via blueyonder. Please address personal email to:- firstname.lastname@example.org, putting 'Brian Gaff' in the display name field.
It is just a different folder per version. I.e. c:\program files (x86)\nvda\lib\2017.4 or c:\program files (x86)\nvda\lib\snapshot-next-14234-a1b2c3d4e5. Not a different folder per run. We are just trying to avoid two differently compiled copies from using the same path for a dll.
Does this mean then that if one runs from snaps you eventually end up either huge numbers of duplicate folders each with the name of the update , but containing the same files. I remember seeing some routine called unlock which was supposed to stop this kind of thing happening as it could stop deletion of files until a system restart otherwise. Brian email@example.com Sent via blueyonder. Please address personal email to:- firstname.lastname@example.org, putting 'Brian Gaff' in the display name field.
That is what I thought, so it looks first on a reboot and removes the unused ones. I tend to do this running of many snaps when trying to get back to the working one if its broken. I tend to use master for working and installed and next as a portable but obviously in different folders, keeping a working portable copy of the release version in a folder which I can use if trouble comes along. So on portable versions then, would the extra folders get deleted when you shut the installed version and run a specific portable one? Brian email@example.com Sent via blueyonder. Please address personal email to:- firstname.lastname@example.org, putting 'Brian Gaff' in the display name field.