Uninstalling HC and or HidHide results in total lose of input device function

[CasperH2O]

Device manufacturer

• AYANEO
• AYN
• AOKZOE
• ASUS
• GPD
• ONEXPLAYER
• VALVE
• LENOVO

Device model
Observed with Lenevo Legion Go (2x) and OneXPlayer 2 (1x).

Handheld Companinion Version
0.19.0.2 and 0.19.0.2 Legion Go beta

Describe the bug
Several users on Discord have reported that upon uninstallation of HC through the Windows uninstaller (regular process) that all HID type devices stop working, controllers, mouse, touch screen, bluetooth keyboard and mouse, wired keyboard and mouse.

Current recovery procedures are either:

• Check device manager, enable disabled HID devices (if you a form of input that does work)
• Install new Windows OS, drivers etc
• https://docs.nefarius.at/projects/HidHide/fixing-a-bricked-system/ (unverified)

To Reproduce
Steps to reproduce the behavior:

1. Uninstall HC, including HidHide

Expected behavior
HID devices should remain functional

Logs file
Unable access.

[CasperH2O]

Initial investigation has been done by @nefarius and @Valkirie but issue has proved to be not easily reproducible.

[NightHammer1000]

I could recover by reinstalling HIDHide. Still had access over Rustdesk.
Had to Reinstall, Disable Device Hiding and than it worked again.

[nefarius]

Can't reproduce. Manual correction of the issue is documented here.

[CasperH2O]

@nefarius if one were to be able to consistently reproduce this issue, what should we check/verify/log in order to come up with an idea of what is going on?

[nefarius]

@nefarius if one were to be able to consistently reproduce this issue, what should we check/verify/log in order to come up with an idea of what is going on?

I assume that the setup doesn't remove the UpperFilters values, when uninstalling and before the reboot, the registry needs to be checked. Other than that there is no logging in the setup that could be of help.

[CasperH2O]

@nefarius thank you. No, HC "simply" runs the HidHide uninstaller, we don't do anything specifically with the register.

@Valkirie I'm thinking we have two options at this point:

1. Remove uninstalling of HidHide from the HC uninstaller and have users do it themselves if they want to.
2. The uninstaller checks and corrects the registry entries.

I don't like either and I don't feel comfortable coding number 2. What do you think?

[nefarius]

@nefarius thank you. No, HC "simply" runs the HidHide uninstaller, we don't do anything specifically with the register.

I mean my own setup, the HidHide setup 😉

[nefarius]

I can skim over the setup project again, maybe something with executing the Custom Actions that take care of cleaning up the registry silently broke in an Advanced Installer update, by now I do not trust this product any further than I can throw it...

[nefarius]

What you also could do to help is; when executing the removal, add /L*V .\install.log to the process and collect the generated log file, hopefully it captures whatever silently fails.

[nefarius]

If an affected user can then retry/reproduce it with this method in place, I can analyze the log file. Other than that we're flying pretty dark I'm afraid.

[CasperH2O]

Changes were made to make HidHide install no longer silent i.e. the user has to click through everything and do the reboot etc. The uninstall of HidHide is no longer done at all through the HC uninstaller.

One user has reported the soft brick issue since this changed was made but he was not sure if it really was this issue.

Was thinking for possible further debug an app that logs/monitors all changes done during an install/uninstall could perhaps be used like Ashampoo Uninstaller (https://www.ashampoo.com/en-us/uninstaller)

[nefarius]

Was thinking for possible further debug an app that logs/monitors all changes done during an install/uninstall could perhaps be used like Ashampoo Uninstaller (https://www.ashampoo.com/en-us/uninstaller)

Not recommended to involved any of this 3rd party nonsense, see my remark about generating a log.

[NightHammer1000]

@nefarius
This is the State of all HID Devices after you trigger the bug.
Seems like something in the Service Dependency Config goes haywire.

[NightHammer1000]

Trying to Replace a Driver results in this Error:

[NightHammer1000]

The Moment I reinstall HidHide i can just disable and enable the failed devices and they work again.
Putting more weight on the Service Dependency Theroy.

[CasperH2O]

/L*V .\install.log

@nefarius it seems @NightHammer1000 can reproduce the issue at will. You mention the addition of above snippet, where would this needed to be added, in the uninstaller?

[nefarius]

/L*V .\install.log

@nefarius it seems @NightHammer1000 can reproduce the issue at will. You mention the addition of above snippet, where would this needed to be added, in the uninstaller?

The official MSI, yeah.

[nefarius]

@nefarius This is the State of all HID Devices after you trigger the bug. Seems like something in the Service Dependency Config goes haywire.

I know the error. We do not know why. Make a log or we will not make any progress on this topic, thanks.

[nefarius]

Trying to Replace a Driver results in this Error:

This will never succeed until the UpperFilters entry of HidHide is cleaned up. The setup is supposed to do that, we need to figure out why it apparently does not for some. Provide a log and maybe we finally see why.

[NightHammer1000]

Will try. I can reproduce it now just fine. Will post one later today.

[nefarius]

Also for those affected and are not aware of it: how to recover from this manually.

[CasperH2O]

Managed to create a log of HidHide uninstalling (succesfully). The following changes were required to the HC inno setup file:

• Product code was outdated
• Add log arguments, note, don't let the log write to a folder that does not yet exists, this results in issues

From:
if(ShellExec('', 'msiexec.exe', '/X{BE49B9DE-F8EB-4F54-B312-DD4B601985FC}', '', SW_SHOW, ewWaitUntilTerminated, resultCode)) then

To:

if(ShellExec('', 'msiexec.exe', '/X{50D7EB6D-6A4A-4A38-B09C-CC28F75F082E} /L*V "C:\HidHide-Uninstall.log"', '', SW_SHOW, ewWaitUntilTerminated, resultCode)) then

I have made a test build for HC with this change, if someone who can reproduce the issue can install it, then uninstall it to create the log that would be great.

[tylergibson]

Also for those affected and are not aware of it: how to recover from this manually.

These instructions do not work. My device is softbricked from trying to upgrade from 0.19.1.5 to 0.20.3.0

When uninstalling HidHide, no usb connectivity works, and there are no registry keys found with the above link - following to the letter. I cannot reinstall HidHide through recovery because its bundled inside the HC installer which wont install in cmdline recovery mode. I cant launch safe mode because all USB devices are disabled.

There are 0 warnings anywhere that you can literally softbrick your device (ROG Ally) by installing HC.

[CasperH2O]

Hey @tylergibson , it saddens me to hear you are experiencing this issue and recovering does not seem possible through the instructions.

HidHide can be obtained separately here: https://github.com/nefarius/HidHide/releases/download/v1.4.192.0/HidHide_1.4.192_x64.exe

I'll make it a priority to default the HidHide uninstall to off in the HC uninstaller and adding a warning when the toggle is ticked. In addition to adding the additional logging.

Please note there is no need to uninstall HC when updating to a newer version, you can install "over" it.

[NightHammer1000]

@tylergibson
If you get it to work again, would you care to tell me your Windows Version?
On a Keyboard Press WIN+R and type in winver and post a Screenshot of the Windows Version.

I wasn't able to reproduce the Issue after a certain Windows Build. Would like to confirm my suspicion and maybe even install your Build Version and try if I can trigger it again to get some logs.

[nefarius]

Also for those affected and are not aware of it: how to recover from this manually.

These instructions do not work. My device is softbricked from trying to upgrade from 0.19.1.5 to 0.20.3.0

This guide works a 100%, make sure when you're in in WinPE mode to select the correct disk/partition.

There are 0 warnings anywhere that you can literally softbrick your device (ROG Ally) by installing HC.

Bugs like these are not intentional, hence not documented. Filter drivers are always risky, that's inherent to the technology. Follow the guide correctly and everything will work again.

[CasperH2O]

@nefarius here we go, we have a log of a failed uninstall and for good measure of a correct uninstall. I have already taken the liberty of diffing them, but I have no idea what I'm looking at. Hopefully it makes more sense to you. I did see that in the failed log, System Restore is disabled.

Attached files.

HidHide-Uninstall-fail.log
HidHide-Uninstall-succes.log

Can I ask you to have a look?

[nefarius]

@CasperH2O well this sucks. I reviewed them, thanks for that. However all the class filter removal steps are called and returned successfully, so now I have even less of an idea what's going on.

[nefarius]

A theory I have; a race condition with the watchdog service. I condensed the logs in the order that could hint at the problem:

MSI (s) (7C:EC) [19:25:30:394]: Doing action: RemoveClassHID
Action start 19:25:30: RemoveClassHID.
Action ended 19:25:30: RemoveClassHID. Return value 1.
MSI (s) (7C:EC) [19:25:30:566]: Executing op: ActionStart(Name=RemoveClassHID,,)
MSI (s) (7C:EC) [19:25:30:566]: Executing op: CustomActionSchedule(Action=RemoveClassHID,ActionType=1106,Source=C:\Program Files\Nefarius Software Solutions\HidHide\x64\nefconw.exe,Target=--remove-class-filter --position upper --service-name HidHide --class-guid 745a17a0-74d3-11d0-b6fe-00a0c90f57da,)
MSI (s) (7C:EC) [19:25:31:966]: Executing op: ServiceControl(,Name=HidHideWatchdog.exe,Action=2,Wait=1,)

If what I see here I understand correct is as follows:

• The watchdog service is always running, as per design
• The setup executes the filter removal steps successfully
• The still running service detects that the driver files are still there, however the filter entries are absent, therefore reinstates them
• Setup continues with the logic, arriving at the service stop and removal actions
• Setup finishes all tasks successfully, however the registry is now in a broken state due to outlined race condition

This would explain why only a handful of people are affected; it is an extremely timing-sensitive bug. I don't think I can manipulate the execution order of the setup so I need to think of a workaround. This is our best shot IMHO.

[Valkirie]

@nefarius I always love a good race condition before the weekend.

[CasperH2O]

@nefarius glad to hear the log helped and you have found something worth while to investigate.

My idea for a workaround (ie not a proper solution) would be to check the registry values at the end of the uninstall and set them to the correct values.

[nefarius]

My idea for a workaround (ie not a proper solution) would be to check the registry values at the end of the uninstall and set them to the correct values.

I do not have control over the order of events, what I could do though is add another custom action to stop the watchdog service before the filter removal steps.

[nefarius]

Took a bit of tinkering and adding more logging but I think we're on the right track here:

[nefarius]

@CasperH2O managed to reproduce it today, it is indeed a race condition with the watchdog service during removal:

[nefarius]

Fixed release is up, happy testing.

[CasperH2O]

With great relief I can state this issue has been fixed. While painful for those who have been affected and those we could not reach with the recovery instructions are least it wont happen anymore in the future.

Note that updating to the new version can still cause this issue when a system is rebooted during the update as it will uninstall the bugged version of HidHide still. Decline the midway reboot request and reboot at the end.

[nefarius]

You can also run this PowerShell snippet before starting the uninstall/upgrade:

Stop-Service HidHideWatchdog.exe

And you'll be OK.

[NightHammer1000]

@CasperH2O maybe add the Stop-Service HidHideWatchdog.exe to the Uninstaller right before uninstalling HIDHide.

[tylergibson]

@tylergibson If you get it to work again, would you care to tell me your Windows Version? On a Keyboard Press WIN+R and type in winver and post a Screenshot of the Windows Version.

I wasn't able to reproduce the Issue after a certain Windows Build. Would like to confirm my suspicion and maybe even install your Build Version and try if I can trigger it again to get some logs.

I was forced to reimage the Ally.

[Valkirie]

@tylergibson If you get it to work again, would you care to tell me your Windows Version? On a Keyboard Press WIN+R and type in winver and post a Screenshot of the Windows Version.
I wasn't able to reproduce the Issue after a certain Windows Build. Would like to confirm my suspicion and maybe even install your Build Version and try if I can trigger it again to get some logs.

I was forced to reimage the Ally.

It suxx but thanks to users reports, the issue was finally sorted. Once everyone has transitioned to the new release this issue will be forever gone.