Insider build 14328: VB won't start at all

[AndyMidd]

Oh no: Windows 10 build 14328: VB wont start. Again, 5.0.18 worked on the previous build; more hardening? Why did I update?

Faulting application name: VirtualBox.exe, version: 5.0.18.6667, time stamp: 0x5714e21a
Faulting module name: VirtualBox.exe, version: 5.0.18.6667, time stamp: 0x5714e21a
Exception code: 0xc0000005
Fault offset: 0x00000000000137e2
Faulting process ID: 0x3340
Faulting application start time: 0x01d19ccb1634e692
Faulting application path: C:\Program Files\Oracle\VirtualBox\VirtualBox.exe
Faulting module path: C:\Program Files\Oracle\VirtualBox\VirtualBox.exe
Report ID: 993d5b7c-3e8b-4a41-8c49-4575aa1e8391
Faulting package full name:
Faulting package-relative application

To be fair: Neither will "TaskHost.exe".

The hardening Log file to follow, once I figure out how.

No Hyper-V.

Intel I3-4130. Loads of SSD. 8GB. 64Bit host/client.

[Jacob Klein]

Oracle:

I can confirm that VirtualBox is not starting, on Windows 10 Insider Build 14328.
See the following 3 versions, and their error info pulled from Event Viewer.
Please fix as time allows.

Thanks,
Jacob Klein

Oracle VirtualBox v5.0.18 Build 106667
Faulting application name: VirtualBox.exe, version: 5.0.18.6667, time stamp: 0x5714e21a
Faulting module name: VirtualBox.exe, version: 5.0.18.6667, time stamp: 0x5714e21a
Exception code: 0xc0000005
Fault offset: 0x00000000000137e2

Oracle VirtualBox v5.0.19 Test Build 106806
Faulting application name: VirtualBox.exe, version: 5.0.19.6806, time stamp: 0x5719dfd6
Faulting module name: VirtualBox.exe, version: 5.0.19.6806, time stamp: 0x5719dfd6
Exception code: 0xc0000005
Fault offset: 0x00000000000137e2

Oracle VirtualBox v4.3.38 Build 106717
Faulting application name: VirtualBox.exe, version: 0.0.0.0, time stamp: 0x57167a8a
Faulting module name: VirtualBox.exe, version: 0.0.0.0, time stamp: 0x57167a8a
Exception code: 0xc0000005
Fault offset: 0x0000000000016b02

[rseiler]

rseiler / TheUntouchable:

The startup problem with Windows 10 Insider Build 14328, while looking similar to prior problems, is actually a different problem than the one in [the 14291 thread]

How so?

[Jacob Klein]

It's different, because the last problem was patched, with Test Builds and an official release, that made it work for the Insider builds at that time. This new Insider build changed something else (or possibly the same thing), and that requires a new patch from Oracle to fix it.

You can expect this behavior (New Insider build changes cause VirtualBox not to start), so long as VirtualBox insists on no workaround for disabling their Windows process hardening features, while Microsoft changes whatever structures Oracle is using for security verification. It's a maintenance-heavy situation that Oracle has put itself into, here, in my opinion. We just have to be patient, I guess. Super frustrating

[rseiler]

Oh, OK, I thought you meant that it was actually a different problem, not just that the build had changed. I think it's highly likely that it's the same thing that's causing this problem, since this tune is very familiar by now.

I wonder why Vmware (apparently) doesn't see the need for the hardening feature if it's so important that Oracle enables it with no way to disable it? Maybe they just do it in a different way.

[michaln]

I wonder why Vmware (apparently) doesn't see the need for the hardening feature if it's so important that Oracle enables it with no way to disable it? Maybe they just do it in a different way.

As far as we know, they just don't do it. Users are welcome to find out whether it's possible to break into VMware's VM process (which talks to the kernel driver) with a debugger or inject a nasty DLL into it.

Several possible reasons:

1) Since VMware doesn't publish their code, security flaws are much harder to find
2) Since VirtualBox is installed on far more systems, it's a much more interesting target than VMware products
3) Because of the way VMware VM processes are structured, the GUI process does not have to be secured

Hardening is important to Oracle because security researchers published methods to attack hosts with VirtualBox enabled. Oracle can't very well remove hardening or make it optional in a world where security researchers decide what's important and what's not.

[Jacob Klein]

While I understand the security impacts, please consider this:

When Windows Defender causes problems, or false positives, I have options to add exclusions to processes/files/folders, and to even disable real-time-protection, temporarily or even permanently.

It would be nice if I, the user in charge, had a VirtualBox option to disable the VirtualBox hardening logic, when it causes me grief. It is quite a hassle to keep relying on alternatives when it stops working correctly on Insider builds, even though I know that running Insider builds is not a supported configuration.

One final note: I'm trying to inform here, not complain. I've got good workarounds that are working for me - dual booting all 4 of my PCs back to a "Windows Release" partition when VirtualBox breaks after a new Insider build is released on my "Windows Insider" partition. I'm simply suggesting that a better workaround, for me and several others, would be a way to disable the VirtualBox hardening until it can work correctly, on my "Windows Insider" partitions.

Regards,
Jacob

[michaln]

This has been discussed to death but...

The problem is that hardening is meant to guard against malicious users and user-level malware gaining system-level privileges. So once such a switch is in place, the first thing any malware will do is turn it off, and we're back at square one. And no, we can't trust the Administrator either, just like Windows itself doesn't. If you know of some 100% bullet proof mechanism that can't possibly be exploited, let us know, because we currently don't.

Really, the best thing you can do about this is look at the Unix security model, then at the Windows security model, and then weep. The saying that "those who do not understand Unix are condemned to reinvent it, poorly" unfortunately applies here far too much to be funny. For the last 15 years Microsoft has been hard at work battling its own legacy, and making progress, but it's really difficult for them to do without breaking everything. Just look at those unsigned DLLs injecting themselves into every process left right and center. (But do not look at 3rd party Windows AV software on empty stomach.)

[cKleuser]

This has been discussed to death but...

The problem is that hardening is meant to guard against malicious users and user-level malware gaining system-level privileges. So once such a switch is in place, the first thing any malware will do is turn it off, and we're back at square one. And no, we can't trust the Administrator either, just like Windows itself doesn't. If you know of some 100% bullet proof mechanism that can't possibly be exploited, let us know, because we currently don't.

Really, the best thing you can do about this is look at the Unix security model, then at the Windows security model, and then weep. The saying that "those who do not understand Unix are condemned to reinvent it, poorly" unfortunately applies here far too much to be funny. For the last 15 years Microsoft has been hard at work battling its own legacy, and making progress, but it's really difficult for them to do without breaking everything. Just look at those unsigned DLLs injecting themselves into every process left right and center. (But do not look at 3rd party Windows AV software on empty stomach.)

KUDOS for you man.... Best post ever!!!! AHhaHAhAhAhAahahaah

[SoulRaven]

Hello,
any news or ideea when a patch will be released?

[hnkumar]

Any idea on when new patch will be released. Now I stuck with Insider Build 14328 (I cannot able to uninstall latest updates) and I cannot able to access VirtualBox. Quick fix at least solve my problem

[dbrown]

ETA on a fix?

[dbrown]

FWIW, I tried updating to 5.0.19 (there were some other threads that indicated this might fix the problem).
No luck.

[Jacob Klein]

FWIW, I tried updating to 5.0.19 (there were some other threads that indicated this might fix the problem).
No luck.

The 2nd post in this thread indicates that "Oracle VirtualBox v5.0.19 Test Build 106806" does not fix the issue.

Though, as new Test Builds are released, it's a good idea to test them.
They can be found here:
https://www.virtualbox.org/wiki/Testbuilds

[SoulRaven]

Right, but no test builds are released yes, still 6806....