Can't Boot Windows 10 Insider Preview From ISO

[RavingCustody4]

I can't seem to figure out how to boot the ISO located at the following directory:

/(Beta) Operating Systems/PC/Microsoft Windows 10 (''Redstone'')/10.0.14351.1000/10.0.14351.1000.rs1_release.160519-1741_x86fre_client-professional-core_retail_en-gb

When I tried booting it with VMWare Workstation, I got the standard blue windows logo for about 0.5 seconds and then I got a permanent black screen with a non-blinking underscore in the top-left corner of the screen. I tried using SCSI and IDE virtual hard disks with the same result.

When I tried booting it by mounting the ISO on an already working Windows 10 guest OS and running 'setup.exe', I get the following error:

The operating system couldn't be loaded because the digital signature of a file couldn't be verified
File: \windows\system32\ntoskrnl.exe
Error code: 0xc0000428

To get past the error, I tried permanently disabling signature enforcement on the guest OS by setting the "nointegritychecks" and "testsigning" bcd options on. Even with these options turned on, I still got the same error. BTW, my guest OS has legacy boot mode so I didn't have to turn off Secure Boot to set those bcd options on.

I suspect that, instead of disabling signature enforcement on the guest OS, I should be doing it on the OS I'm booting into. I just see no easy way of doing that. Perhaps by editing the bcd file on the ISO in the boot directory? It just seems like too much work.

Any ideas?

[Wheatley]

Did you set the BIOS date?

[RavingCustody4]

BIOS system time and date is current.

[AlphaBeta]

BIOS system time and date is current.

You're hitting the timebomb - set the BIOS date to 20 May 2016.

[RavingCustody4]

BIOS system time and date is current.

You're hitting the timebomb - set the BIOS date to 20 May 2016.

Thanks a lot, AlphaBeta! This led me down a path of success. For the sake of those who would like to reproduce my steps:

Method 1 (Boot and Install OS onto Freshly Created VM) (FAILED)
=========================================
1. Created a new VM that set to boot from ISO and I booted into the BIOS.
2. Changed BIOS time to 20 May 2016.
3. Screen displayed following error message:

File: \windows\system32\winload.exe
Error code: 0xc0000428

4. Noticed BIOS time had been reset back to the current system time, so I changed it back to 20 May 2016.
6. Screen displayed following error message:

STOP code: PROCESS1_INITALIZATION_FAILED

7. Gave up and tried second method.

Method 2 (Install OS on Windows 10 Guest VM) (SUCCESS)
=====================================
1. Disabled Early Launch Anti-Malware Protection on Guest VM (this is in addition to the bcd options I set in opening post)
2. Adjusted date time on host machine and guest VM both to 20 May 2016.
3. Mounted ISO onto guest VM and successfully installed the Insider Preview OS.

[AlphaBeta]

Instead of changing the date on your host machine you could have just disabled time sync.

[RavingCustody4]

Instead of changing the date on your host machine you could have just disabled time sync.

Yeah, I heard that some people didn't have the best of luck with that so I went for the overkill. I can afford to have my host have the wrong time.

[Wheatley]

Instead of changing the date on your host machine you could have just disabled time sync.

Yeah, I heard that some people didn't have the best of luck with that so I went for the overkill. I can afford to have my host have the wrong time.

I can safely claim most of the forum has had no trouble with changing time and disabling timesync on VMware products unless they failed to follow instructions. And no, you really can't afford that, not a radically different time anyway. If your time is wrong enough, your online experience will be certificate error galore among other issues...

[RavingCustody4]

Instead of changing the date on your host machine you could have just disabled time sync.

Yeah, I heard that some people didn't have the best of luck with that so I went for the overkill. I can afford to have my host have the wrong time.

I can safely claim most of the forum has had no trouble with changing time and disabling timesync on VMware products unless they failed to follow instructions. And no, you really can't afford that, not a radically different time anyway. If your time is wrong enough, your online experience will be certificate error galore among other issues...

It's good to know that most of the folks on the forum had no trouble with disabling tymesync. My host is actually offline. Are there any drawbacks to having a wrong time on a host machine that is not connected to any network?

[jman]

If your host time isn't right, anything that automatically enters time like the time-stamps on log files will be incorrect. Files you create will list as being created in 2016. It could potentially cause problems if you want to search for a file by date. Your calendar would also not work right. However, depending on what you are using the computer for, it might make no real difference at all.

[RavingCustody4]

Yeah, it turns out that I couldn't afford to have my host time be off, even with an offline machine.

Disabling time sync ended up working for me after all, but I did run into a few hiccups that may have been the same ones the folks who tried disabling it and failed dealt with.

1. I have VMWare Worksation, so all I had to do was edit the vmx file to have the specific fields present and their corresponding values set in the file. However, the edits won't be permanently reflected in the vmx file if there is a "...vmx.lck" directory present in the same directory as the vmx file. I had to power off the VM and close the VM tab in workstation to get rid of the lck first before editing the file.

2. Also, installing VMWare Tools on the guest VM eventually caused the VM's time to be sync'd with the host again. So I had to make sure that I didn't install VMWare Tools.

[whistler2250]

Yeah, it turns out that I couldn't afford to have my host time be off, even with an offline machine.

Disabling time sync ended up working for me after all, but I did run into a few hiccups that may have been the same ones the folks who tried disabling it and failed dealt with.

1. I have VMWare Worksation, so all I had to do was edit the vmx file to have the specific fields present and their corresponding values set in the file. However, the edits won't be permanently reflected in the vmx file if there is a "...vmx.lck" directory present in the same directory as the vmx file. I had to power off the VM and close the VM tab in workstation to get rid of the lck first before editing the file.

2. Also, installing VMWare Tools on the guest VM eventually caused the VM's time to be sync'd with the host again. So I had to make sure that I didn't install VMWare Tools.

Or, you could just read the guide found here at https://www.thecollectionbook.info/info ... bios_dates if you want to avoid that problem.