Ticket #247 (accepted defect)

Opened 4 years ago

Last modified 4 years ago

Installer fails to restart explorer.exe when upgrading on Vista

Reported by: j.vonpreussen@gmail.com Owned by: alamaison
Priority: minor (e.g. uncommon, cosmetic, has workaround) Milestone: 2.0 Extra features
Component: installer Version: 0.7.4
Keywords: Cc:

Description

1.) if pgm-engaged explorer windows are open, your installer asks if you want to close them and try to re-open later. a 'yes' lets your installer kill explorer.exe (the whole process) and not merely the offending windows. the avg user will be totally flumoxed when explorer-run services are gone after the install!
2.) connections using pageant keys fail. i cannot test p/w auth since none of my servers operate in that mode.

aside from fixing the faults, supra, what you need to make your project viable:

A.) a connection edit feature. requiring a user to delete and re-enter the whole set of connection params is very poor design.
B.) if you insist on using pageant, either always load it or set a flag when a connection wants to use it and then load it under those circumstances. if a user already has keys, inserting an SFTP key routine is trivial and i would think it better to integrate keys rather than rely on outside resources. if they do not have keys, there are std routines that produce them through openssh and are also trivial to insert.
C.) produce a connection dialogue box showing progress. allowing a connection to silently die -- telling the user nothing -- is not bad practice it is no practice.
D.) produce a manual and have it accessible from what little UI you provide.
E.) provide a link from your UI to your site and have the site an actual destination where informative wiki and fora activites are supported.
F.) provide a support forum which would instill user confidence, expand info dissemination, and eliminate reduplicative and/or un-necessary bug reporting.

--
johann

Change History

comment:1 Changed 4 years ago by j dot vonpreussen @ gmail dot com

  • Component changed from authentication to winapi

comment:2 in reply to: ↑ description Changed 4 years ago by alamaison

Replying to j.vonpreussen@…:

1.) if pgm-engaged explorer windows are open, your installer asks if you want to close them and try to re-open later. a 'yes' lets your installer kill explorer.exe (the whole process) and not merely the offending windows. the avg user will be totally flumoxed when explorer-run services are gone after the install!

What do you mean by "pgm-enabled"? Closing Explorer windows doesn't do what we need. The installer has to force Explorer to reload its plugins and the only way to do this is to kill explorer.exe and restart it. What kind of Explorer-run services are missing after Explorer is restarted?

Please file different issues in different reports. We can't track them otherwise.

comment:3 Changed 4 years ago by alamaison

  • Component changed from winapi to installer

comment:4 follow-up: ↓ 5 Changed 4 years ago by anonymous

"pgm-engaged" = "swish-engaged"

forgive me if i was not clear: the missing "Explorer-run" services includes "explorer.exe" itself.

i believe this is a single-issue report for Items 1/2: installation failure.

alpha items are merely potential user observations.

--
thank you,

johann

comment:5 in reply to: ↑ 4 Changed 4 years ago by alamaison

Replying to anonymous:

"pgm-engaged" = "swish-engaged"

forgive me if i was not clear: the missing "Explorer-run" services includes "explorer.exe" itself.

Just so we understand correctly, are you saying that when you install Swish and the installer asks to restart in-use processes (explorer.exe) the installer kills explorer.exe but doesn't restart it? Is explorer.exe still listed in Task Manager (Ctrl+Shift+Esc) when this happens?

i believe this is a single-issue report for Items 1/2: installation failure.

Item 2 was about Pageant keys not working. That's quite a different problem, no?

comment:6 follow-up: ↓ 7 Changed 4 years ago by anonymous

1.) explorer.exe was not running (the obvious reason why none of its services were running); and
2.) keys: the *installation* was defective because the pgm would/could not execute an integral part of its operations.

please be so kind as to note: i am talking re your latest update which i installed per your pop-up. the prior version was working just fine.

the fine distinction between whether an installation failed or a module being installed failed is not delineated in your drop-down of selections available for reporting. the selections also seem to be overly broad (perchance to fulfill the needs of other s/w) and could use some swish-specific enhancement. moreover, the avg end-user is unlikely to be able to make much of a reasoned judgment of the actual point of failure. hence, the proliferation of 'installation' bugs being reported to you.

also, if single-issue reporting is of paramount importance to you, please see that your bug-reporting form reflects all reportable-issues. it, then, behooves you to garner more single-issuing reports by clearly stating that no more than one (1) issue will be dealt-with in each report.

--
johann

comment:7 in reply to: ↑ 6 Changed 4 years ago by alamaison

  • Priority changed from critical (affects core workflow) to minor (e.g. uncommon, cosmetic, has workaround)
  • Status changed from new to accepted
  • Summary changed from newest version bombs on vista to Installer fails to restart explorer.exe when upgrading on Vista

Replying to anonymous:

1.) explorer.exe was not running (the obvious reason why none of its services were running);

This is definitely a bug. Unfortunately, maybe not one we can fix, as the logic that handles restarting in-use processes is built-in to the Microsoft Installer framework. This kind of thing happens from time to time with other shell plugins like TortoiseGit? etc. as well. Or does this happen every time for you?

I've changed the priority of the bug because, although unpleasant, there is a workaround: just restarting Explorer.

2.) keys: the *installation* was defective because the pgm would/could not execute an integral part of its operations.

It's still not clear to us what problem you are encountering with Pageant. Are you saying that Pageant was not installed? Or it won't run when you try to start it?

the selections also seem to be overly broad (perchance to fulfill the needs of other s/w) and could use some swish-specific enhancement.

I think 'authentication' is the category you were looking for.

comment:8 follow-up: ↓ 10 Changed 4 years ago by anonymous

1.) unless you are far more than an avg user, having explorer disappear is going to be more than a "cosmetic" event. i do not understand why you do not just have the user close the swish-utilized windows and prevent this occurrence.

2.) there was no problem with pageant at all. as i explained, 7.3 was working fine and i switched to 7.4 per your pop-up. that is also why the affected windows were open when i tried to install the new version. during the un-install i noticed a few things:

a.) the process pops up a dialogue that warns that a re-start is required;
b.) the following config keys are left in the registry after the un-install and no user confirmation is requested to permit this:

(1.) HKEY_CURRENT_USER\Software\Swish,
(2.) HKEY_CURRENT_USER\Software\Swish\Connections (w/ conn subs),
(3.) HKEY_CURRENT_USER\Software\Swish\Updates and
(4.) HKEY_USERS\S-1-5-21-3281499880-2184016308-2487225277-1000\Software\Swish (w/ sub dups as per items 2/3;

c.) you do not kill the pageant process if it was called;
d.) i am not sure why the re-start alert is issued since i checked the registry and there does not appear to be any runonce-type entries and your un-install proc does not actually initiate a reboot call; and
e.) your remaining reg keys ...\Updates has a DidRunOnce? that is set to '1' after the un-install and before the reboot.

i hope you appreciate that i am bringing these matters to your attn since i like your concept and would like it to be "enterprise-ready". i am a consultant to the VA -- a nice paying client -- and have to run this by the local IT for a cursory QC look. so far, i do not see even that modest effort resulting in a "pass".

--
johann

comment:9 follow-up: ↓ 11 Changed 4 years ago by anonymous

RE:
POSED: "the selections also seem to be overly broad (perchance to fulfill the needs of other s/w) and could use some swish-specific enhancement."

REPLIED: "I think 'authentication' is the category you were looking for."

i am not quite certain by the comment 'authentication'. your s/w opns are fairly simple and i would think something along the lines of:
installation,
host connection,
password auth,
key auth (putty::pageant),
SFTP directory opns,
SFTP transfer opns,
un-installation, and
not otherwise categorized

would substantially fill the bill. all of the other drop-down categories are mostly confusing ... at least to me.

i can see that you are very attentive to your raised-issues and, perhaps, prioritizing would best be left to a default rather than asking the user to preliminarily set something. a simple 'pending' might work. then, when you analyze the situation, you can more appropriately categorize things as you see fit.

--
johann

comment:10 in reply to: ↑ 8 Changed 4 years ago by alamaison

Replying to anonymous:

1.) unless you are far more than an avg user, having explorer disappear is going to be more than a "cosmetic" event. i do not understand why you do not just have the user close the swish-utilized windows and prevent this occurrence.

The open windows are not the problem. Explorer.exe keeps a handle to the Swish DLL as long as the process is running, in other words as long as there is a Start button visible. Therefore the only way to get Explorer to release the DLL, so the installer can overwrite it, is to kill explorer.exe, do the overwrite, and then restart explorer.exe.

It's the last part of this process that seems not to have worked on your machine. I'm still not sure whether this was a one-off glitch. Are you able to reproduce the problem by downgrading Swish, opening a Swish window (to make sure Explorer grabs the DLL) and then upgrading Swish again?

comment:11 in reply to: ↑ 9 Changed 4 years ago by alamaison

Replying to anonymous:

i can see that you are very attentive to your raised-issues and, perhaps, prioritizing would best be left to a default rather than asking the user to preliminarily set something. a simple 'pending' might work. then, when you analyze the situation, you can more appropriately categorize things as you see fit.

Good idea. The default category is now 'undefined'.

comment:12 follow-up: ↓ 13 Changed 4 years ago by anonymous

please let me make these suggestion merely to offer points to think about. i am devoid of any hard-core programming experience in windows and am thinking re things i would look at in the linux world.

the .dll update problem could be easily solved if you maintain your master copy in one directory, but utilize a clone/link in another directory for the explorer.exe build. that way you can update, say, the .bin/master file even when explorer.exe is using the copy .using/master file.

i have no experience with plugins for explore.exe, but a couple of alts to a complete restart might be to reload/restart only the affected FD or -- probably a more practical solution -- your own whole plugin. i would think that anything is better than messing with an explorer.exe restart proc.

with your current proc you might be setting up some sort of race condition when you replace the .dll and restart explorer.exe. i am just guessing, but you may replace in the background and the restart expects the .dll and finds it in an unsettled state. also, if you restart in the background and replace, then the restart may see explorer.exe has not finished closing and react strangely. what happens when one copy is simultaneously closing while one is opening is an open question (at least in my mind) as to what the O/S will do. however, this might explain why i see what i do with the file manager functions not being present. i am certain you have a much better idea re all this.

as you know, you can have more than one explorer.exe running and the highest PID will have the file manager duties and the other one shell et cetera. i am not certain how to do it programatically, but running explorer.exe this way is recommended for system stability and probably reduces total resident memory usage.

you asked if this was reproducible: i actually tried the whole proc twice before i started this thread. you also seem to indicate that explorer.exe is acting differently than i would expect: "opening a Swish window (to make sure Explorer grabs the DLL)". this would seem to indicate that explorer.exe is loading/unloading parts of your plugin dynamically and not fully building it at its initialization as i would have forseen. from what i know re windows coders this would show an heightened concern for resource utilization not normally exhibited by the same.

whatever. if this dynamic treatment is a fact, then i cannot see any need for restarting explorer.exe itself since all proper opns would then solely rely upon your own proceess/dll integrity.

i could run a process/dll tracker and answer many of these issues, but i am sure you already know all about these things and have the answers at your fingertips.

comment:13 in reply to: ↑ 12 Changed 4 years ago by alamaison

Replying to anonymous:

please let me make these suggestion merely to offer points to think about. i am devoid of any hard-core programming experience in windows and am thinking re things i would look at in the linux world.

the .dll update problem could be easily solved if you maintain your master copy in one directory, but utilize a clone/link in another directory for the explorer.exe build. that way you can update, say, the .bin/master file even when explorer.exe is using the copy .using/master file.

It's an interesting thought. Chrome and Firefox introduced a background update recently that waits until you restart the browser to overwrite the exe with the updated version.

i have no experience with plugins for explore.exe, but a couple of alts to a complete restart might be to reload/restart only the affected FD or -- probably a more practical solution -- your own whole plugin. i would think that anything is better than messing with an explorer.exe restart proc.

Explorer has ownership of the file descriptor so I can't reload it directly. Only indirectly by restarting explorer.exe. Even if I could, I think that would lead to crashes as Swish's symbols might be at new addresses but Explorer.exe would still be trying to access them at the old addresses.

you asked if this was reproducible: i actually tried the whole proc twice before i started this thread. you also seem to indicate that explorer.exe is acting differently than i would expect: "opening a Swish window (to make sure Explorer grabs the DLL)". this would seem to indicate that explorer.exe is loading/unloading parts of your plugin dynamically and not fully building it at its initialization as i would have forseen. from what i know re windows coders this would show an heightened concern for resource utilization not normally exhibited by the same.

Explorer only loads plugins when it needs to use them. So, for Swish, this is when it needs to query the top-level directory where the connections appear. In days gone by this only used to happen once you open "My Computer", but with more recent versions of Windows Explorer seems to query the plugins almost as soon as it loads.

whatever. if this dynamic treatment is a fact, then i cannot see any need for restarting explorer.exe itself since all proper opns would then solely rely upon your own proceess/dll integrity.

Explorer loads the plugins on demand but never releases them. That's why we have to restart it.

comment:14 Changed 4 years ago by anonymous

your comment:
"Explorer has ownership of the file descriptor so I can't reload it directly. Only indirectly by restarting explorer.exe. Even if I could, I think that would lead to crashes as Swish's symbols might be at new addresses but Explorer.exe would still be trying to access them at the old addresses."

reply:
i agree the FD route is fraught with complications, but there are numerous "unlocker" apps out there from which you could "reverse-engineer" your own solution. i am not really promoting this route since, personally, i think one of the shell script suggestions, infra, would be your best and safest method.

since i think re-starting explorer.exe is a very bad idea, i believe looking into a couple of alternatives might reveal a good solution for you. in fact, the winsparkle site might even have some good suggestions.

there must be thousands of open-source examples of an "uninstall.exe" to remove your plugin in a real-time manner. this is one route.

another route would be to register a "remove" method right along-side your operating dll (much like you do with 'winsparkle.dll). then you, and only you, could call this method to reverse the whole registration process. this would do the same thing as the uninstall.exe. then you would be free to install your completely new version.

the uninstall using C/P leaves the connections and i presume any way you find to "de-register" the plugin would do the same. here is where i might suggest that you code -- or scrounge around for such -- to enable editing the connection params.

i am reminded of this since i recently went through a spate of IPv6 changes for some clients when the service provider dropped the rented numbers from the NOC in favor of his own, new IANA allocation. this required re-working various configs for SSHD, SFTP, IMAP2, et cetera for both servers and clients.

in your current system, you would have to remove the old connections and re-create new ones to accommodate any changes. i might suggest that this is not really very "user friendly" when a simple edit would do. unfortunately, my lack of windows coding experience prevents me from scripting some sort of method to do this programmatically. perhaps, you have some insight as to how this could work where a large number of clients are involved with identical changes.

i would also be very interested in your thoughts re programmatically splitting in two (2) the shell/file-manager functions of explorer.exe and, hopefully, making the change persistent.

Note: See TracTickets for help on using tickets.