virtualbox.org

Suddenly I can no longer make any virtual machine starting. I created a new test virtual machine and does not start. I attach the file VBoxHardening.log. I tried uninstalling and reinstalling VirtualBox (with administrator rights), but nothing has changed. I do not know what to do if you do not change your PC. Can you help me ? Thank you
I tested with version 5.0.26 and 5.1.4 but the virtual machines do not start.

VirtualBox seems to be objecting to a Windows system DLL which, as far as I can tell, appears to be standard.

You might want to try (a) backing up your host using a disk imager, and then (b) running "sfc /scannow".

mpack wrote:VirtualBox seems to be objecting to a Windows system DLL which, as far as I can tell, appears to be standard.

You might want to try (a) backing up your host using a disk imager, and then (b) running "sfc /scannow".

I already run sfc / scannow. But it still does not work. Reading the log file I noticed that there is an attempt to load the dll wintab32.dll. In my system this dll not exists and what I read in the web, is a dll that covers the tablet. Is it normal that VirtualBox attempts to load this dll ?

a.coppola wrote:... wintab32.dll. In my system this dll not exists and what I read in the web, is a dll that covers the tablet. Is it normal that VirtualBox attempts to load this dll ?

Yes, it's normal. And btw VirtualBox doesn't decide which DLLs to load, Windows does. Wintab32.dll in particular is no doubt referenced by another Windows DLL, probably using the LoadLibrary API call. It would be normal for this load to fail on non-tablets.

mpack wrote:

a.coppola wrote:... wintab32.dll. In my system this dll not exists and what I read in the web, is a dll that covers the tablet. Is it normal that VirtualBox attempts to load this dll ?

Yes, it's normal. And btw VirtualBox doesn't decide which DLLs to load, Windows does. Wintab32.dll in particular is no doubt referenced by another Windows DLL, probably using the LoadLibrary API call. It would be normal for this load to fail on non-tablets.

I can not imagine other possible causes. Do you have any suggestions for me?
Thank you

Well, if you can pinpoint why behaviour suddenly changed then that ought to be a big clue. Software is deterministic, it does the same thing every time. You can't have a sudden change unless the environment changes, e.g. by a software update to VirtualBox, or the host OS, or your AV.

Also, you mention that you created a new VM. But do the original VMs still work? If yes then probably 3D acceleration makes the difference, indicating that you have a certification problem on some host graphics drivers.

mpack wrote:Well, if you can pinpoint why behaviour suddenly changed then that ought to be a big clue. Software is deterministic, it does the same thing every time. You can't have a sudden change unless the environment changes, e.g. by a software update to VirtualBox, or the host OS, or your AV.

Also, you mention that you created a new VM. But do the original VMs still work? If yes then probably 3D acceleration makes the difference, indicating that you have a certification problem on some host graphics drivers.

All virtual machines that until Friday 5 August 2016 worked from August 10, 2016 no longer worked. I created a new virtual machine and does not work. I attach printscreen of Windows updates made from 05 August to 10 August. Unfortunately I have no restore point available August 5 to August 7 only. I applied this restore point, but the virtual machines still do not work.

Thank you

edit: solved using virtualbox 4.3

Hi.

I also can't start any VM with on my computer.

I had virtualbox 5.1 installed on my laptop, and running various virtual machines for testing and "lab" purpose, as I'm a student.
The computer was running Windows 10 Pro 64 bit, and as far as I can tell, by the end of june everything was working fine. I haven't used virtualbox since then.
Yesterday, I've decided to come back to windows 7 pro 64, so I went for a clean install, did format c: and installed 7 Pro 64.
I've done the updates during the night, and now that I've installed VBox back, I can't start any VM on my computer, doesn't matter if it's an old one (that remained on another partition), a know working imported from another computer or a brand new one.

Everytime I try to start a VM, I get the following message: The virtual machine 'xxx' has terminated unexpectedly during startup with exit code 1 (0x1).
Error code: E_FAIL (0x80004005), MachineWrap

So far I've tried VBox 5.1.4, 5.1.2, 5.0.26, and I keed trying older builds, hoping to find one that works.

Does anyone has suggestions?

PS: Please forgive my poor English.

edit: Ok, I've installed virtualbox 4.3, and now It is working. I'can now use my old VM's, and create new ones again.

Installing anything 4.3.12 or earlier doesn't solve your problem; those versions don't test for the serious security hole that later versions are tripping over on your system. 4.3.14 was the beginning of the attempt to plug the security hole, and it took several versions to pin down how to plug it properly.

The security hole comes from the ability for DLLs to plug themselves into other processes to change the operation of the processes. This is how theme changers, antivirus, graphics card extensions, etc. work. Malware can do the same thing, and Virtualbox opens up so much capability on a PC that malware can do much more damage through Virtualbox. Since malware writers don't sign their malware, (or else they could be caught) the seemingly sane thing is to not run Virtualbox if unsigned DLLs would be loaded. Virtualbox can't just reject the DLL itself. As Mpack noted (somewhere above) it's Windows that dictates what DLL's will be loaded & Virtualbox has to comply or not run.

It is possible for a Windows update to mess up the Windows DLL security database and cause system DLLs to not work. I would uninstall Windows Updates back to when the system was working, then see if an up-to-date Virtualbox will run.

In addition to running an unsecure system, 4.3 will leave you unable to use some modern OS's, like Windows 10 & newer Linux on host or guest.

scottgus1 wrote:the seemingly sane thing is to not run Virtualbox if unsigned DLLs would be loaded. Virtualbox can't just reject the DLL itself. As Mpack noted (somewhere above) it's Windows that dictates what DLL's will be loaded & Virtualbox has to comply or not run.

Just a minor correction on this. While refusing to run may have been what earlier versions of the hardening function did, I suspect that the current stategy is to filter all DLLs loads and simply eliminate the DLLs we don't want. A rejection would be logged but it would not cause VirtualBox to refuse to run. In this case wintab32.dll wouldn't have loaded anyway (since it doesn't exist) so VBox filtering didn't make a difference. Sometimes the eliminated DLL is called by a buggy other DLL that loaded it, resulting in a memory access error (0xC0000001). The other DLL probably called LoadLibrary but didn't check the result.

mpack wrote:

scottgus1 wrote:the seemingly sane thing is to not run Virtualbox if unsigned DLLs would be loaded. Virtualbox can't just reject the DLL itself. As Mpack noted (somewhere above) it's Windows that dictates what DLL's will be loaded & Virtualbox has to comply or not run.

Just a minor correction on this. While refusing to run may have been what earlier versions of the hardening function did, I suspect that the current stategy is to filter all DLLs loads and simply eliminate the DLLs we don't want. A rejection would be logged but it would not cause VirtualBox to refuse to run. In this case wintab32.dll wouldn't have loaded anyway (since it doesn't exist) so VBox filtering didn't make a difference. Sometimes the eliminated DLL is called by a buggy other DLL that loaded it, resulting in a memory access error (0xC0000001). The other DLL probably called LoadLibrary but didn't check the result.

I uninstalled VirtualBox version 5.1.4, restart the computer and install the 4.3.12 version. Finally now virtual machines work.
I uninstalled the 4.3.12 version, uninstall the updates made between 08/05/2016 and 08/10/2016, reinstalled the 5.1.4 version but the virtual machines still do not work. Now the question is: Is there a way to figure out which DLLs directly or indirectly causes the problem?
Thank you

See my previous post about identifying the change.

Post another hardening log, maybe something else will show itself.

I doubt that would help, since the only change mentioned so far (since the previous hardening log), is the reversion to 4.3.12, which of course doesn't have the hardening feature and hence doesn't generate a log.

I would like the OP to consider what I asked him to consider, and not get sidetracked.

Hi, I have installed 5.1.8. I attach VBoxHardening.log file. I hope you can give me some guidance. I am currently working with another virtualiser
Thank you