Firebird 5.0.1 closes applications and requires reboot (MSVC installation problem)

[ralf3i]

In our application we use Firebird as database.
A install-launcher program (a simple win32 program) performs a scripted installation of Firebird, then of the main application, by calling both installers one after the other with command line options.

This always worked with FB2.x - 4.0.5.
The new 5.0.1 installer suddenly misbehaves:

When running the Firebird5.0.1 64bit installer on a fresh Win10 machine, in the same moment when the installer states it's installing MSVC 32-bit runtime libraries, it closes the our install launcher that would install (as a next step) the main application.

It also requires a complete reboot after installation, what it never did before.

The Install launcher is also closed if the FB-installer is launched manually (without parameters) - but only if the install launcher is from a network share and the 32-app was also started from that network share.

The Message "To complete the installation of Firebird, Setup must restart your computer. Would you like to restart now?" shows up in either case.

I tried running the installer with "/NORESTART /Silent /NOGDS32" - then the reboot-question does not show, but the service is also not started. Als it can be started manually, so there seems to be no reason no to do that.

This breaks the automatic installation.

Is there a trick to get that working, or do I have to revert to an older version of Firebird to implement an application installation that runs through in one go?

---

After some more checking:

If I install the MSVC installer from https://learn.microsoft.com/de-de/cpp/windows/latest-supported-vc-redist?view=msvc-170

If I install the X86 installer, then the launcher application is not closed by the FB installer
If I install the X64 installer, then the FB-installer can launch the FB service after installation.

Both MS installers don't require a system reboot.

Could it be, that the MSVC installation is not done properly by the FB installer?

[reevespaul]

Can you describe what is a fresh Windows 10 machine?
Is the Windows 10 machine up-to-date ?

[ralf3i]

Can you describe what is a fresh Windows 10 machine? Is the Windows 10 machine up-to-date ?

It's a Win10 machine with no other software installed.
It's a VM snapshot that is reverted after every test, therefore it's NOT up-to-date.
But: Does this make a difference?
1.) I can circumvent the problems by installing the MSVC manually - that works without a reboot and without apps being closed
2.) As it's a medical software typically installed on standalone device, so there is a good chance that the software will be installed on isolated systems that don't have any internet connection and that are also not on the latest patch-level.

If you like I can install TeamViewer or similar on the VM and allow you doing tests there.
And I can install all pending updates on that machine to see if that resolves the problem. But (as mentioned in 2 above) I already have feedback from sales people in the field running into exactly this problem.

[aafemt]

If you have no problem with manual install of MSVC runtime - just install it and Firebird from zip package.

[ralf3i]

I installed all available windows updates on the system.
The behaviour is exactly the same.
The problem remains.

@aafemt : That would be a dirty workaround for a bug in the installer. I'd prefer a "clean" solution, we have a few thousand customers.

[aafemt]

IMHO, "a dirty workaround" is exactly what Firebird installer does instead of simple addition of the runtime into the list of system requirements.

[reevespaul]

The reason I asked about which version of Windows 10 was because there have been 14 releases of W10, of which all but one are out of general support by MS. And one of the main differences between FB5 and FB4 is that the former is built with more or less the latest version of Visual Studio. FB4 is built with VS 2017 which appeared fairly early on in the release cycle of W10. So there is a small possibility that older versions of W10 that are not up-to-date might just fail to install firebird for some obscure reason.

Anyway, now that we seem to have ruled out a problem with W10 updates we can look deeper into this problem.

Have you tried running the installer with logging enabled? If so can you send me the log? Let me know if you need to send it privately. And theoretically at least the installation of the runtimes should also produce logs. Although I have never seen them. Their location will be indicated in the installer log.

[reevespaul]

Also, what version of msiexec do you have?
(Just type msiexec in a console prompt and a window will open with the version and a help screen.)

[ralf3i]

Here's the log file....
log.zip

msiexec returns 5.0.19041.4651

[reevespaul]

That's just the regular innosetup log. It is of no use in this case.
What is needed are the msiexec logs. Unfortunately they are automatically deleted by the innosetup installer when it closes.
I've prepared a special build that allows you to specify a different location for the msiexec logs. You just need to add

/logmsi="path to logs"

to your install script.

If you can then send me the log output of a failed runtime install I might be able to make some progress with this.

You can download the special build from here:

https://scm.ibphoenix.com:3000/ibphoenix/-/packages/generic/firebird-build-fb5_branch-windows-amd64/fb5_branch/files/4934

[ralf3i]

Ok, here are the logs.
This time I only called the installer with /logmsi="C:\somepath"
Let me know if you need different parameters...
logs.zip

[reevespaul]

The problem appears to be in the x64 install:

Info 1603.The file C:\WINDOWS\system32\msvcp140.dll is being held in use.  Close that application and retry.
...
Info 1603.The file C:\WINDOWS\system32\vcruntime140.dll is being held in use.  Close that application and retry.
Info 1903.Scheduling reboot operation: Deleting file C:\Config.Msi\67a81.rbf. Must reboot to complete operation.
Info 1903.Scheduling reboot operation: Deleting file C:\Config.Msi\67a86.rbf. Must reboot to complete operation.
Action ended 12:13:43: InstallFinalize. Return value 1.

Apart from that my log is functionally equivalent to yours.

Can you identify which application is using the msvcp140.dll ?

[ralf3i]

Strange things are happening.

It seems that vmtoolsd.exe uses it.

On fresh PC it has version 14.24.28127.4, dated Sept 19.
After installing the MS update it is version 14.42.34433.0 , dated 29th October 24
But it is not used by vmtools anymore. (so installing FB 5.0.1 would work)

If I revert to the plain system and install the "normal" FB 5.0.1 installer , then it requires a reboot and (already before reboot) the DLL is updated to 14.36.32532.0 dated 10th may 2023

If I revert to the plain system and install your new "special" installer without any command line parameters, it does not require a reboot, and the DLL remains on 14.24.28127.4, dated Sept 19. Also the service seems to be started automatically.

I hope things are clarer for you than for me :)

[aafemt]

There is nothing strange that programs compiled with MSVC use MSVC Runtime Library.

[ralf3i]

Hey Captain Obvious :)

Yes, that's not strange.
But it surprised me, that
1.) the MS installer can update the library without closing vmtools
2.) VMtools seem to not need the library any more afterwards (and before you aks, I do know dynamic linking, but that does not explain it, does it?

[aafemt]

This is one advantage of side-by-side assemblies. In contrast to Firebird installer they preserve old versions of the library so applications using the old library can continue working.

[reevespaul]

I've prepared a new build to test. There are three changes since the previous one.

1. This version was built with the most recent version of VS2022 - 17.12.3

   The previous test version was built with an older version of the VS 2022 runtimes that were certainly older than the runtimes deployed with v5.0.1. VS2022 is very much a moving target as it is updated every eight weeks or so. In theory that should not make any difference to the installation of the runtimes, but we all know the difference between theory and practice.

2. You now need to pass /MSILOGDIR=c:\path\to\wherever instead of /LOGMSI to you install script.

This is just a cosmetic change so that the parameter is now self documenting.

I would be interested to see the logs from this build produced by a failed install. I am wondering if there is a difference related to the changes in the VC runtimes used.

3. There is a new option - /NOMSVCRT

   It is intended for use with scripted installs. As the name suggests this will allow you disable deployment of the MSVCRT runtimes. If the target server is already patched up-to-date then it will probably already have the runtime libraries. Otherwise you will need to deploy them directly from MS.

I'm not really sure how this will work in practice but in any case I don't see any harm in committing these two features upstream so that they appear in the upcoming v5.0.2.

https://scm.ibphoenix.com:3000/ibphoenix/-/packages/generic/firebird-build-fb5_branch-windows-amd64/fb5_branch/files/5121

[ralf3i]

1.) The new build shows the same problems when started without parameters.
2.) On the test system everythings works fine with the /NoMsvcrt switch. The application works.
3.) However, I am a bit worried. Can I really deploy my application with the /NoMsvcrt switch? What happens if the PC is lacking those DLLs? Or can I be sure they are there on Win10 (or newer) systems?

[reevespaul]

Can I really deploy my application with the /NoMsvcrt switch? What happens if the PC is lacking those DLLs? Or can I be sure they are there on Win10 (or newer) systems?

The idea behind the /nomsvcrt switch is to give you a workaround. You need to either be sure that the runtimes have already been deployed or you must deploy the official vc runtimes as part of your installation.

I do not think that you can rely on a PC to have the VS2022 runtimes installed. The probability is high but not 100%. W10 is almost 10 years old so theoretically there are many people running older versions that have not been kept up-to-date.

The reason why we don't include the official vcredist binaries in the firebird installer is because they are actually larger than firebird itself. The kits would triple in size.

The new build shows the same problems when started without parameters.

I'll create another special build tomorrow. This time with the debug switch enabled for msiexec. The logs might produce enough information to track down the origin.

[reevespaul]

This build will now log msiexec with the verbose and debug switches enabled.

https://scm.ibphoenix.com:3000/ibphoenix/-/packages/generic/firebird-build-fb5_branch-windows-amd64/fb5_branch/files/5158

Hopefully it will be enough to give us some more insight as to the cause of the problem.
Just remember to run it with /MSILOGDIR=c:\path\to\wherever

[ralf3i]

Here are the new logs...
logs.zip