Issue Details (XML | Word | Printable)

Key: CORE-3900
Type: Bug Bug
Status: In Progress In Progress
Priority: Minor Minor
Assignee: Paul Reeves
Reporter: Brenden Walker
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.
Firebird Core

VC runtime installer can reboot system prior to installation finishing

Created: 31/Jul/12 12:33 PM   Updated: 04/Jan/20 09:30 AM
Component/s: Installation
Affects Version/s: None
Fix Version/s: 3.0.5

Environment: Windows 7 fresh installation during first boot process

QA Status: Cannot be tested

 Description  « Hide
If the VC runtime installer needs to reboot to finish installation it will cause the FB installer to reboot the system with no warning (due to /qn passed to msiexec) before the FB installer finishes. This page notes that msiexec returns exit code 3010 if a reboot is needed perhaps running always with /norestart and setting internal reboot required flag would be preferable.

The only time we've seen this is with freshly imaged Win 7 machines during the first boot process.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Paul Reeves added a comment - 31/Jul/12 01:29 PM
I'm not sure what to say about this. Let me add a few thoughts anyway.

Part of the problem is that we are building with and consequently deploying the original MSVC8 runtimes, whereas all new Windows versions come with the later (SP1?) runtimes. Worse still, we can't, afaict, detect if the either of these runtime assemblies have already been installed. This seems to be a deficiency of wix v2.0.

The other part of the problem is that we do not plan to deploy runtime assemblies with Firebird 3.0. It is built with MSVC10 which has abandoned this stupidity. All that is required is to drop the runtime into the same directory as the Firebird binaries.

So, going forward, this problem will disappear naturally. The question is what, if anything, can be done for Fb 2.1 and Fb 2.5.

I'll take a look at your suggestion of trapping the error and setting the reboot required flag.

Brenden Walker added a comment - 31/Jul/12 04:41 PM
Considering that this will be moot in the future, AND that our situation was likely an extreme edge case.. I think this is likely a low priority. Thanks for looking into this.

Paul Reeves added a comment - 04/Nov/14 11:09 AM
We don't seem to have had any other reports with this problem and as the OP indicated, it appears to be an edge case. I think we can close this issue.

Paul Reeves added a comment - 26/Sep/19 03:51 PM
I'll take another look.

Sean Leyne added a comment - 26/Sep/19 04:20 PM
Stefan Heymann today posted to the devel list:

    CORE-3900 is an issue about the VC runtime installer (which is included in the Windows Setup.exe install) rebooting the machine without any prior warning.

    I have had this on several occasions when installing Firebird 2.5 on a client's production machine. When I installed it onto a brand new Windows 10 computer last week, the same thing happened.

    The classification of this issue as an "edge case" (Paul Reeves, 2014-11-04) is wrong IMO. This is a serious issue because it can cause production machines to suddenly boot.

    It would be good to reconsider this issue and fix it.

Paul Reeves added a comment - 07/Nov/19 10:48 AM
Here is some background to what is happening:

There is a system level setting which determines when and how to do a system restart. By default the setting is to restart automatically if a restart is required. This can be over-ridden at the application level.

The firebird installer is designed to not require a system restart. The problem here is when it calls msiexec to install the runtimes. No restart option is passed so the system default is used.

msiexec has three restart options:

Do not restart after the installation is complete
Prompts the user for restart if necessary
Always restart the computer after installation

We can safely ignore the last one. So the choice comes down to /norestart and /promptrestart.

/promptrestart appears to be the most sensible solution on first examination, but I have no idea how that will manifest itself to the user. I presume it will throw up a dialogue as well as setting an error flag. But msiexec is run silently and if the install is scripted this could present a bigger problem than the one we have at the moment.

This means that /norestart would be the safest solution but with the small risk that the install may not work correctly for the few installs that require a reboot. However, in general it seems that active applications that might be using existing versions of the runtime libraries will continue to run and newly started appplications will pick up the new runtimes. At least that is the theory. All that the reboot does is clean things up by deleting the old runtimes.

It would be helpful if we had some more information from a system that did a forced restart. The msiexec application writes a log out to {tmp}\vccrt{#msvc_version}_Win32.log and {tmp}\vccrt{#msvc_version}_x64.log

If we could identify the cause of the restart I might be able to reproduce it and find the right solution. But I must admit that suppressing the restart completely is the best and simplest way to go.

What do others think?

Brenden Walker added a comment - 07/Nov/19 02:01 PM
If VC is installed in PrepareToInstall you could run with /norestart and set the passed in var NeedsRestart if msiexec exitcode is 3010. That will allow InnoSetup standard restart handling to deal with it (including not restarting when /NORESTART is passed, which is what we expect).

That should resolve the specific issue we had.

All that said, as noted in my original post. We've only seen this happen on freshly imaged systems during the firstboot process. AFAIK we've worked around the issue on our end. As nobody else has reported this issue, I think it could be closed or at least made very low priority.

Paul Reeves added a comment - 07/Nov/19 02:19 PM
The other problem is that, as far as I can tell, innosetup does not pick up the errorcode from msiexec. At least, not when msiexec is executed from the [RUN] section.
It is possible that we could run msiexec in a function but that seems as if it may also have unforeseen side effects and require some more serious testing.
Hence my preference for /norestart and then winging it :-)

It puts us in a better place than where we are now, and side effects would be limited.

Brenden Walker added a comment - 07/Nov/19 02:29 PM
Indeed, you would have to run the installer in code. I don't know that it's any more risky that using the run section, but would definitely require more testing.

In case you decide to go down the manual install path. Here's how we install dotnet, we do all of our dependencies in PrepareToInstall so that we can set NeedsRestart.


function InstallNETFramework(var NeedsRestart: Boolean): String;
  xExe: String;
  xParams: String;
  xRun: Boolean;
  xResult: Integer;
  xLogFile: String;
  xLogFile := LogFileNameNoExt('{app}\LOG', 'NETSETUP'); // No extension - already gets .html
  xExe := ExpandConstant('{tmp}\NDP461-KB3102436-x86-x64-AllOS-ENU.exe');
  xParams := '/q /norestart /log "' + xLogFile + '"';
  xRun := Exec(xExe, xParams, '', SW_HIDE, ewWaitUntilTerminated, xResult);
  if (not xRun) or ((xResult <> 0) and (xResult <> ERROR_SUCCESS_REBOOT_REQUIRED))
  then Result := 'Unable to install Microsoft .NET 4.6.1 (' + IntToStr(xResult) + ').'
  else Result := '';
  NeedsRestart := (xResult = ERROR_SUCCESS_REBOOT_REQUIRED);

Paul Reeves added a comment - 07/Nov/19 03:52 PM
Thanks for that Brendan. That will be useful.

I will certainly look to include it or something like it for the next release of FB 3 or maybe Fb4 beta 2. But the immediate problem (which caused this report to be re-opened) is to provide a fix for Fb 2.5.

My hope is to just add the norestart switch and then we can repackage and silently upload the new binaries. Fb 2.5 is no longer officially supported by the Firebird project but if this can be fixed with a simple repackaging then I think I can push it through. The last thing I want to do at this stage is try out a new bit of code.