Hi,
Were currently experiencing exactly the same issue. Also a fully-updated Server 2012R2 (with the recent KB2919355 update) machine.
So far, I found two other posts with exactly the same issue:
1) http://wp.secretnest.info/?p=1474
2)
http://community.spiceworks.com/topic/472581-wds-capture-image-winload-exe-corrupt-or-missing
According to these posts it seems like the issue occurs after the first time a capture image based upon a Windows 8.1 or Server2012R2 boot.wim is created.
What Ive tried so far is removing the server role, deleting the WDS store, rebooting the server and start over with a Windows 7 boot.wim. The normal boot.wim starts ok, but the created capture image doesnt.
So the process of creating the capture boot image did something in a way the new boot.wim differences from the old boot.wim. To find out what, I first mounted the new .wim file to see if winload.exe is actually there it is both in
system32 as well as systen32\boot. So my second guess was that the Windows Boot Manager cannot find the windows loader, because of an incorrect declaration of disks in the BCD store.
I used BCDEDIT to show the differences between the working and non-working boot images:
Windows Boot Loader
-------------------
identifier {1d214c07-6892-401c-a762-04647ad38560}
device ramdisk=[boot]\Boot\x64\Images\boot.wim,{b321afc0-8a23-4
961-85dd-a10f3c46473f}
description Windows 7 Boot Image
osdevice ramdisk=[boot]\Boot\x64\Images\boot.wim,{68d9e51c-a129-4
ee1-9725-2ab00a957daf}
systemroot \WINDOWS
detecthal Yes
winpe Yes
Device options
--------------
identifier {b321afc0-8a23-4961-85dd-a10f3c46473f}
inherit {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdiskmcenabled No
ramdiskmctftpfallback Yes
-- Second - Non Working disk --
Windows Boot Loader
-------------------
identifier {872352a0-0ad9-46f6-8612-1aed71ea8534}
device ramdisk=[boot]\Boot\x64\Images\boot-win7-capture.wim,{7a
b86a3a-3651-4f50-a748-34f3e784158c}
description Windows 7 Capture
osdevice ramdisk=[boot]\Boot\x64\Images\boot-win7-capture.wim,{68
d9e51c-a129-4ee1-9725-2ab00a957daf}
systemroot \WINDOWS
detecthal Yes
winpe Yes
Device options
--------------
identifier {7ab86a3a-3651-4f50-a748-34f3e784158c}
inherit {68d9e51c-a129-4ee1-9725-2ab00a957daf}
ramdiskmcenabled No
ramdiskmctftpfallback Yes
So the ID for the osdevice is the same, and only the device is different, but mentioned correctly under Device options (as far as my knowledge goes in this subject). I hope there will be a solution anytime soon.
-
Edited by
C-Laze
Saturday, April 19, 2014 10:44 PM
Added KB article