7.6.9 Upgrade Fails on Windows 10

[Ardemus]

Thanks jrweiss. And thanks goates, you are experiencing exactly what I am. I also have tried all of those things and more, with no success, except going through and manually deleting the entire folder. I'd rather not try the brute force suggestion since Windows installers usually riddle the OS with files, and it's highly unlikely that I could root it all out without a guide to what's actually hidden all over the file system. Without that guide, I'd likely just break the current install and there's a good chance reinstalling will still fail, leaving me unable to run FAH at all.

[jrweiss]

After a brute force uninstall, I do a search for appropriate strings in both Windows Explorer and Regedit to find and purge the file structure and Registry of unwanted files, folders, and keys. Usually takes 5 minutes or less...

[Ardemus]

After a brute force uninstall, I do a search for appropriate strings in both Windows Explorer and Regedit to find and purge the file structure and Registry of unwanted files, folders, and keys. Usually takes 5 minutes or less...

I appreciate the suggestion. Yes, there's a good chance of success, but the current version is working, and there's also a good chance of breaking that. It seems wiser to wait for a safer solution.

I don't trust that everything is registered and named appropriately. If this project was developed appropriately, then I'd be able to update without uninstalling and I'd have an uninstaller matching what's registered with Windows. I'm also years out of date on Windows internal details. There were rumblings of a more robust system to replace the registry, designed for OOP manipulation through .net and Powershell. I know that the registry still exists, but are you sure there aren't other hidey holes to clean out?

[jrweiss]

If this project was developed appropriately, then I'd be able to update without uninstalling and I'd have an uninstaller matching what's registered with Windows. I'm also years out of date on Windows internal details. There were rumblings of a more robust system to replace the registry, designed for OOP manipulation through .net and Powershell. I know that the registry still exists, but are you sure there aren't other hidey holes to clean out?

Well, I don't know why it was "developed appropriately" for me, but not for you. I updated without uninstalling, and I have the uninstaller. I don't know what drivers and protection apps (anti-virus, anti-malware, firewall, etc) you have, but one of them may be interfering with successful [un]installations.

These days, it is IMPOSSIBLE for a software developer to foresee EVERY combination of software and hardware. Sometimes the end user just has to do some manual intervention...

If 7.5.1 is working for you, then just stay with it. I suspect it will be a VERY long time before it is deprecated...

[Ardemus]

You're protective of FAH, which is understandable. I wouldn't be here if I didn't value the project, and what it does. I'm investing my time more to help the community get a jump on the problem than get a solution for myself. I'd like to see FAH maintain the huge surge in popularity that their COVID-19 project has brought them. To do so, they'll have to support a far larger, far less tech savvy, user base.

This machine is a basic AMD self built using popular components. Scanning my Start Menu and "Apps and Features", this is everything I've installed:

• Game Clients (Steam, Oculus, Oculus Tray Tool, GOG, each with a collection of games
  and not allowed to run in the background unless I launch them)
• Chrome
• Firefox
• Spotify
• Notepad++
• windirstat
• FOH
• CPU-Z
• zoom
• driver packages (AMD Graphics, MSI MB, Samsung Monitor, MS Input, Logitech Input)

I did have the userbenchmark test installed, but I've removed it. I've run autoruns, but that doesn't involve installing anything. It doesn't get much simpler for a real system with a useful graphics card. Oculus and FAH are the only things I'd suspect of interfering with other apps.

I'm aware of the challenges involved in software development and QA. FAH is great for an internal tool shared by experts, which I think is the level it has operated at, but there are weaknesses compared to the best mainstream products. I'm confident that this is a problem with FAH, and it's a problem that many others will face as time goes on. There are already two of us with this exact problem who took the time to find this forum, and that's before the mods even setup a section for the release.

[VxJasonxV]

Coincidentally, Ardemus, you named the source of the problem. I too had this problem, there is one minorly strange detail.

Yes, my installer also hung at SSLeay32.dll as well. I chose to try deleting the Program Files x86\FAHclient directory specifically. I was able to delete all but three files, the deletion dialog tells you why it can't:





Why GOG Galaxy took hold of them is beyond me, but after shutting GOG Galaxy down (I'll point out this is 2.0, as well) I was able to delete the folder. It's still off, I'm going to run the 7.6.9 installer, let's see how it goes.

[VxJasonxV]

Hopefully my posts get approved in order, otherwise this one will not make any sense. Since I can't edit my original post to add, since it's in moderation as a new user: hey mods! if you're reading this, please make sure my other post explaining the issue is approved first, please!

I closed GOG Galaxy, deleted the FAHclient program directory, was able to run the 7.6.9 installer successfully. I'm curious to know if it's sufficient to close GOG Galaxy and run the 7.6.9 installer without any other steps. Might be? Anyone stumbling across this post, please try that first.

[Forcen]

I'm curious to know if it's sufficient to close GOG Galaxy and run the 7.6.9 installer without any other steps. Might be? Anyone stumbling across this post, please try that first.

I can confirm that closing GOG galaxy lets me run the installer without problems. Thanks for letting me know.

I'm running GOG galaxy 2.0.13 beta on Windows 10 version 1909 (OS version 18363.778).

[Ardemus]

after shutting GOG Galaxy down (I'll point out this is 2.0, as well) I was able to delete the folder.

Thanks Jason. I'm non running the GOG 2.0 beta, but apparently I was letting GOG 1.2 start in the background at boot on this system. Exiting GOG through the systray freed the DLLs and the FAH update went fine.

Why GOG Galaxy took hold of them is beyond me

I don't know a lot about library registration in Windows. However, I doubt that GOG took hold of the DLLs from FAH. I installed GOG months before FAH, and GOG doesn't have file system access to the FAH directory during updates. I checked the gcc dll (gnu c compiler?) out of curiosity, and the file in the FAH directory is twice the size and 2 years older than GOG's copies. I would guess that FAH registered it's own copies of a few libraries at a system level, superseding other system level registration of the same libraries, and maybe downgrading the system's shared libraries in the process. I hope that's not the case.

It may well be that both GOG and FAH intalled the same subordinate app, and the older version FAH installed overwrote the registrations for the newer version GOG installed. Regardless, I'd recommend that someone look into it. If FAH is downgrading shared libraries, it will cause problems for other apps.

[Ardemus]

Is there a way to mark a thread as resolved, or mark a post as a solution?

[bruce]

I don't understand why GoG Galaxy would be putting programs in Program Files x86\FAHclient. The developer made what seemed like a reasonable assumption that the subdirectory named FAHClient could be owned by the developer of software named FAHClient.

[Chris_TG]

I don't understand why GoG Galaxy would be putting programs in Program Files x86\FAHclient. The developer made what seemed like a reasonable assumption that the subdirectory named FAHClient could be owned by the developer of software named FAHClient.

I think the strange behaviour is connected to the fact that windows can't load different instances of shared DLLs with the same filename. Instead it just increases an internal counter for how often this particular DLL is in use ATM and inform the requesting program "yep, it's already there".
For example: If you have program 1 in autostart loading DLL "zlib.dll" and then starting program 2 that also want to load this DLLs, it will use the already loaded DLL.
In VxJasonxV's case it seems that the GoG-client uses the DLLs already loaded by the FAHclient, so if you keep the GoG-client running when you try to uninstall the FAHclient, it will complain.

[goates]

Disabling the GOG client worked for me as well. The GOG client had already been installed on my system so I doubt it installed anything into the FAHClient directory. Chris_TG's suggestion makes sense though.

And using the Express Install option there is now an Uninstall.exe in the FAHClient directory. I used the Custom Install previously, mostly just to see where it wanted to install everything, so maybe there is an issue there with not including the uninstaller.

[jrweiss]

I use Custom Install, and I have the Uninstaller.

[Ardemus]

I don't understand why GoG Galaxy would be putting programs in Program Files x86\FAHclient. The developer made what seemed like a reasonable assumption that the subdirectory named FAHClient could be owned by the developer of software named FAHClient.

GoG didn't do anything to the FAHclient folder on my system. I installed FAH months later.

If you have program 1 in autostart loading DLL "zlib.dll" and then starting program 2 that also want to load this DLLs, it will use the already loaded DLL.

If you're correct, wouldn't restarting with FAH disabled fix the problem? FAH wouldn't load any libraries, so GOG would load it's own libraries, and nothing in FAH would be locked. However, I tried that and it didn't change anything.