Cannot install/upgrade to VirtualBox 7.0.10 on Windows 7 Professional Service Pack 1 (x64)

[Juan Pablo Guzmán Rosero]

Hi.

I have VirtualBox 7.0.8 installed, and when I try to upgrade to 7.0.10, a message is shown that Visual C++ 2019 Redistributable is not installed or missing.

The strangest thing is that Visual C++ 2019 is installed on the computer as shown in the following screenshot.

Does this have to do with the fact that VirtualBox no longer supports Windows 7?

It's necessary to take into account that the computer has all its Windows updates installed.

Thanks in advance for the review.

[Klaus Espenlaub]

Hard to tell really... we're not testing any VirtualBox version with Windows 7 any more.

The error message you see is produced if the registry key HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\X64 isn't there, or its contents indicate that it isn't installed or that it is not at least version 14.20.

Could you provide a screenshot or a textual copy/paste of this bit of the registry (including sub-keys!), please?

[Juan Pablo Guzmán Rosero]

Hello. Glad to greet you.

Of course, here you are: 3 screenshots for:

HKLM\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\X64

HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\X64

HKLM\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes\X86

Thanks in advance for your review and reply.

Regards from Colombia.

[bsvorinic]

I have the exact same issue - Windows 7, Visual C++ 2019 Redistributable installed but still getting error. I know Windows 7 is not supported, but some kind of workaround would be greatly appreciated :-)

[fth0]

Replying to Klaus Espenlaub:

I've provided a (partial) analysis with a hint to a possible root cause in the VirtualBox forums in ​Microsoft Visual C++ 2019 Redistributable Package.

[fth0]

It looks like your Windows 7 host is not up to date. Did you install SHA-2 support (KB4474419)?

[bsvorinic]

Replying to fth0:

It looks like your Windows 7 host is not up to date. Did you install SHA-2 support (KB4474419)?

I have KB4474419 installed (actually all available Windows 7 updates are installed) but still get the same error.

HTH, thanks!

[Juan Pablo Guzmán Rosero]

Replying to fth0:

It looks like your Windows 7 host is not up to date. Did you install SHA-2 support (KB4474419)?

Yes, I have all Windows 7 Updates installed, even that update.

And also, I just looked for available updates and Windows Updates shows the computed up-to-date

[fth0]

Thanks for trying! The background for my question was the following experiment:

At the weekend, I created a new VM, installed Windows 7 SP1 (without activation), installed the Microsoft Visual C++ 2019 Redistributable Package (x64), ran the VirtualBox 7.0.10 installer and could reproduce the issue. Then I just installed KB4474419, rebooted the Windows 7 (as requested) and the VirtualBox 7.0.10 installer didn't complain any more.

In the meantime, I did some more investigations, revealing that the verification of the code signatures of the VBoxInstallHelper DLL by Windows 7 is failing. It's an open question why and under which conditions it fails ...

[ruyi]

I can install VirtualBox 7.0.8 without prompting

https://www.virtualbox.org/wiki/Download_Old_Builds_7_0

[__Vano]

I have diagnosed this problem and found the cause.

Bottom line: the VBoxInstallHelper DLL is built with the /IntegrityCheck flag which causes the dynamic linker to validate it like a driver upon LoadLibrary. But the .cat files needed to do that are not yet present on the system -- so the validation fails.

So this DLL cannot be built with that flag.

You may have not seen this error because on your system, the needed .cat files are already present, or you were testing a package with MSVC embedded (this custom action only runs for a package without an embedded MSVC).

---

Details:

The fact is, the MSVC redistributable search is not even attempted! The custom action DLL that does that, VBoxInstallHelper, fails to load, with error 1157 (ERROR_DLL_NOT_FOUND):

Action 16:31:49: ca_IsMSCRTInstalled. 
Action start 16:31:49: ca_IsMSCRTInstalled.
MSI (c) (34:5C) [16:31:49:833]: Creating MSIHANDLE (1) of type 790542 for thread 10844
MSI (c) (34:88) [16:31:49:833]: Invoking remote custom action. DLL: C:\Users\Sasha\AppData\Local\Temp\MSI27D4.tmp, Entrypoint: IsMSCRTInstalled
MSI (c) (34:D8) [16:31:49:835]: Cloaking enabled.
MSI (c) (34:D8) [16:31:49:835]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (34:D8) [16:31:49:835]: Connected to service for CA interface.
CustomAction ca_IsMSCRTInstalled returned actual error code 1157 but will be translated to success due to continue marking
MSI (c) (34:88) [16:31:53:668]: Closing MSIHANDLE (1) of type 790542 for thread 10844
Action ended 16:31:53: ca_IsMSCRTInstalled. Return value 1.

Sysinternals Process Monitor shows however that this error code is false: the cause is not some missing dependency DLL. Instead, the custom action msiexec.exe process iterates over all the installed .cat files, then terminates without ever loading the DLL. To see the real error code, I've extracted this DLL from the installer and tried to load this DLL manually, via Python Ctypes module (I've added the ".dll" extension that Ctypes expects). This gave me the real error message:

In [3]: import ctypes

In [5]: ctypes.windll.LoadLibrary("./VBoxInstallHelper.dll")
<...>
OSError: [WinError 577] Windows cannot verify the digital signature for this file. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source

After lots of googling about what this error means, I have finally tracked it down to the IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY flag in the DLL's optional PE header which causes it to be validated upon load just like I've seen in the Process Monitor. Validating it with signtool verify /kp (with Kernel Model Signing Policy) confirms that without the /kp switch, the valiation succeeds but with it, it fails. Indeed, if I remove the integrity flag from the DLL with a PE editor, the DLL loads successfully.

[__Vano]

Patch (MIT license)

[__Vano]

One more piece of evidence: upon the DLL load, an error is logged into the Application and Services Logs\Microsoft\Windows\CodeIntegrity\Operational system log:

Code Integrity is unable to verify the image integrity of the file \Device\HarddiskVolume1\Users\Sasha\AppData\Local\Temp\MSI27D4.tmp because the set of per-page image hashes could not be found on the system.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-CodeIntegrity" Guid="{4EE76BD8-3CF4-44A0-A0AC-3937643E37A3}"/>
    <EventID>3002</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>1</Task>
    <Opcode>102</Opcode>
    <Keywords>0x8000000000000000</Keywords>
    <TimeCreated SystemTime="2023-10-21T13:31:53.668285100Z"/>
    <EventRecordID>1497</EventRecordID>
    <Correlation/>
    <Execution ProcessID="9396" ThreadID="12352"/>
    <Channel>Microsoft-Windows-CodeIntegrity/Operational</Channel>
    <Computer>Sasha-PC</Computer>
    <Security UserID="S-1-5-21-3641942489-2283234919-193382172-1000"/>
  </System>
  <EventData>
    <Data Name="FileNameLength">66</Data>
    <Data Name="FileNameBuffer">\Device\HarddiskVolume1\Users\Sasha\AppData\Local\Temp\MSI27D4.tmp</Data>
  </EventData>
</Event>

[__Vano]

(off topic) Could you please add me to CC for this ticket? I'd like to get notifications on its progress. I seem to not be able to do that myself.

The Component field should probably be set to Installer, too.

[fth0]

Replying to __Vano:

(off topic) Could you please add me to CC for this ticket? I'd like to get notifications on its progress. I seem to not be able to do that myself.

Writing a comment (like you already did) should be enough to get notifications from then on. If you get notified for this comment of mine ... ;)