ajgor

My reasoning about what causes the problem was obviously wrong. A simple explanation would be that bootmgr can not properly load the kernel because the BCD is corrupted or wrongly configured (error report states Error 0xc000000e, Windows failed to start. File: \EFI\Microsoft\Boot\BCD). However, the BCD was exactly the same on images that could not boot (the source Gandalfs Win8.1U1SE_x64 updateable final.iso) and on those that could (e.g. TEST_double_mkisofs_OK.ISO, which was created by the first one using Rufus and mkisofs). All files that could be related to booting and OS start were the same in both images, except the boot.catalog. But as as I understand, boot.catalog is not used after the bootmgr starts? When I finally created the ISO that booted normally by ImgBurn, it was with the UDF file system instead of ISO9660 + UDF. Everything looks the same when I compare this image with the one that fails to boot (created in the same way, except with ISO9660 + UDF). Files in the root and in directoies possibly involved in booting (boot, efi, bcdw, sources) are exactly the same, both images don't contain boot.catalog. Yet one boots well (the one with UDF) and with the other one, Windows boot manager reports Error 0xc000000e related to BCD. This looks mysterious to me, do you have any possible explanations?

It was that BCD issue.

I also tried with UDF and - it works! Who would understand. For sectors to load I can not insert 0, but I can insert 1 and it works.

Update: I tried to create an UEFI bootable ISO from the USB stick (containing contents of the source image Gandalfs Win8.1U1SE_x64 updateable final.iso transferred to USB by Rufus), but it did not boot in UEFI. I used the same settings as when creating UEFI ISO from the AOMEI backupper's image. Screenshots of settings are in the posts_3 directory. Strange, I really thought it would work now.

OK, thanks. One interesting thing is if I created an UEFI bootable ISO by mkisofs form the USB stick, it worked. When I copied contents of the USB stick to a directory and created ISO image from that directory (using mkisofs with exactly the same parameters except the source), the ISO image was not UEFI bootable. Do you know what might be the reason for this?

Oh my, this is getting frustrating... But I think I've made some progress. It seems that VirtalBox is somehow more strict about EFI than VMware. I can not boot on VirtualBox from the source image Gandalfs Win8.1U1SE_x64 updateable final.iso, no way. I played a bit more with mkisofs. Before I was running mkisofs on USB stick created from the source image by Rufus. This works fine, but when I try to just use the mounted source image or source image extracted to a a directory on hard disk, it does not work. It seems that Rufus adds something to the USB whet is necessary on VirtualBox to boot in EFI mode. I was then workinng on Windows 10 home official ISO (which boots to Windows installer) and on Windows PE ISOs created by AOMEI backupper as bootable media (rescue disks). AOMEI can generate a bootable disk based on Linux kernel or on Windows PE (the last one bootable either in BIOS or UEFI mode). This image is nice to play with because it is relatively small (below 300 MB). Both disks (Win 10 and AOMEI Win PE/UEFI) can be booted from VirtualBox. By mkisofs, I can create UEFI bootable image for VirtualBox from UEFI bootable ISO created by AOMEI Backupper. This can be done either from windows-mounted ISO image or from a directory where the image is extracted beforehand. If I also add files necessary for legacy boot (/bootmgr in addition to /bootmgr.efi and boot/etfsboot.com in addition to boot/efisys.bin) then I can create either bios, uefi or double bootable ISO. mkisofs always creates the boot.catalog file, but original UEFI bootable ISOS (Windows 10 Home and APMEI Win PE / UEFI) didn't contain that file. mkisofs can be run with paremeters -hide boot.catalog, but the file was still added to the ISO image. So, I tried to create an UEFI bootable ISO image by ImgBurn from AOMEI image and it was finally successful, I could UEFI-boot it on VirtualBox. I used the settings that you suggested (Restrictions & ISO9660 from 1999, Options/Include hidden, Include system files, UDF-Disable unicode, 2880 sectors to load). In mkisofs I can skip this argument (then it loads the whole image, which is default). Now, what concerns VirtualBox, it seems that when source image can not be booted in UEFI mode, the image generated from the mounted or extracted source image is also not UEFI bootable, either when creating the image with mkisofs or by ImgBurn. The source image Gandalfs Win8.1U1SE_x64 updateable final.iso could not be booted in UEFI on VirtalBox, but when I created a bootable USB from this image using Rufus, it could be booted in UEFI mode on VirtualBox. It seems that Rufus fixes something that is needed by VirtualBox to boot in UEFI mode, but was not included with the source image. Then, when creating a new image by mkisofs from that USB, everything was OK, but when creating it from the mounted or extracted original, the image did not boot in UEFI mode. I still have to try whether I can use ImgBurn to create an UEFI bootable ISO from the USB stick created by Rufus, now that I know which settings to apply.

Strange that the source image (Gandalfs Win8.1U1SE_x64 updateable final.iso) worked in EFI mode, on my VirtualBox it only worked in legacy mode, also on my laptop when I burnt it to a DVD. Like I said, I could only boot in UEFI mode the ISO that I created by mkisofs (TEST_double_mkisofs_OK.ISO). This one boots in both modes because it was created for both modes. The strange thing is that when I compare the Gandalfs Win8.1U1SE_x64 updateable final.iso (source image) and TEST_double_mkisofs_OK.ISO (created by mkisofs, bootable in UEFI), practically all files that could be related to booting and to the system, are the same, byte to byte and by paths within ISO. So if the original image really came to the point where Windows are started, how could it fail when the one created by mkisofs does not fail, and all Windows-related files are (in my opinion) exactly the same? As I understand, from the point when Windows begin to load, all data on disk is accessed through the file system paths and not through hardware addresses? This would then mean that if two disks have the same file structure, either Widows should run properly on both or should fail on both? The only differences in file systems between the source image and the mkisofs image are the following: mkisofs image has $RECYCLE.BIN, but this has nothing to do with booting or starting Windows mkisofs image has an additional directory (my customization), which has nothing to do with booting or starting Windows mkisofs image has a file boot.catalog (2048 , which is not contained in the source image. This could be the only reason in the file system for different behavior. boot.catalog was added by mkisofs when I created the image along the path Gandalfs_Win8.1U1SE_x64_updateable_final.ISO ==> (by Rufus) UEFI bootable USB ==> (by mkisofs) UEFI bootable TEST_double_mkisofs_OK.ISO The USB stick boots perfectly in UEFI mode although it doesn't have boot.catalog. Why is that, is boot.catalog specific to optical drives, or the reason for boot/not boot lies in lower level (not at the file system level)? When you booted the source image in UEFI mode, did you use the one I have upoloaded?

Hmm... This would suggest either that the Windows 8.1 PE disk that I was using is different from the original Windows 8.1 in something that is important for booting, or that VirtualBox' implementation of UEFI is different from VMWare's. But I could easily boot form the ISO created ftom the same original via creating a bootable USB by Rufus and then creating ISO image by mkisofs. Also, in my previous testing, I could UEFI - boot those DVDs or USBs that I could also boot on VirtualBox on two actual systems (Acer Aspire V3 (quite old) and MS Surface Pro 4), and I couldn't boot those which I couldn't boot on VirtualBox. I haven't yet tried to boot the ISO image created with the latest settings (i.e. 2880 sectors to load) on actual systems (I will not have access for some time). I also cudn't boot any images created by ImgBurn with legacy settings when EFI was enabed, and all those images booted without any problems in legacy mode. Is it possible that VMware doesn't have a strict implementation of UEFI standard and is tolerant to some minor error in images created by ImgBurn? It would be nice to verify that on some other systems, but I will not have this possibility for some time.

It seems that Windows boot manager is started, but the error displayed is strange, complaining about BCD file (efi/microsoft/boot/bcd). This is strange because the file is there, and it is precisely the same location and contents as the one contained on the original ISO image and the one contained in the mkisofs - created image that boots without errors on the same configuration (I boot form VirtualBox, have also used my laptob before). The error screen is in the file error_screen_boot_UEFI.JPG.

I tried, it still doesn't work.

To further clarify, the problem is that I can create UEFI bootable ISO from UEFI bootable USB by using mkisofs (creating TEST_double_mkisofs_OK.ISO, which is both legacy and UEFI bootable) but I can not do this by using ImgBurn by suggested settings (the result is TEST_uefi_fromUSB_not_good.ISO, which is not UEFI bootable). With ImgBurn I could only create a legacy bootable ISO (TEST_legacy_OK.ISO), using settings from legacy_bootable.JPG in the uploaded directory posts_2.

OK, that was a missunderstanding. So Gandalfs_Win8.1U1SE_x64_updateable_final.ISO, this was my original and is not UEFI bootable (didn't even check that), and I uploaded only the 1.44 MB part of it if you need to check anything. The mkisofs -generated image (TEST_double_mkisofs_OK.ISO) is UEFI bootable. It was created from original through USB stick (using Rufus) to the final version (using mkisofs), so: Gandalfs_Win8.1U1SE_x64_updateable_final.ISO ==> (by Rufus) UEFI bootable USB ==> (by mkisofs) UEFI bootable TEST_double_mkisofs_OK.ISO The first 25 MB or so of TEST_double_mkisofs_OK.ISO is in the TEST_double_mkisofs_OK__split subdirectory of posts_2 (split to 1.44 MB parts).

Hi, I've put around first 25 MB of TEST_double_mkisofs_OK.001 to the TEST_double_mkisofs_OK__split subdirectory, split into 19 files of 1.44 MB. I have a slow connection and it willl take some time for all files to be uploaded. I tried different things and I noticed that the original (Gandalfs_Win8.1U1SE_x64_updateable_final.ISO) is not UEFI bootable on VirtualBox VM, and also if I create new ISO images from the original bymkisofs (same parameters as described) they are only legacy bootable. As I mentioned, the double bootable ISO image that works was created by mkisofs from the double USB drive that was created from the original ISO image by Rufus, so obviously Rufus added the stuff that makes the USB (and ISO images created from it by mkisofs) UEFI bootable.

Update: I tried to create an ISO from USB, since this is what I've done when using mkisofs. The USB contents were created by Rufus from the same original ISO image used to generate the other images (Gandalfs_Win8.1U1SE_x64_updateable_final.ISO). I have uploaded the first bytes of generated ISO and the corresponding log file to the Dropbox directory with the above link. Result is similar (log file is more or less the same, it also doesn't work), just binary contents of ISO are different. List of files in the directory: Gandalfs_Win8.1U1SE_x64_updateable_final.ISO.001 - original ISO image (Win PE 8.1) from which other ISO images are created by ImgBurn. TEST_double_mkisofs_OK.001 - created by mkisofs from USB flash, which was created by Rufus from the original ISO image. It works both with UEFI and legacy boot. TEST_legacy_OK.ISO.001 - created by ImgBurn for legacy boot (log file: ImgBurn_legacy.log, screenshot: legacy_bootable.JPG) TEST_uefi_fromUSB_not_good.ISO.001 - created vy ImgBurn for UEFI boot from the original ISO image, does not work (log file: ImgBurn_uefi_not_good.log, screenshots: uefi_bootable.JPG, uefi_options.JPG, uefi_iso.JPG, uefi_udf.JPG). TEST_uefi_fromUSB_not_good.ISO.001 - created by ImGBurn from the USB flash (the same one as used to create TEST_double_mkisofs_OK.001). Log file: ImgBurn_uefi_fromUSB_not_good.log, the same screenshots apply as before (uefi_bootable.JPG, uefi_options.JPG, uefi_iso.JPG, uefi_udf.JPG), except that the source was different (J: instead of F:). Question: Under Advanced/Bootable Disc menu, how is the number of Sectors to Load determined in case of UEFI Platform ID, does it have any meaning?

I've taken the wrong screenshot before, Joilet instead of UDF restrictions. I've created UEFI ISO according to your instructions, still doesn't work. Files are here: https://www.dropbox.com/sh/wmp5qayy5lqmeyd/AAA1kEBvxq1Z0o9lq9TaBOgIa?dl=0 Included are the first megabyte of the original image (Gandalfs_Win8.1U1SE_x64_updateable_final.ISO.001), double boot image created by mkisofs (works; TEST_double_mkisofs_OK.001), legacy boot image created by ImgBurn (works; TEST_legacy_OK.ISO.001) and uefi boot image created by ImgBurn (doesn't work). File names tell what other files represent.

I've uploaded the files on DropBox (settings screen shots and the first part of generated image): https://www.dropbox.com/sh/rlp21pk3ei5nb9t/AADx0j7SuxHH6tnPJ96mwFoua?dl=0

I tried it but it didn't solve the problem.

I'm running mkisofs like this: set inputdir=F:\ set outputiso=d:\VM\bootable\TEST.ISO set label="UEFI_BIOS_BOOT" set biosboot=Boot/etfsboot.com set efiboot=efi/microsoft/boot/efisys.bin mkisofs -iso-level 4 -l -R -UDF -D -volid %label% -b %biosboot% -no-emul-boot -boot-load-size 8 -hide boot.catalog -eltorito-alt-boot -eltorito-platform efi -no-emul-boot -b %efiboot% -o %outputiso% %inputdir% This makes an ISO bootable both in legacy and UEFI scheme. mkisofs is not from the original version of cdrtools, but from reboot.pro: http://cdob.reboot.pro/ Exact executable I was using was this one: http://reboot.pro/index.php?app=core&module=attach&section=attach&attach_id=15214 Please let me know in case you need chunks of the images (which ones & what length). Thanks, Ajgor.

Because I don't want , I also attach the log file below. I 22:29:19 ImgBurn Version 2.5.8.0 started! I 22:29:19 Microsoft Windows 8 Core x64 Edition (6.2, Build 9200) I 22:29:19 Total Physical Memory: 16,654,616 KiB - Available: 11,586,624 KiB I 22:29:19 Initialising SPTI... I 22:29:19 Searching for SCSI / ATAPI devices... I 22:29:19 -> Drive 1 - Info: HL-DT-ST DVDRAM GTA0N 1.00 (E:) (SATA) I 22:29:19 -> Drive 2 - Info: Msft Virtual DVD-ROM 1.0 (F:) (Virtual) I 22:29:19 Found 1 DVD-ROM and 1 DVD±RW/RAM! I 22:32:28 Operation Started! I 22:32:28 Building Image Tree... I 22:32:32 Checking Directory Depth... W 22:32:33 Directory depth exceeds ISO9660 limit of 8 levels! W 22:32:33 Name: '\PortableApps\AOMEI Partition Assistant 5.5.8 Pro Portable\Data\local\meta\@PROGRAMFILESX86@\AOMEI Partition Assistant Pro Edition 5.5\native\' W 22:32:34 Number of directory levels in path: 9 W 22:32:34 Most directory levels in any path: 15 I 22:32:34 Calculating Totals... I 22:32:34 Preparing Image... I 22:32:37 Checking Path Length... I 22:32:37 Contents: 7,351 Files, 1,026 Folders I 22:32:37 Content Type: Data I 22:32:37 Data Type: MODE1/2048 I 22:32:37 File System(s): ISO9660 (Bootable), UDF (1.02) I 22:32:37 Volume Label: Win8.1SE I 22:32:37 Size: 2,310,440,637 bytes I 22:32:37 Sectors: 1,131,947 I 22:32:37 Image Size: 2,340,552,704 bytes I 22:32:37 Image Sectors: 1,142,848 I 22:32:38 Operation Successfully Completed! - Duration: 00:00:09 I 22:32:38 Operation Started! I 22:32:38 Image Contents: 7,351 Files, 1,026 Folders I 22:32:38 Image Sectors: 1,142,848 (MODE1/2048) I 22:32:38 Image Size: 2,340,552,704 bytes I 22:32:38 Image Single Layer Profile: DVD-R/RW (Media Capacity: 2,297,888) I 22:32:38 Image Volume Identifier: Win8.1SE I 22:32:38 Image Volume Set Identifier: 488DB40E00117036 I 22:32:38 Image Application Identifier: IMGBURN V2.5.8.0 - THE ULTIMATE IMAGE BURNER! I 22:32:38 Image Implementation Identifier: ImgBurn I 22:32:38 Image File System(s): ISO9660 (Bootable), UDF (1.02) I 22:32:38 Destination File: D:\VM\bootable\TEST.ISO I 22:32:38 Destination Free Space: 66,680,225,792 Bytes (65,117,408.00 KiB) (63,591.22 MiB) (62.10 GiB) I 22:32:38 Destination File System: NTFS I 22:32:38 File Splitting: Auto I 22:32:38 Writing Image... I 22:33:58 Operation Successfully Completed! - Duration: 00:01:20 I 22:33:58 Average Write Rate: 28,571 KiB/s (21.1x) - Maximum Write Rate: 57,594 KiB/s (42.6x) I 22:39:02 Operation Started! I 22:39:02 Building Image Tree... I 22:39:06 Checking Directory Depth... W 22:39:10 Directory depth exceeds ISO9660 limit of 8 levels! W 22:39:10 Name: '\PortableApps\AOMEI Partition Assistant 5.5.8 Pro Portable\Data\local\meta\@PROGRAMFILESX86@\AOMEI Partition Assistant Pro Edition 5.5\native\' W 22:39:10 Number of directory levels in path: 9 W 22:39:10 Most directory levels in any path: 15 I 22:39:10 Calculating Totals... I 22:39:10 Preparing Image... I 22:39:12 Checking Path Length... I 22:39:12 Contents: 7,351 Files, 1,026 Folders I 22:39:12 Content Type: Data I 22:39:12 Data Type: MODE1/2048 I 22:39:12 File System(s): ISO9660 (Bootable), UDF (1.02) I 22:39:12 Volume Label: Win8.1SE I 22:39:12 Size: 2,310,440,637 bytes I 22:39:12 Sectors: 1,131,947 I 22:39:12 Image Size: 2,340,552,704 bytes I 22:39:12 Image Sectors: 1,142,848 I 22:39:22 Operation Successfully Completed! - Duration: 00:00:19 I 22:39:22 Operation Started! I 22:39:22 Image Contents: 7,351 Files, 1,026 Folders I 22:39:22 Image Sectors: 1,142,848 (MODE1/2048) I 22:39:22 Image Size: 2,340,552,704 bytes I 22:39:22 Image Single Layer Profile: DVD-R/RW (Media Capacity: 2,297,888) I 22:39:22 Image Volume Identifier: Win8.1SE I 22:39:22 Image Volume Set Identifier: 488DB4E100117036 I 22:39:22 Image Application Identifier: IMGBURN V2.5.8.0 - THE ULTIMATE IMAGE BURNER! I 22:39:22 Image Implementation Identifier: ImgBurn I 22:39:22 Image File System(s): ISO9660 (Bootable), UDF (1.02) I 22:39:22 Destination File: D:\VM\bootable\TEST.ISO I 22:39:22 Destination Free Space: 64,339,632,128 Bytes (62,831,672.00 KiB) (61,359.05 MiB) (59.92 GiB) I 22:39:22 Destination File System: NTFS I 22:39:22 File Splitting: Auto I 22:39:22 Writing Image... I 22:39:38 Operation Successfully Completed! - Duration: 00:00:16 I 22:39:38 Average Write Rate: 142,856 KiB/s (105.6x) - Maximum Write Rate: 263,256 KiB/s (194.6x) I 22:46:22 Operation Started! I 22:46:22 Building Image Tree... I 22:46:25 Checking Directory Depth... W 22:46:28 Directory depth exceeds ISO9660 limit of 8 levels! W 22:46:28 Name: '\PortableApps\AOMEI Partition Assistant 5.5.8 Pro Portable\Data\local\meta\@PROGRAMFILESX86@\AOMEI Partition Assistant Pro Edition 5.5\native\' W 22:46:28 Number of directory levels in path: 9 W 22:46:28 Most directory levels in any path: 15 I 22:46:28 Calculating Totals... I 22:46:28 Preparing Image... I 22:46:30 Checking Path Length... I 22:46:30 Contents: 7,351 Files, 1,026 Folders I 22:46:30 Content Type: Data I 22:46:30 Data Type: MODE1/2048 I 22:46:30 File System(s): ISO9660 (Bootable), UDF (1.02) I 22:46:30 Volume Label: Win8.1SE I 22:46:30 Size: 2,310,440,637 bytes I 22:46:30 Sectors: 1,131,947 I 22:46:30 Image Size: 2,340,552,704 bytes I 22:46:30 Image Sectors: 1,142,848 I 22:46:37 Operation Successfully Completed! - Duration: 00:00:14

I was trying to create a UEFI-bootable ISO with ImgBurn, but the ISO can not be booted on UEFI based systems. I tried to boot the generated ISO file on a virtual machine (VirtualBox) and two computers (after transferring ISO to USB drive by Rufus). I tried to create an ISO from extracted contents of the Windows 8.1 PE ISO image. Contents of the original image were extracted by automatic mount to a Windows volume. I tried to do the same with other software (mkisofs) and everything worked, so that the original ISO should be OK. I needed to create an ISO as intermediate step in customizing a pre-compiled Win PE ISO image downloaded from this site. I needed to add my own software (IGLib, IGShell and AnnApp based) to the ISO for testing and deployment. I checked all possible sources (Google, ImgBurn forums and FAQ) but actually did not find any precise instructions about which settings to use to create a UEFI (not legacy BIOS/MBR) compliant ISO. If I want to create a legacy-bootable ISO, everything works fine with the following settings: Emulation Type: None Boot Image: F:\Boot\etfsboot.com Platform ID: 80x86 Load Segment: 07c0 Sectors To Load: 0 Then I wanted to create a UEFI bootable ISO image and it didn't work with any of combinations below (1) without emulation, 2) with hard disk emulation, 3) with floppy emulation): 1) Emulation Type: None Boot Image: F:\efi\microsoft\boot\efisys.bin Platform ID: UEFI Load Segment: 07c0 Sectors To Load: 8 2) Emulation Type: Hard Disk Boot Image: F:\efi\microsoft\boot\efisys.bin Platform ID: UEFI 2) Emulation Type: Floppy Disk (1.44 MB) Boot Image: F:\efi\microsoft\boot\efisys.bin Platform ID: UEFI What settings should I really use to create an ISO that would correctly boot on UEFI schemes? Thank you and best regards, ajgor