Cannot boot - 0xc000000f / 0xc0000098

Hi there.

I am trying to get a working Win10PE SE bootable iso but so far no success.
I already tried a bunch of different sources but it didn't seem to change the end result so I stuck with one of the first sources that are actually recommended, the official list, from which I chose:
English (United States) x86:
10240.16384.150709-1700.TH1_CLIENTENTERPRISE_S_EVAL_X86FRE_EN-US.ISO
SHA1: AA8CE9CC9B660B31245622E49E0D183DB355558F

Okay, so the build went smoothly and I used all the defaults, the only thing I actually set myself was the source dir.
But so far every build has failed to boot, stopping at the "Windows Boot Manager" with an error explaining that the system was unable to load.
The error's info is pretty self-explanatory: The application or operating system couldn't be loaded because a required file is missing or contains errors.
Although not bringing me closer to understanding the problem...

The file which originates the error: \windows\system32\boot\winload.exe

The status code , depends... when using the iso with VMWare Workstation (v10) I got the status code 0xc000000f, using a physical machine returned the same error but with a different status code 0xc0000098.
Also tried qEMU, which froze at the grub4dos boot selection menu but then, using standard boot, sadly also returned that same error yet with a different status code: 0xc000000d.
Also, for the record, I have no anti-/virus/malware/spyware or sandbox enabled at the time of build. This problem, or a variation, has happened to me in the past with Win8.1SE but back then it was due to the source which was really messed up from customized slipstreams of updates, using an original MSDN usually did the trick. But this time I don't have a clue since you guys advise to use this very source. I've also read a few other forum entries related to this error on previous PE SE releases, but I reach the conclusion that often the problem lies there too with the source. On "physical" disks the problem usually is related to either a corrupt boot loader, a corrupt file system index/table or a failing disk altogether.

Anyway, I would be grateful if I could get some help to find out what's wrong here, maybe this has happened to someone else...

P.S: Attached log and pretty screenshot.

It appears your are trying to boot a UEFI system with legacy x86 PE..

Enable legacy Support / CSM support in the BIOS..

And use F12 boot menu to select the  Non-UEFI USB

First of all, thanks for the reply KYHI.

That could be an explanation, but in this case it isn't.
Afaik, VMWare (v10) and qEMU don't have UEFI support and my physical machine is booting legacy, UEFI doesn't get me anywhere either way.
I've tried my typical standard which is booting from syslinux and loading memdisk kernel with an ISO into RAM which has worked flawlessly for all other PE SE projects.
In any case, I went ahead and used Rufus to make a base bootable USB from that ISO, booted with legacy, but sadly I'm stuck in the same place as before.
I'm open to suggestions.

Even real Win10, FOR ME, sux in many ways (rights, permissions, etc , etc compared to being an Admin in Win7) and causes things that "don't work right" and give Access Denied and odd errors, that I never had in Win7 and WinXP running as administrator.  I avoided Win8 as much as I could.

Having said that, with what little I know, I would point out:

1) I wouldn't run Win10PESE in other than the real local hardware, at least until you can make a successful build with just the defaults.
   It sounds like you are running Win10PESE in a virtual machine, which I have never done. Note that the default settings will make an ISO file and
WON'T build to a 2-partition usbstick. You have to tell it that in WriteMedia. You'll get a usbstick that can both Legacy and UEFI boot.

2) If the local hardware is a x64 Win10 setup, get the x64 ISO. Win10PESE x64 gets some of its settings, locale info, etc from the local machine.
   Not all info comes from the SourceDiskFiles. Like  a "technician machine" in WinPE 3. (I would think the x86 version would do the same.)

3) If you are concerned about Win10PESE running directly on local machine, it does NOT seem to write anything to the registry that I have found.
   It stores settings in INI files. It does modify some of its own system files.  Assuming your Winbuilder folder is, say,  C:\winb, the entire
   setup is in that folder and can be deleted by removing that folder (and subfolders, etc)  and start from scratch again if you have to.

4) I have caused problems for myself by just TOUCHING anything more than setting the SourceDisk PATHS.  [changing Target directory, then
realizing you shouldn't and then changing it back again DOES NOT UPDATE THE UNDERLYING INFO, JUST THE DISPLAY.] I made that mistake too. 

5) Don't add any personal settings or scripts or plugins til you get a successfull build using the defaults. I also made this mistake by trying
to use Win7PESE x64 scripts that 'should have' worked, but were flawed in some way. (worked ok in Win7PESE but barfed during Win10PESE build!)

6) Always do at least one format of any usbstick you plan to use to store your build. Win7PESE-formatted usbsticks WILL NOT WORK FOR ME in
Win10PESE until I reformat it once, in Win10PESE. Don't know why. Yep, made this mistake more than once also.

Hi Tony4219, thanks for your reply.
I know that Windows 10 has it's faults and like yourself I pushed the usage of Windows 8/8.1 out of view which landed me in Win10 from Win7.
That being said, I'm pretty content with Windows 10 and did not have yet had the displeasure you seem to have experienced.
Have been using it for about 6 months now and it was an upgrade from a tired Win7 so I can't really say that so far the experience has been negative.
Now, as for your points:

1. I did mention that I tested this on virtual and real environment, both with ISO(emulation)/DVD-ROM/USB; all the same result. In the end the VM is just for making testing easier and quicker.
NOTE: In case I might have given the wrong idea, I am not building on a VM I am just booting the images there for testing.

2. I have a x64 bit capable machine but that doesn't prevent it from being fully compatible with x86 code, in fact I usually prefer going x86, and it never broke anything with previous PE environments; nevertheless I tried both but again same result.

3. Not concerned at all, I'm not sure if you're under the impression that I am creating my builds under a virtual environment, which I'm not. Indeed I have started from scratch every time I started a new build, this minimizes the risk of other factors doing some damage.

4. As I mentioned, I did run everything with defaults to make sure I was not messing it up, because indeed we can f*ck things up easily :)

5. This is addressed in the previous point, no customization at all.

6. I never had that trouble but I imagine that could happen under certain circumstances.
My priority is getting bootable ISOs for PXE/HTTP loading and occasionally chain-loading with Syslinux from a USB stick; either way so far it did not work any way at all.

I a bit new to this stuff but it's a bit of a surprise that this is not a common issue.
I have created x86/x64 images for Windows XP, Windows 7 and Windows 8.1 all of them worked just fine (except the rare cases where I used messed-up ISOs as sources).

In the meantime I tried mounting and unmounting boot.wim with commit to try and see if it fixed the problem (something that has been suggested in some forums) but no dice.
I compared the BCD entries with for example Win8.1 and it's virtually identical so it should be good. I' still struggling with the same issue as before, not understating what gives.

Hi Tony4219,

thanks, I put your "re format usb stick" and "First Make a default build"
 to FAQ http://theoven.org/index.php?topic=834.0 

*
1. you can build any project on windows virtual machine. On some very rare cases I do.

2. ner0 is right, you can build with any host architecture to any target architecture.
 + localized settings only read from hostos, and if available or possible used on building project.
   With other words, Importing localized settings feature designed with "any architecture" in principle.

4. just for public info: precautions already made to avoid possible failures after Tony4219 reported.

5. just for public info: this may be valid for "some" of personal plugins, shared plugins on servers developed to work on all projects.

Yes, I thought you were either building in a VM or doing a really complicated boot method. Not sure if you have the winbuilder IDE directly on the local hardware yet.  Sorry. That's the only way I have run it.

On point 6) above, using Win7PESE-formatted usbstick to receive the build generates no errors during the build but NEVER EVER boots properly. I haven't seen anyone else mention that but me     It lacks the UEFI stuff, I believe.

I just posted some odd things I took a LONG time to get past ... The first thing I do when I download a complete package (the forum Moderators do that about once a month or so, at http://win10se.cwcodes.net/Compressed/.  I haven't had to do that in a while.) and do a test build with absolutely nothing changed. It always works!  Only when I start adding things do I get it to NOT work

For SourceDiskFiles, I use the old Techbench ISO (from summer 2015) that you cannot download anymore from MSFT unless you have an MSDN subscription, so I have not had a reason, yet, to try to find a different source.  Coincidentally, it is also the same as the Win10 OS on the build machine (see below).

The 3 machines I upgraded from Win8 to Win10  *ALL* failed to boot about a month later, each required a complete new Win10 reinstall--Repair and built-in troubleshooting all failed. Since then, all 3 have been troublefree. For local networking, I have had many issues with Permissions, such that I have finally set Everyone to have Full access, in order to  grab or edit files from one machine to another across the home network.  I couldn't just give user Tony full rights, because "Tony" on one machine is not same as "Tony" on different machine.  <sigh> So, Yes, I don't trust Win10 much !! It doesn't trust me either.

Thanks Lancelot. Yes, my personal plugins were problematic.

In Win7PESE, none of mine had the line in [Main]  "Type=script" and all my personal plugins were dumped in Components folder.  Always worked in Win7PESEx64 !. So I continued that way for years ...

Trying to get them working in Win10PESE x64, they all bombed [where, during build, the winbuilder.exe app actually quit running] until I went thru them line by line and changed them to the proper Win10PESE way.

I appreciate all your help !!

*
well it is good you figure out a way,
Type=Plugin
 
 for distributable plugins, you can share them,
  even you can gather into package "Tony4219_Plugins.7z" on a topic, saying "tested only on blabla"
    There are already some direct plugin packages around topics.

Well, during development we can not be responsible about plugins out of servers,
 I inform authors when there is a plugin topic, about things that will not work or not general plugin way, up to authors....
 we make changes after checking all these plugins (I guess there are ~1000 plugins on servers now)

*
I upgraded from Win8 to Win8.1, than Win8.1 to Win10, than Win10 to Win10 (10.0.10586.0), through windows update.
 All went fine here.
   Check here http://theoven.org/index.php?board=37.0 , Kyhi seems to know these upgrades very well.

1. you can build any project on windows virtual machine. On some very rare cases I do.

Not that it hadn't crossed my mind before, but this tipped my mind into doing just that.
Currently I'm using Windows 10 Pro x64, so I decided to try building on an old Win7 Pro x64 VM that I happen to have at my disposal...
Guess what, it fracking worked! What the hell?! Now, how do I get to understand why all the builds fail on my system but not on the VM system?
Could it be OS? Are you guys building Win10PE from a Win10 system?

I mean, this may have repercussions on other people's projects, because I keep building Gena, Win7PE and Win8.1SE on this same system and it never fails, why would it fail for Win10PE?
I'll try to find out in time but it's pretty odd nonetheless.

Like you, I'm surprised that  works. Ever since my feeble attempts at WinPE3 on a 'technician machine' where the OS you were trying to build HAD to be the same as the OS of the machine you build on, I thought they had to be the same.  Well, MSFT said they had to be the same. 

but, I have always used

Win10PESE x64 is built on a Win10Home x64 machine,
Win7PESE x64 is built on Win7 Pro x64 machine,
and
BartPE x86 is built (not in a long time!) on WinXP x86 machine.

Time marched on ...

I make best experiences with:
ISO on hdd, defragmented with WinContig - copied/added to Win7 C:\Boot\ with EasyBCD.

Try also: Single core (disabled Multicore in BIOS)

 

Thanks for the reply Gerhard S.

After a painstaking hunt for the culprit I finally found what was "corrupting" my builds.
For the sake of it, I'll describe exactly how I came to my conclusion and solution:

First I compared both successful and unsuccessful ISOs and reduced the range of possibilities to the boot.wim file itself.
Then I mounted both boot.wim files and compared the contens using WinMerge, yet it showed that all files were identical which was somewhat puzzling since I was sure the problem was in there.
Then I copied all the contents of the working boot.wim to the non-working boot.wim, committed the changes and replaced it in the non-working ISO and still it wouldn't boot.
Then I used SyncBackFree, which is this little software that allows to backup/synchronize two folders, to sync between both mounted WIMs folders and when I ran a simulation it showed me a list of several files that diverged, not in size, not in binary data, just it's time-stamp!
They all had one thing in common, all were executable files.
 
Alrighty then... so I have this anti-virus software, which is called Comodo Anti-Virus, this little devil has a little peculiar behavior which is that it changes the time-stamp (last modified) of executable files when they are copied, like FTP if you will.
Apparently this behavior is part of it's default defense mechanism, particularly the sandbox. The interesting thing about it is that it is persistent, it still does this even if you disable all security functions and exit the app from the tray icon. I had known this but I tend to forget it very often because most of the time it's not a problem. But as I just became aware it seems that Windows 10, as opposed to (all?) previous Win OSes, has a problem with having it's executable files carry a different time-stamp which is kind of a good thing... maybe.
In conclusion, the solution (which did not require to uninstall the A/V) was to go to Comodo's "Advanced Settings > Security Settings > Sandbox > Auto-Sandbox" and disable the setting "Enable file source tracking".

And well, I guess that's that... the problem was that Windows 10 refused to load executable files with time-stamps different from the original's and didn't bother to give a straight hint about it, which is kind of it's thing, the mystery and adventure that awaits you whenever you touch Microsoft's stuff 

I'd like to thank everyone for chiming in with ideas, thanks!

I mean, this may have repercussions on other people's projects, because I keep building Gena, Win7PE and Win8.1SE on this same system and it never fails,

Hopefully all inside same base folder ex: D:\Oven 

I have all projects and plugins at D:\Oven and do feedback accordingly, life is easier, time is efficient.
Also D:\Oven and my source folder D:\CD are on "AV exclude folder" (Windows Defender  )
D:\CD\NT5\WinServer2003_Ent_R2_CD1_SP2_ENU
D:\CD\NT5\WXPx64_SP2_Pro_English_X13-41611
D:\CD\W10x64
D:\CD\W71x86
....

sharing my organisation on my pc, maybe helps others. 

Like you, I'm surprised that  works. Ever since my feeble attempts at WinPE3 on a 'technician machine' where the OS you were trying to build HAD to be the same as the OS of the machine you build on, I thought they had to be the same.  Well, MSFT said they had to be the same. 

but, I have always used

Win10PESE x64 is built on a Win10Home x64 machine,
Win7PESE x64 is built on Win7 Pro x64 machine,
and
BartPE x86 is built (not in a long time!) on WinXP x86 machine.

Time marched on ...

We never wrote such thing on any plugin on any topic. !

I also put info to FAQ http://theoven.org/index.php?topic=834 to underline it is ok to to build projects at TheOven.org on different host different source, architecture etc.

Apparently this behavior is part of it's default defense mechanism, particularly the sandbox. The interesting thing about it is that it is persistent, it still does this even if you disable all security functions and exit the app from the tray icon. I had known this but I tend to forget it very often because most of the time it's not a problem. But as I just became aware it seems that Windows 10, as opposed to (all?) previous Win OSes, has a problem with having it's executable files carry a different time-stamp which is kind of a good thing... maybe.
In conclusion, the solution (which did not require to uninstall the A/V) was to go to Comodo's "Advanced Settings > Security Settings > Sandbox > Auto-Sandbox" and disable the setting "Enable file source tracking".

Thanks for hard work and detailed info ner0    ,
  I put Comodo AV info to FAQ http://theoven.org/index.php?topic=834 pointing your post   

*
I hate "disable AV" not working to disable all....

Nice finding ner0, Congratulations