View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003080||Ham Radio Deluxe||Bug||public||2019-01-19 23:02||2019-02-24 15:13|
|Target Version||Fixed in Version||18.104.22.168|
|Summary||0003080: V22.214.171.124 No automatic restart of install after C++ 2017 runtime is installed.|
|Description||When installing on a system where the VS C++ 2017 runtime is installed. our installer comes to the point where the runtime is installed. The system properly installs the runtime software and indicates that a reboot is needed. Once the computer is rebooted, the installation does NOT automatically continue the installation of HRD.|
The computer comes up in the desktop as it would or a normal reboot. In order to continue installing HRD you must locate the setup.exe file and re-run it.
|Steps To Reproduce||Setup a machine which does not have VS C++ 2017 runtime installed.|
Run the HRD installer (Setup.exe)
Follow the installation and after the install script installs the C++ 2017 runtime kit, the dialog will display indicating a restart of the computer is required.
Click the [Restart] button and a reboot will begin.
Upon completion of reboot the computer will come up in the desktop view
In order to continue installing HRD V126.96.36.199 you must locate and re-run the HRD "setup.exe" again.
|Tags||No tags attached.|
I'm not able to reproduce this problem. I've spent about five hours trying various combinations. In each scenario, I started with a fresh Windows 10 x64 installation.
In the cases where the existing runtimes kit is present and of the same version as the kit the product wants to install, I can verify that the product doesn't attempt a re-installation of the kit.
With little to go on in the report and without seeing the problem first-hand, I'm forced to guess at what might be happening. Of particular interest is the cause of the restart. I can't tell if the VC++ Redistributables paackge is itself causing the restart, or if the HRD Setup script is executing the restart.
If the redistributable package installer is causing the reboot, then there's not much we can do. It doesn't signal the restart to the HRD setup script, which would need to know to restart at the point where it left off. There's no mechanism for this communication, and no bookmarking exposed to the script language in InstallAware.
If it's our own script that's performing the reboot, then we've got a more serious problem. It's readily verified that any explicit reboot in the InstallAware script uses the "Reboot and REsume Setup" command, which InstallAware advertises as rebooting then resuming setup. (See https://www.installaware.com/mhtml5/desktop/rebootandresume.htm) While it's concerning that the setup resumes before the user logs in, the documentation for this command does indicate that it performs the overall action we desire. I have no facility for diagnosing why the InstalAware package, itself, would be failing to complete this operation.
Two more possibilities are that the script (or the installer) tell the user to reboot manually (and they do) and the script terminates. That path would have symptoms consistent with what has been reported, but the reported symptoms have multiple causes.
Further, it's possible that the runtime distribution kit isn't involved; other component management may require a reboot. Just because the restart is invited after the install of the runtime kit doesn't necessarily mean the runtime kit is initiating the requirement for the restart; and it doesn't necessarily mean the runtime kit is alone in requiring a restart.
Adding to the challenge is that the VC_REDIST.EXE package is scarcely documented. If I assume that it is a self-contained MSI package, then we can work with the assumption that it returns on of several common error codes (see https://docs.microsoft.com/en-us/windows/desktop/Msi/error-codes) to indicate its disposition. The HRD setup script doesn't exhaustively test for these.
Until more information is available, I think my only move is to augment the tests for restart returns from the Visual C++ runtime package and assure that the we end up at the "Reboot and Resume Setup" instruction that we intend.
Because I am unable to demonstrate this issue myself, I have no way to test that my fix is impactful. The changed code is checked in with the changeset below. It seems likely that the problem is stateful; removing or installing something means changing state. Users who've continued with setup past the reboot probalby won't be able to reproduce the issue because the preconditions that cause the issue (unidentified so far) don't exist anymore. As such, we can't directly interpret success on an install of the first changed build as demonstration that the underlying issue is solved ... all the more reason to pursue enough details to form a test case.
||I'm never too sure what to do with issues in this state. I can't repro the issue, and I've made a speculative fix ... as far as I know, the only way to expose it to testing is to mark it resolved, so I'm doing that.|
||The only way we're going to know if this resolves the issue is to send it out as an open beta and allow a large number of customers to provide us feedback.|
Simplified: (on Windows 7 64 Bit)
When there is no MS Visual C++ 2017 present on the system, it calls for a reboot
When there is an older build of MS Visual C++ 20017 present It will run thru the setup and let our installer continue
When the same Build of MS Visual C++ 2017 is already on the system, the Visual C++ installer prompts with a Fail, after that
you can press cancel and our installer will continue.
It can be that this will be different on Win 10 (did you tested on Win 7?)
This issue makes no mention of a specific version of Windows, so I tested with Windows 10.
When I install Build 187 on Windows 7 (32-bit) without the VC 2017 runtimes previously installed, I'm not prompted for a reboot.
||Validated on both trade show machines|
|2019-01-19 23:02||KB3NPH||New Issue|
|2019-01-19 23:02||KB3NPH||Status||new => assigned|
|2019-01-19 23:02||KB3NPH||Assigned To||=> K7ZCZ|
|2019-01-20 13:21||K7ZCZ||Note Added: 0007040|
|2019-01-20 21:01||K7ZCZ||Note Added: 0007042|
|2019-01-20 21:01||K7ZCZ||Project||1 - Backlog => 3 - Current Dev List|
|2019-01-20 21:02||K7ZCZ||Status||assigned => resolved|
|2019-01-20 21:02||K7ZCZ||Resolution||open => fixed|
|2019-01-20 21:02||K7ZCZ||Fixed in Version||=> 188.8.131.52|
|2019-01-21 02:33||WA9PIE||Note Added: 0007051|
|2019-01-21 04:45||PD9FER||Note Added: 0007054|
|2019-01-22 15:53||K7ZCZ||Note Added: 0007058|
|2019-02-08 09:30||WA9PIE||Status||resolved => closed|
|2019-02-08 09:30||WA9PIE||Testing||Not Started => Beta Successful|
|2019-02-08 09:30||WA9PIE||Note Added: 0007315|
|2019-02-24 14:36||WA9PIE||Fixed in Version||184.108.40.206 => 220.127.116.11|
|2019-02-24 15:13||WA9PIE||Project||3 - Current Dev List => Ham Radio Deluxe|