VB tries to install an unsigned driver when starting a VM

[GIGA1BYTE]

This particular issue of unsigned drivers comes about after successfully installing VirtualBox 6.1.26 on a MS windows 7 host.

The very first Virtual Machine (with any guest) I show/open after a windows 7 boot up, always activates the windows program compatibility assistant.
The message from this assistant informs that a recently installed program tried to install an unsigned driver.
The driver and its location it references to is MpKslDrv.sys.
This driver is part of the Microsoft Security Essentials antivirus program, which of course is signed.

I don't remember this issue when I installed VB 5, but when I uninstall VB 6 and reinstall VB 5 this issue remains.

It concerns me that this relates to the antivirus driver, and hence it seems unwise to defeat unsigned driver checking and installing.

As I said, this only happens on opening the first VM. Opening/showing any subsequent VM never results in this unsigned driver message.

Any ideas what might be going on?

Be gentle as I am just a casual user of VirtualBox and don't know a lot about its intricacies.
Hoping its nothing to be concerned about and or has a simple setup fix.

[mpack]

This particular issue of unsigned drivers comes about after successfully installing VirtualBox 6.1.26 on a MS windows 7 host.

Win7 is not a supported host OS for VirtualBox 6.1.26. Are you sure you are talking about a host and not a guest? The host is the physical PC, the guests are the VMs.

Which particular VirtualBox driver or module do you say is unsigned? AFAIK VirtualBox modules are always signed, unless it's a test build. Also my Windows 10 64bit host has not objected to any VBox 6.1.26 driver or module.

[GIGA1BYTE]

Yes, I was talking about Win 7 being the OS on a physical machine, which I have taken to be the host.

I was not aware that Win 7 is an un-supported OS for VirtualBox V6.1.26.
The guest VM's (I have several created under VirtualBox 5 as well as a couple of new ones under VirtualBox 6) all work fine on my win 7 PC.
Note I an relying on hostossupport.html which states VB 6 supports win 7.

The unsigned driver issue also occurs when I un-install VirtualBox V6 and reinstall VirtualBox V5.
As I said, I don't recall this issue with VB 5 but I can't be sure as it was some time ago.

The unsigned driver being flagged is not a VirtualBox driver at all, but a Microsoft antivirus component that is signed.
There has to be some interaction involving this driver with opening that first guest VM.
Subsequent openings of any guest VM (with or without an OS in it) do not cause this windows popup message.
Only when you reboot windows 7 will this popup appear again, one time only, when opening a guest VM.

When installing VB 6.1.26 on my windows 7 (64 bit) there were no objections about unsigned drivers or modules.
The objection only comes when opening that first guest VM. And it points to a signed microsoft windows driver (the KSL driver).

If uninstalling VB 6 is not complete then VB 5 might inherit this issue from VB 6.
Hopefully there is a process that can be followed to remove everything VB 6 installs, so that I can restore VB 5 and not run into this issue.

Since the issue involves the antivirus protection, it is a concern that it seems that virtualbox tries to install a fake microsoft driver.

[mpack]

The unsigned driver being flagged is not a VirtualBox driver at all, but a Microsoft antivirus component that is signed.
There has to be some interaction involving this driver with opening that first guest VM.

Or it could be pure coincidence, since I'm not aware of any possible interaction between VirtualBox and host OS that can make the host OS think that some other component is unsigned.

On the other hand, corruption of the certificates database used to be a common problem with Win7 - there was a particularly notorious Windows update that planted the seed.

Uninstalling VirtualBox v6 and installing v5 should completely remove all installed v6 files. Again, if you wish to assert otherwise then again I'd need to see chapter and verse, i.e. here is the filename, here is the version properties showing that it's a v6 file.

VirtualBox files are readily identifiable. They exist either in the c:\Program Files\Oracle\VirtualBox folder, or they live in system32 folder and are called vbox<something>. You can also search for VBox* in the registry.

[GIGA1BYTE]

You are unnecessarily being very defensive wrt VirtualBox.
I am not making any assertions about VirtualBox, just trying to convey what is happening.

And in doing so was hoping someone else has the same experience or
That someone understands the nitty gritty of VB and gain some idea by digging into system level detail.

For the record, uninstalling VB6 does leave keys in the registry and does leave some files.
As far as I can tell, the ones that I can find seem innocuous or irrelevant to this issue.
Differential analysis says that if VB5 didn't have the issue before but does after VB6 then something has changed.

Further info, disabling real time protection in the antivirus program avoids the flagging of this issue.
This suggests that the antivirus program does intercept some VB action that takes place when opening a guest VM.

[mpack]

You are unnecessarily being very defensive wrt VirtualBox.

Nope. I'm just not prepared to waste time on unsupported or vague assertions - I've been at this too long for that. Plus Win7 isn't a supported OS so there's nothing to defend.

In hindsight it is true that uninstalling VirtualBox may leave some files behind, but these are not referenced by the OS so can't cause any problem, certainly not a problem with the signing of a completely unrelated app or driver. If you want to be sure that no files are left behind then just delete the Program Files\Oracle\VirtualBox folder before installing anything else.

Btw, I did not claim anything about registry entries being deleted. It is common to leave those behind to be picked up again on a reinstall. The entries are harmless if nothing is around to read them. But again, if a particular registry entry causes you concern then please name it so we can have a useful discussion of whether leaving that key behind is a good idea.

[scottgus1]

@GIGA1BYTE, please remember that one big problem with your setup has been identified already:

Win7 is not a supported host OS for VirtualBox 6.1.26.

Some short time ago, (I think within the 6.1.x series) Windows 7 was dropped as a supported host OS. This means that Virtualbox no longer gets tested for bugs on Windows 7 host PCs. Virtualbox 6.1.x may work or will have bugs, but if bugs happen these bugs will no longer be fixed for Windows 7 PCs.

So even if we can pin down that there are leftover files (expected in some cases, btw, since the VMs and XML definition files are left behind for further reinstalls, like how an uninstall of MS Word does not delete the .doc's) and exactly which file is being left over or interfering, these problems will no longer be fixed for Windows 7 hosts.

Also, sometimes things on commodity computers, even on big server computers, don't go as planned. Do you have backups to roll back to? That's where I'd go to try to fix this kind of annoying glitch, to the disk images I take regularly of my important computers.

FWIW this kind of problem hasn't happened much (at all?) that I have seen in the years I've been on the forum. It's extremely likely a "cross-wiring" problem in your host OS not in Virtualbox.

[GIGA1BYTE]

Thanks,

Found the manual for VB6.1 and it no longer mention's windows 7, so I accept that this version may have some unintended consequences.
Before I installed it, I did a google search on supported Hosts, which lead to the manual for VB6 and that does state support for windows 7 (64 bit).
Never thought that incremental revisions would drop an OS that still has a large user base (1 in 7) but understandable as MS no longer supports it either.

Will try to delete all references to Oracle or VirtualBox and reinstall a supported version of VirtualBox, and hope its fixes the issue.
I did make a private restore point, and installing VB also resulted in an automatically created restore point, but they do not help with this issue.

Yes, have several images of my OS (protection against ransomware), but they are snapshots that are not 100% current, and so loading them just replaces an issue with some recovery work.

There is no argument that things go wrong with computers and I really haven't assigned any blame because it did go wrong.
I came looking for expertise to nut out an unusual issue that seems difficult to relate to virtualbox.
But as is so often the case on specialized technical forums, there is a quick response of pointing elsewhere if there is no immediate recognition.
IMHO, that is just a cop out response, and in this case it is just as likely to be an issue of VirtualBox as it is likely to be an issue of Windows 7.

Just have to accept that this is an unknown, and lacks interest due to windows 7 having been dropped.

[scottgus1]

Good that you have backups! Most don't. Of course a backup taken yesterday won't have the changes since then so recovery work would be naturally needed. Unless you take the backup right before the upcoming change.

Supposed "cop-out" responses may be the only reasonable responses possible. Yes, once a particular arrangement goes out of support, folks may just say, "Don't want to bother with that because it's not supported". Anything can be fixed. But time is money. So who's going to pay to have the problem fixed? Oracle has paying customers that fund Virtualbox development. Virtualbox support is expensive, and the customers likely don't use 7 as a host OS much anymore. The problem you're having appears very rare to me, so will take some digging, which means money. The bill from a computer fixer will probably be a lot more than simply getting a new PC, and tons more than reinstalling the host OS.

as is so often the case on specialized technical forums, there is a quick response of pointing elsewhere if there is no immediate recognition.

Some forum gurus may take this comment quite personally. The unpaid forum answerers here volunteer their time to help free Virtualbox users, like you sir, who have purchased zero (0) support and are entitled to zero (0) support. These volunteers work their brains to help folks with very intriguing problems. Just read around on the forums to see the very unusual issues that come up and get fixed. We do tend to work on supported environments, but we also enjoy the challenge of fixing things when it is possible and feasible.

[GIGA1BYTE]

I get that some issue's are difficult to tie into causality, but this issue was posted to see if anyone had any clue about it.
The fact that windows 7 is no longer supported was good information and gives reason to try and remove everything left behind after the un-installer.

If the total removal of VB6.1.26 and installing a win7 supported VB gets rid of this peculiar issue, I'll report the process for those that fall into the same trap.

[GIGA1BYTE]

Some differential observations:

As I don't recall this issue with VB 5.1.22, I verified if it existed before by using a backup image from before installing VB 6.1.26.
Result was that this issue did not pop up when starting a guest machine.

Installing VB 6.1.26 over the top of VB 5.1.22 also did not cause any pop up (from the compatibility assistant with a message about this issue).

Unfortunately the issue re-appears as soon as I update to the latest virus definitions for Microsoft security essentials.
And it does so for VB 5.1.22 prior to, as well as after installing VB 6.1.26.

Some event must triggers the real time protection associated with current definitions.
Using process explorer did not help with getting deeper into the issue - need some-one with more expertise.

With all of this it may well be that the message is probably not representative of the root cause.
As a thought, maybe related to VirtualBox hardening, as there were some similar posts wrt opening of a guest and security essentials.

[scottgus1]

Restoring to a previous image and trying again got you some really good data there!

Restored 5.1.22 > no error
Restored 5.1.22 > upgrade to 6.1.26 > no error
Restored 5.1.22 > Update MSE > error
Restored 5.1.22 > upgrade to 6.1.26 > Update MSE > error

It certainly looks like MSE is causing this. Can you set an exception in MSE to not scan any files or folders related to Virtualbox or the VMs, including the network and USB driver files somewhere within in the Windows folder (should have 'vbox' in the name)?

FWIW if there is a hardening problem, you would see a non-0 exit code in the end of the hardening log, or possibly lines in the vbox.log containing the text "supR3HardenedErrorV".

[GIGA1BYTE]

I should have mentioned that one thing I had already tried was to exclude the whole VirtualBox folder in MSE.
It did not have any impact on the issue, and of course MSE has no issues with any of the files in this folder.

sigverif (a signature verification program) does flag a virtualbox network driver as unsigned, that one is parked in windows/system32 (I forgot the name but will check for it again).
This particular driver is signed by Oracle, so is may be a false positive from sigverif, or some co signature mismatch.

Since the issue only appears when you start a guest and thereby invoke this driver, it might be related.
I'll exclude it from being scanned by MSE and see what happens.

[fth0]

Perhaps you could check the certificate chains manually: In Windows Explorer, right click on the driver file and open the properties dialog, then the Digital Signatures tab and its subordinate windows. I could imagine that a Windows 7 installation does not have all necessary certificates to verify signatures created in 2021. Just my 2 cents.

[GIGA1BYTE]

The driver is VBoxNetAdp6.sys.

There is only one entry in the digital signatures list "oracle".

The certificate information shows as ok - has a couple of exclamation marks to identify some critical extensions (normal I think).
There is a counter signature for time stamping and its certificate information also shows as ok.

MSE does not allow browsing to exclude specific .sys files - but entered the path to it manually anyway - no impact on the issue.
Excluding all files with the sys extension and excluding the whole "drivers" folder - no impact on the issue.

ftho - You may be right with windows 7 falling behind with its certificate verification checks.
Don't like windows 10 and even less the direction of windows 11.
Looks like I will just have to move to linux for some programs.
The VM is in fact for a linux guest, in order to run a build root for compiling NAS firmware (it makes for a convenient development environment).

There is also an expired oracle certificate on my system - did wind back the system clock to see if this was interfering somehow - no impact on the issue.