Announcing Windows 10 Insider Preview Build 16179 PC + 15205 Mobile Insider

Fafhrd said:

Testing a new IP build on those commonly available VM systems, especially Microsoft's own Hyper-V, is something that must happen in the MS Windows development labs hundreds if not thousands of times before the next new build is released to the general mass of those on the Insider Program, and that is probably why Kari can guarantee that an upgrade performed in a VM will work.

However, IMO, that is not what the Insider Program is really about - repeating the work already carried out.

I feel that it should be a test on a sample of the general population of machines, old, new, perfect and faulty, overclocked and underspecified, warts and all, and definitely never likely to be seen anywhere near the Microsoft Windows development labs, and not on a batch of behave-alike virtual machines with a small range of virtual components and devices that only exist in the VMs themselves.

Wynona said:

Maybe that's why I was told it's best to test on a physical, rather than virtual, machine.

Another one here with the same opinion. (Not that I would intend to criticize anybody who runs IP in VM...)

AndreTen said:

Another one here with the same opinion. (Not that I would intend to criticize anybody who runs IP in VM...)

Hmmmmm, it seems I'm not as much in the minority as I thought, Andre.

Guys really, I admit I made a terrible mistake by suggesting how to get the upgrade for 100% sure using a VM, then upgrading your physical PCs with ISO made on that VM. I have already apologized for that. I repeat that I have never said you should do your testing on a VM, just that you would get the ISO made with that method.

That being said, could someone please explain it to me what's wrong in using virtual machines also for testing Insider builds? Where can I find and read these rules liike that you should not test clean installs only upgrades (also mentioned in these announcement threads), or that testing on VM is wrong, that we should test on physical machines only?

Trying to upgrade my Toshiba laptop from 15063.138 to 16179.1000 and getting a 0x8000000a error when I try to restart. I'll try it agian in a bit. First I'm running CCleaner to get rid of temp files, including Windows.old from the 15063 upgrade then exiting programs like Classic Shell, CCleaner, Everything Search, DesktopOK.

Will see how it goes then. Space is not a problem as I have 80GB of 128GB SSD free.

Kari said:

Guys really, I admit I made a terrible mistake by suggesting how to get the upgrade for 100% sure using a VM, then upgrading your physical PCs with ISO made on that VM. I have already apologized for that. I repeat that I have never said you should do your testing on a VM, just that you would get the ISO made with that method.

That being said, could someone please explain it to me what's wrong in using virtual machines also for testing Insider builds? Where can I find and read these rules liike that you should not test clean installs only upgrades (also mentioned in these announcement threads), or that testing on VM is wrong, that we should test on physical machines only?

I have no really strong feelings to VM or not to VM. I simply don't use it because I have two computers (used to have six or seven) on which to test. I have an SSD somewhere in the neighborhood of 500 GB and another 240 GB one that's inside the case but not connected. Lappy has a 240 GB SSD also. I dual boot the desktop with Build 15063 and Insider Builds; Lappy is a dedicated Insider Program computer. I have no need to use a VM of any type.

That said, there may come a time I will want to check it out further; I at least know how to set up Hyper-V.

Besides, with summertime coming soon, I don't have the time to spend on more than I have set up for testing. Too many outdoor activities require my time, as well as my husband.

Ztruker said:

Trying to upgrade my Toshiba laptop from 15063.138 to 16179.1000 and getting a 0x8000000a error when I try to restart. I'll try it agian in a bit. First I'm running CCleaner to get rid of temp files, including Windows.old from the 15063 upgrade then exiting programs like Classic Shell, CCleaner, Everything Search, DesktopOK.

Will see how it goes then. Space is not a problem as I have 80GB of 128GB SSD free.

No help. Failed this time with a 0x80010105 error. Anyone have any suggestion?

I'll add the specs for the Toshiba laptop as System 3 in a minute.

Nope, only two allowed.

Toshiba A305-S6872
Intel Core Two Duo 2.0Ghz
4GB RAM
128GB Kingston SV20053128G drive 87GB free
Win 10 Pro X64 15063

Wynona said:

I have no really strong feelings to VM or not to VM. I simply don't use it because I have two computers (used to have six or seven) on which to test. I have an SSD somewhere in the neighborhood of 500 GB and another 240 GB one that's inside the case but not connected. Lappy has a 240 GB SSD also. I dual boot the desktop with Build 15063 and Insider Builds; Lappy is a dedicated Insider Program computer. I have no need to use a VM of any type.
That said, there may come a time I will want to check it out further; I at least know how to set up Hyper-V.
Besides, with summertime coming soon, I don't have the time to spend on more than I have set up for testing. Too many outdoor activities require my time, as well as my husband.

My reason for using Hyper-V actually goes back to the initial builds of WinX, and my tale of woe.

My mobo is an eVGA X58/ICH10R Classified 3 motherboard, which has some fantastic features, but which the eVGA team really screwed the pooch with when ti comes to the BIOS. When WinX first came out and I was testing TP2 hard on my machine as a dual boot, then running an Intel 180 GB SSD + an Intel 80 GB SSD, so all my VMs would have to go to one of my spacious mech HDDS, I found that I could not run Hyper-V. I would get all sorts of errors about Virt Tech not being enabled. But I build my own machines, and I know it is - and doubled checked in the BIOS to make sure.

It turns out there was a bug introduced in the BIOS somewhere around late 2009 or early 2010 that was never fixed - in that if you enable the VT setting in BIOS, it actually disabled it. And vice-versa. So, with it enabled in BIOS< Steve Gibson's little freeware utility securable shows vt (aka hardware virtualization) as being disabled. If I disable it in the BIOS, then securable shows it as enabled.

However, for whatever reason, earlier builds of WinX were also checking the BIOS for the setting (at least that is my theory) because when I had it turned off in the BIOS, and I enabled Hyper-V in Windows additional features, my machine broke - as in black screened and / or BSOD and refused to boot from that point on. But if I had it enabled in BIOS, then Hyper-V broke and would not run, claiming vt was disabled.

So, I gave up on VMs using Hyper-V for a long time.

Then I came back around here about a year ago and saw Kari doing what he was doing, and without any thoughts about it, I fired up Hyper-V in whatever current build I was running then and it just worked.

I was re-introduced to the foibles of this mobo recently when I tried to boot the RemixOS player to run Android within Windows - it gave me the same runaround, and it took me a couple of days to remember all of this from the past.

My machine is not a beast anymore - it is 7 generations behind in terms of CPU family, and only has 12 GB of RAM, so I run 1 VM at most on the system at any given time, but it has made software testing, for me, a lot easier, since I can have dedicated VMs for various software that I only fire up when needed for this or that test. All of these software tests, BTW, are being conducted on IP builds, with the exception of one, which I was hardcore testing last weekend on CU.

I have another desktop machine that I could take the time and put back together, using the old Intel SSDs for testing, and I have 2 laptops besides that I could test on - but it is a lot easier for me to test using one set of KB, mouse, and monitors rather than trying to move around and such, for me. Plus, having used Synergy, Multiplicity, and even Mouse without borders, I can say almost unequivocally, that there is no real substitute for a true hardware-based KVM.

So, that, plus the fact that I was like a kid in a candy store when I fired up Hyper-V and it just worked, have kept me stuck to using it.

My next build it going to be as modern of a build as I can get it to be (I have good storage, in 1 Sandisk 1TB SSD, 1 Crucial 240 GB SSD, 2 Seagate barracuda 1 TB mech HDDs and 1 Seagate 500 GB mech HDD, and my GTX 970 is more than sufficient for my gaming needs, so I can build up to a new machine on the cheap - only CPU, mobo, RAM and (optionally) case and PSU (I have a ThermalTake Tr2 BlackWidow 850W PSU, which should be fine for newer CPUs even with gobs of RAM thrown at them), but until then, this desktop is what I got - because the laptops are painfully slow (even with both having SATA II SSDs installed) at running Windows alone, forget anything else. And the old machine? Well, that is an nVidia 680 based mobo that uses a Core2Quad 6600 CPU (and this is what I expect Windows to look at my like if I were to try to run it as a daily driver on that machine: 0_o)

So, I have to agree with Kari to both counts: He did apologize for saying that the VM install was the only 100% reliable way to build an ISO, but he also never said hat VMs were the only platform for testing IP builds, and I agree with his outrage that someone suggested that VMs are, in fact, not a good platform for IP build testing.

My VMs take it to another level though - because I'm IP build testing on VMs whose host is also the current IP build lol.

Anyhoo, that's my soliloquy.

Ztruker said:

No help. Failed this time with a 0x80010105 error. Anyone have any suggestion?

I'll add the specs for the Toshiba laptop as System 3 in a minute.

Nope, only two allowed.

Toshiba A305-S6872
Intel Core Two Duo 2.0Ghz
4GB RAM
128GB Kingston SV20053128G drive 87GB free
Win 10 Pro X64 15063

I use disk cleanup, but I've noticed that any time I've done so and the build was already released, I've started to get issues. I've resorted to either running disk cleanup the day after the build has been released and installed on my machine, or I don't bother running disk cleanup at all - after all, who knows WTH WU might be downloading in the background that I delete using the cleanup, only to confuse WU (again).

I always do a disk cleanup but only after I have imaged the new build (that's on the physical machine). Given the amount of disk space that windows.old takes plus the ability to snapshot VM's I can't see a reason to keep it around. This post sent from a Windows 10 Professional Virtualbox VM running on Windows Server 2016 after its been copied from openSUSE. I used to do that with the VMware VMs that could run on Workstation for Linux and Windows but I have not found anybody whose been able to hack the Workstation source files to run on openSUSE Tumbleweed - especially with the latest kernel (4.11rc7) that I'm using. I'll be booting in Windows 10 in a bit and get with installing my programs on the the 16179 build. And I have found, like Kari, that creating an ISO on a VM is quite convenient.