Windows 4.3.16 specifically for errors due to security

[RelakS]

Now, with the test build 5, I have

1: a BSoD
2: a not too informative startup log...

On Windows 7 SP1 64bit with McAfee pack: Host Intrusion Precention 8.0 (8.0.0.2151), McAfee Agent 4.6.0.3122, Endpoint Encription Agent 1.2.1.315, Endpoint Encryption for PC 6.2.1.315, GTI Proxy Agent 1.1.0.550, Virus Scan Enterprise 8.8.0 (8.8.0.849)
VM extension pack 4.3.10 r93012

[quiettime]

Test build #5: https://www.virtualbox.org/download/tes ... 26-Win.exe

Changes since test build #4:
- Fixes problem on windows 8.1, especially for symantec endpoint protection users (but also avast and others).
- General improvements (hopefully).

Would be great if as many as possible could give this build a spin, even if things works for you already. (Consider it a 4.3.18 release candidate.)

@bird Hey thanks for your work on this. You might remember I was one of the people with a weird apiport object mismatch. I installed your build #5 and a reboot was required. After I rebooted I tried to start a VM but received a message that vboxdrv was not working and suggested I run sc query vboxdrv so I did and it said the service doesn't exist. So then I ran the installer again and chose repair. After that I was able to start a VM and everything appears to be working. This is with a Windows 7 x64 host.

[rexcat]

Uninstall the older version, reboot several times, and then install the new version and still cannot run VirtualBox.exe.

[mpack]

Now, with the test build 5, I have
1: a BSoD
2: a not too informative startup log...

Please provide details of the BSOD, including whether you mean a BSOD on the host or the guest. Also, if it's the guest that's BSOD'ing then presumably that means the VM started, and you can provide the VM log.

[Scrotos]

Odd situation. Built two identical machines. Win7 x64 Pro, patched to the latest. Symantec Endpoint Protection 12.1.3001.165. Installed VB under domain admin users, attempting to run under regular users.

4.3.16 installed on one, ran, running the VM caused it to keep throwing exceptions. Mouse was all spotty. Updated that to 4.3.17-96342 and it works fine.

On the other, just installed 4.3.17-96342 from the onset. It loads fine if the users are domain admins but not as regular users. Just tried 4.3.17 r96426 and get the same hard crash. I could not find VBoxStartup.log anywhere on the hard drive on both this machine and another working machine. I assume maybe you mean VBoxSVC.log instead? The \.VirtualBox folder was never created in that user's folder so there are no logs.

What the user gets upon launch of the program is this:

VirtualBox - Error In VirtualBox
WinVerifyTrust failed on stub executable: WinVerifyTrust failed with hrc=CERT_E_REVOCATION_FAILURE on '\Device\HarddiskVolume2\Program Files\Oracle\VirtualBox\VirtualBox.exe' (rc=-22919)

Please try reinstalling VirtualBox.

-------------

We've reinstalled VB a few times to no avail. I am unsure if this is related to "security" but since the other identical machine had VM exceptions and crashes on 4.3.16 and that was fixed with the 4.3.17 test build we tried, I'm assuming it's related.

I just updated from 4.2.x to 4.3.17 r96426 and didn't have any problems. Didn't have any VBoxStartup.log either.

-------------

Update while writing this. There's apparently some GPO being set that's messing with us. Why it's being set for one user/machine and not another, I have no idea. Here's background: msdn . microsoft . com/en-us/library/windows/desktop/aa387700(v=vs.85).aspx Scroll to the bottom to see some of the values. The fix is this:

setreg 5 true

5 - Offline Revocation server OK (Commercial)
If TRUE, allows offline approval for commercial certificates. The default is TRUE.

I'm leaving this here in case someone else runs across it thinking it's "security" related. I suppose it is, to an extent, with the certificates and all, but I don't think it's a VB issue.

[spider38]

Hi All!

Test build #5 is finally here, been working around the clock for since last week on this. It include some radical changes to the code that has been running head first into several antivirus/antimalware/firewalls/quickcam/protection software. The changes should better contain the conflict situation, ruling out a lot of annoying factors. (For the curious, I've moved the securing of the VM process and opening of vboxdrv till before NTDLL.DLL is initialized. Not pretty, but hopefully efficient.)

Test build #5: https://www.virtualbox.org/download/tes ... 26-Win.exe

Changes since test build #4:
- Fixes problem on windows 8.1, especially for symantec endpoint protection users (but also avast and others).
- General improvements (hopefully).

Would be great if as many as possible could give this build a spin, even if things works for you already. (Consider it a 4.3.18 release candidate.)

Enjoy,
bird.

@bird - test build #5 works for me, I am now able to start my VM.

Windows 7 Professional SP1 + Avast

[rnewman]

Windows 7 Professional SP1 64bit
TrendMicro OfficeScan 11.0.1454
Virtualbox 4.3.17 test build #5

No logs to attach as none were created.
GUI manager starts. However when an attempt to start any VM, the system hangs then reboots.

[Redbyte]

Host: Windows 8.1 Pro x64 fully updated (build 9600)
Version: 4.3.17-96101
Anti-Virus: Symantec Endpoint Protection v. 12.1.4013.4013

Error: Error in supR3HardendedWinVerifyProcess
Failed to verify process integrity:(rc=-5662)

Extra files and logs are in zip

With test build #5 4.3.17-96426 I am no longer getting errors and am able to use VirtualBox normally

[Petr Vones]

For the curious, I've moved the securing of the VM process and opening of vboxdrv till before NTDLL.DLL is initialized. Not pretty, but hopefully efficient.

All these hacks into PE loading and DLL initialization have single common issue - it can never work reliably. Especially some calls like reading from the registry and so on are not recommended in this stage for ages (read for existence of Win32 API). Again, with proper Software Restriction Policy setup (and using limited user account to run VirtualBox, of course) there is no chance that a "bad" DLL is loaded into (any) process by design.

[Docfxit]

I have installed Test build #5: 4.3.17 r96426

I have reported this problem earlier.

I'm having trouble running the Vboxheadless. The command window opens. The Vbox window doesn't open

If it would help you are welcome to remote into this computer to see what is going on. Just let me know your favorite remote control program.

Do you have a favorite trace/debug program that might help figure out what is going on? I'm happy to run it if you like.

Is there any other way I might be able to help figure this out?

Thank you,

Docfxit

[bird]

@Docfxit: There isn't anything obvious in the VBoxStartup.log. The minidump seems to be of the first or second VBoxHeadless.exe process, there are three of them if you get VBox.log output. So, switch process explorer into tree view and minidump the deepest of them. (Alternatively just dump all three.)

@Mucky: Still no luck reproducing the evil handle error. But I'll post a new test build in a few hours with improved error reporting. So, please try test build #6 when it's ready.

@RelakS: It's really tedious to try replicate your environment... End-user McAffe products work fine, and so does the enterprise versions setup we have on our oracle PCs (to my knowledge). Would be real cool if you happened to have a (system) minidump from that BSOD or any other information (screen shot, log entry, whatever)...
@rnewman: Been unable to reproduce that issue locally (recreating your environment is also difficult for me). Would be really cool if you happened to have a (system) minidump from that BSOD or any other information (screen shot, log entry, whatever)...

@quiettime: Sounds like we've got an installer problem or two wrt vboxdrv installation... Will investigate.

@Scrotos: Nice work figure out that CERT_E_REVOCATION_FAILURE error! ( http://msdn.microsoft.com/en-us/library ... 85%29.aspx )

@Petr Vones: May the (vbox) source be with you the next time.

@Peter_at_Work: Glad to hear your problems are fixed.
@GlennChugg: Very good to hear it's also working on windows 10.
@spider38: Excellent.
@Redbyte: Cool!

-bird

[Krynos]

Test build #5: 4.3.17 r96426 is the first to actually successfully launch a VM for me on a machine running Windows 8.1 pro and Symantec Endpoint Protection version 12.1.4013.4013; good job! Keep up the great work!

[RelakS]

Now, with the test build 5, I have
1: a BSoD
2: a not too informative startup log...

Please provide details of the BSOD, including whether you mean a BSOD on the host or the guest. Also, if it's the guest that's BSOD'ing then presumably that means the VM started, and you can provide the VM log.

The host had the BSoD, when I wanted to start a virtual machine. Unfortunately I did not make a picture about the program what was reported on the blue screen.
After installing 4.3.10 everything is working again, so no harm were made to the VMs or to the Host.


@Bird: yes, I can understand, the Host is a company image with inhouse configuration. I even have to use vbox for works that I inteded to do on the Host simply because the device driver killed the Host, but it ran flawless in a clean Windows 7. I am rather busy now, but whenever I will have time to play around, I will install the #5 (or the actual latest) again, because it is strange that I had to repair it to be able to remove. Some component were missing, but I did not record that too...

[Docfxit]

@Docfxit: There isn't anything obvious in the VBoxStartup.log. The minidump seems to be of the first or second VBoxHeadless.exe process, there are three of them if you get VBox.log output. So, switch process explorer into tree view and minidump the deepest of them. (Alternatively just dump all three.)

Thank you for looking at it,

Docfxit

[rexcat]

Today's test, the system is still Windows 7 SP1 (already uninstalled all the security software), is installed after the Test build # VirtualBox.exe is still unable to run (annex 1:dump file). However, VirtualBox.exe compatibility mode is set to 'Windows after 7', VirtualBox.exe running, but running the VM complains (annex 2:log file and dump file)