If you did a clean install the files should be lost unfortunately. Sorry for the issues.
Meanwhile if you’d like to try a 2.2 install again in the future I could provide you with a version with logging so we could find the cause of the issue you are experiencing, then we can fix it for everyone. @PhilipGoddard
I’ve got the same problem as Philip Goddard. “My initial installation resulted in a blank program window with a message saying something like “attempting to connect to local server”, which it repeated a few times over a few minutes, then it crashed” Lots of dmp files. I guess I’ll watch and see if there is a fix posted here.
Well, after all that faffing around, 2.2 is now working fine on my system!
Yes, after lunch today I got a strong intuitional nudge to have another go at installing 2.2.
I automatically thought to uninstall 2.1 first, but an inner nudge pointed me first to try installing it on top of 2.1 but as a clean install. But then when I was about to click the ‘Clean install’ checkbox I had another little surprise intuition, to experimentally see what happens now if I do a ‘dirty’ install first before trying to clean things up, and with no reboot unless anything had gone wrong.
And you know what? – The world came to an end most calamitously of course (we’re all just ghosts now)!
In other words, 2.2 installed smoothly and ran smoothly, and, after my evening meal recess and starting up the computer again, GW 2.2 still running smoothly!!
However, there was one little difference about the installation this time. Before starting the installation I temporarily turned-off my power AV, VoodoShield. That may have been significant because part way through each of the previous installations, each time VS had intercepted a command line that it regarded as suspicious and gave me a prompt-alert. Although I allowed that each time, it occurred to me that there was a possibility that by delaying that particular action VS might have been causing a glitch each time in the overall installation process and so slightly corrupting the program or its configuration.
So, yes, I do need to remember to temporarily turn-off VS for installations of programs I trust!
Are there any settings that @PhilipGoddard could have activated that look at scripts in installers or anything similar that you might not have turned on?
I’ve extracted the VS log entries covering the period during which I did the installations. Weirdly, I could find only one entry saying ‘User Allowed’, for that would be one where I responded to the prompt. There should have been one for each installation. I’ve saved the list as a txt file, which I’d be happy to send you so you get a better idea of what VS was up to, but here’s the one User Allowed entry:
22/05/2020 20:24 User Allowed gwdrvins.cmd c:\users\philip\appdata\local\temp\nsz935a.tmp\gwdrvins.cmd 0 55 37a1cc07dea0aa1367f5ee44aa41c80ad6c6b82069e6c89ffa18c215059dd4c5 c:\windows\system32\cmd.exe /c ""c:\users\philip\appdata\local\temp\nsz935a.tmp\gwdrvins.cmd" -i "c:\program files (x86)\security\glasswire\driver\x64"" 1385 glasswiresetup-2.1.167.exe e:\downloads\glasswiresetup-2.1.167.exe Philip
– And yes, that is from when I reverted back to the earlier GW version, but it does highlight a significant point.
I should explain that it’s highly problematical behaviour of various installation programs to run programs or scripts from uniquely-named folders or files, because they can’t be whitelisted, and are thus a problem for security software to recognise as safe.
I’d run into that issue with other program installers and indeed had a really nice exchange with Dan, the VS developer, who explained the problem, and how with VS this could be worked around by creating a rule to make an exception for the particular Temp folder. I set that up and found that I could still choose to have a choice of conditions applied to that exception to make it as safe as possible - the one condition that I had to leave disabled being ‘if it is digitally signed’. I think if I disabled one or more of the other conditions there would be no issue from GW installer - but I’d rather keep most of the conditions if possible for safety, and rather just remember to temporarily turn off VS (a simple left-click on tray icon) immediately before running the installer of any program I trust.
But more generally, I’d seriously recommend to ANY software developer to understand the problem they create for users of some AV / AM programs by creating temporary scripts / exes in uniquely named folders or/and with unique filenames. They need to make it as simple as possible for all their installation programs and scripts to be easily whitelistable.
OS Name: Microsoft Windows 10 Home
OS Version: 10.0.18362 N/A Build 18362
I wasn’t having an issue with the previous install; I did this as a dry run before eventually uninstalling via GUI and reinstalling via Chocolatey (more info in this thread).
It took me a bit of time to notice it, but the toggles between Ask To Connect and Click To Block and vice versa are considerably faster. (I have to set to the latter temporarily to connect out Thunderbird running from a VeraCrypt container.)
I never put a stop watch to it previously, but now at about 4 seconds, seat-of-the-pants (an age old and trusted engineering proof) tells me it’s about five times faster. Not that I ever considered the wait an annoyance.