Windows 10 Build 14267 VirtualBox error

[drbohner]

Update - Restoring to the previous release does resolve the issue (but who knows which ones it will now create)...

- Windows Settings (the Gear)
- Go to 'Update & Security'
- Select 'Recovery' on the left pane
- Select 'Go back to an earlier build <Get Started>'

Report the issue in the provided box (so M$ will get spammed by us loyalists)

It took less than 30 minutes for my machine to roll back - your mileage may vary.

(db)

[eltoddo]

That's 8 hours of my life I'll never get back...

Tried working around the issue by exporting a VM I needed for work to VMWare Workstation 12 Player. Made the mistake the first time of making an OVA 2.0 archive. After the 1 hour export (100GB VM disk), there were multiple failures trying to import VM to VMWare. I finally managed to import it in as OVA 1.0 ovf export. Then the fight with VMWare Tools began. After spending hours attempting to resolve that and failing, I saw that drbohner had success in rolling back Windows to previous build.

My rollback was done pretty quick, but not without problems on the far side. Windows doesn't think Chrome is installed anymore, and Outlook is having problems opening its mail folders (fixed by reboot).

...but VirtualBox is working again! Thanks for the pro-tip on the rollback, drbohner.

[Jacob Klein]

The following Test Builds, released today, still exhibit the same issue:
Oracle VirtualBox v4.3.37 r105613
Oracle VirtualBox v5.0.15 r105651

[AntonioRibeiro]

Is this something that should be fixed on Windows or Virtualbox? This error, AFAIK, is coming and going a while now... Tweeted Gabriel Aul and he said the team is looking into it, but still, the way things are going, it looks like something we will see coming back after the next fix, over and over...

[michaln]

If Microsoft keeps breaking VirtualBox with every new build, Oracle can only fix it after the fact. And Insider builds are definitely not high priority since it's impossible to have them as a supported platform for customers. A bit of a vicious circle.

So... please tell Microsoft that this is a problem for you. If they need us to change something, they know how to reach us. But so far we only get "it's broken again" reports from users, and at that point it's really too late.

So far VirtualBox users have been generally "voting with their feet" and not upgrading to Windows 10. There's absolutely no comparison of the uptake of new OS versions between OS X and Windows users.

[Jacob Klein]

michaln:

Can you confirm that your Windows process hardening is only calling documented supportable API calls, and that it's built to handle/support/process newer versions of core Windows dlls as they come about?

What I'm getting at, is that it seems like it's very fragile, and the common user has no idea who would be at fault. It would be helpful for us to at least know that you (the devs) believe you have done everything correctly.

Thanks,
Jacob

PS: I especially want to express gratitude for letting us have a place to document the problem, here in this subforum. Thank you.

[bird]

I have to admit that we are using some APIs that aren't all the well documented, however this has so far never caused anyone any problems!

The code is sensitive to some things that Microsoft may do to the extremely early process initialization (basically, what's done from the kernel side before the process actually starts running), but we do not expect this to cause a lot of trouble as Microsoft so far has been very careful with their changes. I think thus far there might have been one instance of this, where we needed to adjust our code to deal with Microsoft modifications to Windows 10. (The problem we had a while back with a Microsoft timestamp server update that triggering an overly strict input check in the code parsing authenticode signatures was a naturally our fault, not Microsoft's.)

Our main problem is with the wealth of "protection software" out there which attempt to make intrusive changes to our process, changes which are extremely hard to distinguish from malevolent software.

-bird

[Jacob Klein]

Well .. considering that Microsoft is making changes to how process memory gets handled (compressed when applicable), it wouldn't surprise me if they're also making changes to process initialization.

So long as you're using published supportable API calls, then all I can do (as a Windows 10 Insider enthusiast) is document the errors, and only expect a fix at the time the Windows 10 Insider changes get released publicly (or preferably a little bit before). Others here may not understand that, but I do. It's unfortunate, because VirtualBox is literally the only program that continues to have problems for me, with Insider releases.

It would be helpful if you could perform a preliminary investigation each time it breaks, to determine whether it looks like the fix will necessitate a code change on your part or not. ie:
a: Did Microsoft do something wrong (which will likely get fixed in a newer Insider build), or
b: Did Microsoft change how something is done, and Oracle will need to account for it with a code change to VirtualBox
... but I completely understand if you're not even willing to do that. But bear in mind, people are using these Insider builds, and they have certain expectations.

In the meantime, I will continue to use my Windows 10 Release partition as needed, whenever VirtualBox breaks. I do BOINC work, on RNA World VM tasks that take months of processing time to complete, and it relies on VirtualBox.

[rseiler]

Unlikely to make a difference, but 14271 is out:
https://blogs.windows.com/windowsexperi ... 14267-1004

[bird]

We do try keep up with the issues. However, as most of us wishes to debug VBox rather than Windows 10, all our Windows 10 development are using the stable version that most users use. So, it may take a little time before we update the test boxes we've got on the fast and slow windows insider rings and figure out that something is broken and why.

So, we're very thankful for info about new slow-track and to some extend fast-ring builds causing trouble for us. (The reservation about the fast-ring is that we've had one or two examples on Microsoft fixing a problem in the next build. And while it's always interesting to see what Microsoft is experimenting with in a fast-ring build, there are only 24 hours in a day.)

-bird

PS. Just to underline why we don't develop on slow/fast ring boxes, my favorite slow ring box won't update anymore and consistently fails with 0x800700c1, which looks like the COM version of ERROR_BAD_EXE_FORMAT.

[Jacob Klein]

Thank you, michaln and bird. It is reassuring to have devs say "we do care", especially when the fixes might be a ways out.
PS: No-ones asking you to necessarily develop on a slow/fast ring... but it can be very helpful to have dual-boot setup to troubleshoot

[bird]

Uploaded a test build with a fix: https://www.virtualbox.org/download/tes ... 93-Win.exe
Hope it works for you guys as well.
-bird

[Jacob Klein]

Uploaded a test build with a fix: https://www.virtualbox.org/download/tes ... 93-Win.exe
Hope it works for you guys as well.
-bird

Thank you!! However... I need 4.3.x.
Is there any chance for a 4.3.x test build, please?

[rseiler]

Uploaded a test build with a fix: https://www.virtualbox.org/download/tes ... 93-Win.exe
Hope it works for you guys as well.
-bird

Thanks, it works in 14271. I just had to remember to remove the extension pack and disable USB 2.0 in the VMs, otherwise, because of an extension pack mismatch, you're stuck.

[Heldchen]

VirtualBox r105696 with ExtPack r105651 on the newly released insider build 14271 works for me. thanks bird!