VBox not working

[NoNameNeeded]

I know that Virtual Box is an extremely unreliable product (but that's putting it mildly) but every time I think it can't get any worse Virtual Box proves me wrong.

Anyway, the "good" software doesn't work.
I created a virtual machine (Windows XP on a Windows 2008 R2 host), turned on 3D acceleration (VBox 5.2 because I've read that 3D acceleration no longer works on more recent versions)
but it won't start.

Apart from the fact that it doesn't start anyway using the start button (which is a problem that has existed for many years that no one bothered to fix), even if I start it without GUI there is an error message that tells me some stuff that doesn't really say anything.

ScreenShot 679.jpg (61.47 KiB) Viewed 3008 times

Here are the log files...

Windows XP-2022-06-13-01-39-16.log

(2.82 KiB) Downloaded 5 times

I can't upload the hardening log file because it's too large.
Probably too many errors for the forum server to handle

[NoNameNeeded]

Now I've compressed the hardening log file (using 7 zip)

Windows XP-2022-06-13-01-49-51.7z

(15.52 KiB) Downloaded 7 times

[scottgus1]

Thanks for the logs, let's see if we can get this working for you!

Hardening:

132c.1324: Error (rc=0):
132c.1324: supR3HardenedScreenImage/LdrLoadDll: cached rc=Unknown Status -22900 (0xffffa68c) fImage=1 fProtect=0x0 fAccess=0x0 cHits=3 \Device\HarddiskVolume2\Windows\System32\shell32.dll
132c.1324: Fatal error:
132c.1324: supR3HardenedDllNotificationCallback: supR3HardenedScreenImage failed on 'C:\Windows\system32\SHELL32.dll' / '\??\C:\Windows\system32\SHELL32.dll': 0xc0000190
......
ExitCode=0x1

The VM log concurs in this error.

Exit code 1, according to Diagnosing VirtualBox Hardening Issues, might be fixed with a Run-As-Admin 'sfc /scannnow'. Seeing as your host's 'shell32.dll' is the trigger, this may be some 3rd-party software that plugs deeply into the Windows substructure but didn't sign the changes. Also try uninstalling 3rd-party antivirus or other malware protection (though the log doesn't report any such).

VBox 5.2 because I've read that 3D acceleration no longer works on more recent versions

Actually, 6.0 still has 3D for XP, too. But 5.2.44 should also work well.

I know that Virtual Box is an extremely unreliable product

You were playing that record on your first and until today your only post viewtopic.php?f=6&t=96013&p=465512#p465512. I'm sure if you can lift that needle for a bit we can get things going well for you.

[NoNameNeeded]

You were playing that record on your first and until today your only post viewtopic.php?f=6&t=96013&p=465512#p465512. I'm sure if you can lift that needle for a bit we can get things going well for you.

I didn't mean to hurt anyone's feelings but it is indeed very annoying.
And yes, the exact same error (vm won't start by just clicking on the start button) that occurred three years ago is still a thing in version 6.1.
So what does this tell me about the effort the developers put into fixing this problem (which not only I seem to have, btw)?
There was no effort whatsoever.

But anyway, my shell32.dll file has been modified by me at some point (even though I don't remember exactly what I did, but I think I replaced some of the icons).
But as I see it, none of the Windows system files come with digital signatures, so should this really cause any problems?

Oh and something very important: When I disable 3D acceleration the vm DOES actually start normally so it seems to be the 3D acceleration setting that causes the problem.
But the only reason I've installed Virtual Box once again was to use XP with 3D acceleration so disabling 3D acceleration isn't really an option.

[scottgus1]

There was no effort whatsoever.

There's been tremendous effort:

Hardening is necessary to prevent malware from getting more control over the host than it's allowed to get. And Virtualbox can allow such privilege extensions. So hardening must be implemented to prevent that problem. After a few iterations, the devs settled on requiring DLLs to be security signed (it seems for some reason that malware makers don't want to security sign their malware). And hardening works when the DLLs are all security-signed. A little more dev work allowed simply rejecting some unsigned or failing DLLs instead of preventing all Virtualbox operation. But core Windows DLLs cannot be simply rejected.

But when we shoot ourselves in the foot:

my shell32.dll file has been modified by me at some point

and we aren't aware of the side effects:

none ALL of the Windows system files come with digital signatures (ftfy)

then some troubles will continue.

So if one hacks a Windows DLL and does not security sign it, then hardening errors happen.

The solution: Don't hack core Windows DLLs. You have to roll with plain vanilla Windows on Virtualbox hosts.

[NoNameNeeded]

So how will Virtual Box be more secure if they prevent to power on a machine by simply clicking the start button when - at the same time - it is very well possible to start the machine by choosing "headless start" and then hitting "show"?
That makes no sense.
How can VBox be more secure because of that?

Or why doesn't the other error occur when I disable 3D acceleration?
How does this make VBox more secure or how can it be that VBox works with my modified shell32.dll when I don't use 3D acceleration but doesn't work with 3D acceleration enabled even though it's still the same shell32.dll?


Additionally, I just checked again and found that there are SOME system files (dll files) with a digital signature, but not too many as it seems.
The shell32.dll doesn't have a digital signature.
At least not on Windows Server 2008 R2.

[scottgus1]

possible to start the machine by choosing "headless start" and then hitting "show"

why doesn't the other error occur when I disable 3D acceleration

Headless start does not use 3D acceleration either, so in both cases 3D is not being used. When 3D is being used, host graphics drivers are relied on. There may be a security signing trouble with the host graphics drivers too. The graphics companies also sometimes fail to sign a file.

Can you please upload a log using the headless/show method where the VM boots? Be sure to fully shut down the VM before taking the logs. Please provide both the far left tab's log and the hardening log in the zip file.

[NoNameNeeded]

Maybe let me clarify that there are two problems.
The first problem is the one I already had 3 years ago: It's not possible to start a vm by pressing the "start"-button, I have to choose "Headless start".
It's annoying and I don't understand why they don't bother to fix that problem but it's a problem I can live with now that I know that it is nevertheless possible to start a vm, though.

The second problem is that a vm won't start when 3D acceleration is enabled.
It won't start in "headless mode" either.
That's the main problem now.

Here are the log files, the leftmost one and the hardening log

vbox log.zip

(21.1 KiB) Downloaded 4 times

[scottgus1]

OK, that makes sense. I believe I understand the two different problems. The headless vs 3D problem from before was probably related to host video driver issues.

a vm won't start when 3D acceleration is enabled.
It won't start in "headless mode" either.

This problem is before the 3D drivers load, even before the VM 'hardware' gets created. The signing-failing host 'Shell32.dll' is getting in the way this time. Run the Admin command prompt 'sfc /scannow' and replace the hacked shell32.dll with the official Windows file. You won't be able to use the hacked dll.

[NoNameNeeded]

Ok, I've done that and, lo and behold, it works.
Both problems seem to be solved now.

Who would have thought that?

I mean, I certainly didn't ruin my shell32.dll file, it's been working fine all along.
And it's not even a file that comes with a digital signature so I don't know why Virtual Box wouldn't want to use it.

Anyway, thx for your help.
I really appreciate it.

[scottgus1]

Awesome! Glad you're up and running!

I'm not sure about the signing question on the Windows dll. I never dug into the whole signing thing, only how Virtualbox needs a valid signature for each dll that interfaces with it. If there is a signature somewhere that gets checked, a single bit changed in the file invalidates it against the signature.

[fth0]

FWIW, the authenticity of the shell32.dll file can be verified with a digital signature in the file itself or with a digitally signed Windows Catalog (CAT) file containing a hash of the file or with both.