For those playing along at home....
I got the scan results, showing any registry hits for sx550j, via email
When you install a program, some parts are set by the installer in a static path for files, and in static locations for most registry entries. But for drivers (and some other things) their classes, enumerated devices registry keys they get assigned random keys or GUID keys, to stop any entries being duplicated or overwritten (collison)...for example the bold part of the following reg key is a (random) class GUID
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\
{88bae032-5a81-49f0-bc3d-a4ff138216d6}\0000
As these are generated randomly by windows when the drivers are installed, after the main program is finished being installed (the YiHI driver installer is post-install), the main Yihi installer doesnt know anything about them, so it cant remove them if you uninstall the program....it will remove the static files and registry keys just fine. When he tried reinstalling and it didnt work, i first suspected either he had bricked his firmware, but with his next post i suspected he had dynamic registry keys for the drivers files that were confused and was trying to use the same incorrect driver when he tried connecting to the mod. With the incorrect driver installed and them being dynamic theres only a few ways to get rid of them. This way is the safest ive used for a remote attempt at fixing, without resorting to teamviewer, which is my 1st choice normally, if i know the person...
Then for the ENUM keys we have USB Vendor ID's (VID_XXXX) AND Product ID's (PID_XXXX) for their uniqueness
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USB\
VID_1980&PID_0001\!GL907095DJECE9----------------
After a couple of decades of the windows registry, you learn to identify Vendor ID's (VID_xxxx)....the most obvious one is 8086, which is Intel, chosen as they of course made the original 8086 Chips used i the original IBM PC....
Also added to that are the references to the oemxx.in files which are randomly created driver inf files - if you install drivers for your video card or audio, it may have a name in the driver package like atixxxx.inf, but when its installed into the windows inf folder, it gets an oemxx prefix, again to avoid overwriting each other
So with the registry scanner report, i went through and confirmed that it was what i thought and he was getting stuck with the same driver being presented, i sent him a .reg file to delete the relevant registry keys and to stop the driver installer referring to the previous incorrect oemxx.inf files as well
Fro a 1900 line report file with all the subkeys and values, it could be reduced to delete the root keys for the offending branches
Downloaded and merged as admin, it will remove those root keys, a reboot and retry of the driver installer will hopefully do the job...
Fingers crossed
Note: the following reg file is PC specific due to the reasons above, random oemxx.inf references and random class GUID's
Code:
Windows Registry Editor Version 5.00
[-HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{88bae032-5a81-49f0-bc3d-a4ff138216d6}\0000]
[-HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USB\VID_1980&PID_0001\!GL907095DJECE9----------------]
[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{88bae032-5a81-49f0-bc3d-a4ff138216d6}\0000]
[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1980&PID_0001\!GL907095DJECE9----------------]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverInfFiles\oem12.inf]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverInfFiles\oem13.inf]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverInfFiles\oem14.inf]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverInfFiles\oem15.inf]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverInfFiles\oem16.inf]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverInfFiles\oem17.inf]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverInfFiles\oem18.inf]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverInfFiles\oem19.inf]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverInfFiles\oem20.inf]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverPackages\sx550j-b.inf_amd64_03734a3f37cced8d]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverPackages\sx550j-b.inf_amd64_2a28a9700ae2eb76]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverPackages\sx550j-b.inf_amd64_6804040c1baec2ea]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverPackages\sx550j-b.inf_amd64_82526a288190945e]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverPackages\sx550j-b.inf_amd64_8491565fed726405]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverPackages\sx550j-b.inf_amd64_c41dbfcfc2c9601b]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverPackages\sx550j-b.inf_amd64_c670180b3415a5cc]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverPackages\sx550j-b.inf_amd64_eb9b44bd9e128b32]
[-HKEY_LOCAL_MACHINE\SYSTEM\DriverDatabase\DriverPackages\sx550j-b.inf_amd64_f869a72afbff747b]
Going to bed, 5am here...ill check in in about 6 hours
Edit/update:
Lying in bed realised depending on his user level, he may not get permission to delete those keys even form an admin command prompt, so got up and wrote some batches and sent a zip containing a semi auto solution using NSudo to absolutely get the permissions necessary