Venue 8 Pro (5830) BIOS update needed to fix microcode problems?

Just a warning: I've done a pile of research, so this post may get a little long, but I'm trying to document a possible bug and I want to give good information to developers. If anyone from Dell is browsing these forums, either (A) this is going to be as close to a bug report as I can do, so PLEASE do something or (B) this is just another strange issue just like those I usually seem to have.

My device is a Dell Venue 8 Pro 5830 32 GB. I've been having issues with installing the windows 10 update, as well as more recent windows 8.1 images as well. The device works fine under Linux (with some special considerations, I had to compile a custom kernel for the wifi and use a custom GRUB config to get things working), so I highly doubt that the issue is hardware based and unfixable (e.g. broken traces within the motherboard.) However, I have not seen anyone else having the same issue as me so it may just be an issue with my particular device, in which case I would be unsure how to proceed.

I've done a pile of research into the issue and possible causes/solutions, and have come up with many possible causes and possible solutions that have all failed.

Steps to replicate error:

1. From windows 8.1, attempt to install Windows 10 with "Get Windows 10" tool from Microsoft/Windows update.

1.b Just an FYI: I did a fresh install of windows previously, so I have enough disk space to install without a flash drive. However, just for testing, I have created multiple USB drives to install Windows 10 and all have failed with the same problem.

2. Upon the system rebooting the first time to install windows 10, I get the error "0xc0000017:Could not create ramdisk." I've looked this up and it looks like it's just a generic error, as there is more than enough RAM in the device. I even double checked this by installing Windows 10 in Virtualbox, extracting the .VDI image to a writable disk image, and then writing that image to the internal DV8P drive from within the Fedlet custom Linux bootable USB (If you don't know what that is, look it up.) Upon writing it (which took a total of about 4+ hours instead of 20 minutes as it should have, I think there's an oddity in the way that 3g-ntfs does blocksizing... anyways, other topic entirely) the system booted up, albeit without a registered Windows copy, which is why I had to wipe the drive again and put 8.1 back onto it (You need to go through the upgrade process for your key to upgrade from 8.1 to 10, so I'm stuck back at square 1.)

One of the solutions suggested at multiple sources all across the internet is that there is not enough contiguous memory, as some blocks have been marked as "bad" blocks, causing the error. However, after checking for bad blocks using the commands listed here I found there are no bad blocks listed under the bcdedit /enum all command, so I highly doubt this is the cause of the issue.

3. When the system boots back up to Windows 8.1 after the failed install attempt, another error comes up:

0xC1900101 - 0x20017

The installation failed in the SAFE_OS phase with an error during BOOT operation

I've had more luck looking up these error codes and finding causes. The best source I've found so far is a pair of articles on the Microsoft support forum talking about the issues, here and here. The second page has an interesting solution, which is to turn off overclocking and limit the CPU to one core, which is part of the reason that might tell us the cause of the issue. However, I attempted this method, and it again resulted in the same errors as before. Not wanting to give up so easily, I went into the UEFI BIOS and disabled everything- multicore, bluetooth, wifi, virtualization, etc. and it still did nothing. The thread also talked about disabling/changing the intel Microcode package within windows after installing W10, so as to not have the same error upon re-enabling multicore support.

However, if we move on to the other forum thread, we can find a solution that worked for someone which was also related to the intel Microcode package in windows- removing it from the install image entirely by mounting the install.wim and boot.wim images and going in and removing the mcupdate_GenuineIntel.dll (mcupdate = microcode update, GenuineIntel = intel processor, if it was AMD it would be AuthenticAMD) from the USB install images! I attempted this, but it still did not solve the problem (which doesn't surprise me, it's an unsupported fix and other people on that thread have reported that it did not work for them either.)

More discussion revealed that this problem with the microcode that seems to have cropped up during one of the earlier builds of Windows 10 Preview- 10130 to be exact, according to someone on the forums.

By complete coincidence, I happen to actually have 3 old 32-bit builds of windows 10 ISOs still on my hard drive- 9926, 10041, 10074- all three of which are before 10130. So, I flashed them to a USB drive and, though they refused to install because of unrelated reasons (the error code said something about "expired", which I'm assuming means Microsoft purposely had the install images pull the time and date from the bios to see if it was past a certain date and, if it was past a certain date, refuse to install, so people couldn't just pirate windows from these old images) but the point is the "cannot create ramdisk" error didn't come up, meaning the problem was not prevalent in these older images. More research by people on that thread shows that it probably is the microcode that was changed in 10130, causing the issue.

My theory of what happened from here is: these changes from image 10130 (which, since the Microcode is usually a proprietary binary blob from intel and packaged into windows by Microsoft, the problem may actually be from intel) just didn't get fixed and got put into the W10 install image we have today, as well as backported into the W8.1 reinstall image that you can download as well. The best guess I have is that the windows PE and the actual windows kernel/desktop are built differently enough that this only affects the windows PE (Preinstall Environment I think?) and not the actual installed environment, which is why I was able to run windows 8.1 and 10 from the internal drive by flashing the partitions extracted from the Virtualbox virtual machine images.

So, what's the fix then? The people in that forum thread mostly had it fixed by a UEFI/BIOS update from their manufacturers to fix this particular issue. Again, this issue might just be me, heck for all I know my multiple memory check operations may have just missed something, but I find that really hard to believe after so much testing and usage of the tablet over the last few months. So please, if you're having the same issue, comment below and let me know, I would really appreciate it!

If anyone from Dell could please take a look into this problem and make a UEFI/BIOS update to fix it, you would make me very happy! Thanks,

~Ben