VirtualBox 7.0 doesn't work on my Windows 7 host

[Technologov]

Hi,

Since VBox hardening, all VirtualBox versions refuse to work on my
Windows 7 host.

Log:
https://www.dropbox.com/s/zkf3lcxpme8rp ... 220827.log

... so I am forced to keep using VirtualBox 4.1.6 on it.
All v6.x doesn't work here either.
VBox 7 can be installed, the GUI works, but VMs refuse to start, like there is a vboxdrv kernel issue.
Is there any solution ?

This bug seems to happen only on some large-disk >2 TB systems with Windows 7, legacy BIOS, and GPT-formatted disks.

NOTE: VBox 7 works on Win7 hosts with small disks.

Regards,
--
-"Technologov"

[mpack]

Please zip complete logs and attach the zips directly here.

And note that Windows 7 is no longer a supported host for VirtualBox 6.1.x and later, though 6.1.x itself stills seems to work for most.

[Technologov]

vbox hardening log (vbox log doesn't get generated, since VM refuses to start)

[scottgus1]

Your sheel32.dll and uxtheme.dll are showing not signed. Hacked themes were a big Windows 7 thing. You probably have a hacked theme in place. Virtualbox can't run unless core Windows DLLs are signed. Gotta boot out the theme hack.

Run an "sfc /scannow" in an Admin command prompt to put the unhacked files back.

[Technologov]

--
> Run an "sfc /scannow" in an Admin command prompt to put the unhacked files back.

Thanks a LOT ! This fixed my issue with my Windows 7 system. VBox 7 BETA1 now works fine, and can start VMs !

Now my question is: why VBox hardening interferes with hacked system theme ? Is the theme user-space or kernel-space ? Assuming user-space, then VBox should not really care, IMO. It may be a security hazard unrelated to VirtualBox at all.
1. Is there any fix possible to ignore those hacked theme files ?
2. If not, then at least provide a more meaningful error message rather than just failing on "vbox hardening", which is a really obscure error.

[klaus]

They're userland components, but since they're present in the VM processes of VirtualBox (which can influence the kernel-mode state of VMs) hardening needs to establish trust for those, too. Which is why VirtualBox requires a valid signature.

The fact that creators of random software think they can modify system libraries is (even if you look at purely userland applications) is a broad violation of trust in the OS, since everyone would blindly assume it is from Microsoft.

[mpack]

Now my question is: why VBox hardening interferes with hacked system theme ?

You have that completely the wrong way round. You have system DLLs that have been altered, and the digital signatures required for trust purposes have not been updated. This is not professional work, it's a hack. It isn't just VirtualBox that has a problem with blatant hacks, a lot of modern software will. And in the modern world, complaining about OS security features is pointless.

Even back in the day there were theme managers for Win7 and later that modified the theme without actually hacking OS DLL files - basically they hacked the DLLs at runtime in the memory of each process instead. Processes that don't about this behaviour will not notice. Those processes that do care are easily excluded.

[Technologov]

I request some kind of resolution:

Either:
1. exclude theme libraries from VboxHardening check ... ? (but what are the security implications ?) -- if it doesn't reduce VirtualBox security very much...
(is non-hardened VirtualBox such a bad deal ? What about Linux system, where users can installed hacked & custom KDE themes? is it also a problem on Linux ? )
-or-
2. at least provide a better error message when something like this happens. (if #1 is not an option)

I don't really understand the "hardening" concept.

[squall leonhart]

patching the uxtheme file was made unrequired 11 flippin years ago when the UxStyle unsigned theme service was released.

[mpack]

1. exclude theme libraries from VboxHardening check ... ?

Obviously not an option. Malware needs only pretend to be a theme dll and it's exempt from VirtualBox hardening checks?

2. If not, then at least provide a more meaningful error message rather than just failing on "vbox hardening", which is a really obscure error.

Not so easy either. VirtualBox's treatment of unsigned/hacked DLLs is simply to unload them. A crash happens when something else calls the DLL, and that "something else" isn't likely to be VirtualBox. It's going to be another theme DLL that is signed.

This conversation was done to death years ago, when hardening was introduced. See FAQ: Diagnosing VirtualBox Hardening Issues.

[mpack]

Have we established that this conversation belongs in the beta test forum? Because to me this looks like a typical hardening vs theming complaint that could have happened on any version since 4.3.14.

[klaus]

VirtualBox 7 is not promised to run on Windows 7 host (minimum Windows version is 8.1), which means that we'll not do anything unless the issue is reproducible with a supported Windows version.