LIGHTNING UK!

What was the MID of the other discs you used? You have to ignore the brand name and go by that. It could be that you've actually tried the same ones twice.

Same thing if you boot into safe mode?

Your drive is reporting it as one... see the 'current profile' bit at the top. Eject and reinsert a few times to see if it sorts itself out. If it doesn't, please copy and paste everything out of that box. You could also try powering the pc off and on again. Totally kill the power, don't just reboot.

I'm afraid there's no such thing. The only test is to burn and verify several times (using various discs) and if it keeps failing where another burner keeps succeeding, the drive has probably had it. Only the cheap verbatim discs use the UME media code and people are advised not to use them. Buy the proper MKM ones.

You'll have to do what I said in my last reply.

How close to being full is the disc? Can you not just do loads of splits in and around the area it mentions and hope that one ends up being a possible layer break point?

Unless you missed something in copying the files over... not a clue. When you say 'not bootable', did it error out with that BCD issue again or did it really not boot at all - as if you hadn't mounted the image at all?

You may find it's buggy rather than strict. As I said, booting is not really the problem here. It 'boots' ok (the el Torito part), it just falls over after that. Still, there's no way to know for sure I guess unless you ask the virtualbox developers to look into why that Gandalf image won't fully load. You don't appear to need iso9660 at all as it worked fine for me with just udf selected - and that's how the Windows installation discs have been built for ages now. I read that for uefi, if the 'sectors to load field' in the boot catalog is 0 or 1, it uses the size in the FAT partition boot sector (first 512 bytes of the boot image). The value within the boot sector is exactly what I told you earlier - 2880. So basically, you can use any of those 3 values and should end up with the same result.

I don't know why you think this is an issue in ImgBurn. If you're read the previous threads, you'll see I've said that when that message is in the status bar, the program is simply sending (has simply sent) the 'Reserve Track' command to the drive with the number of sectors it wants it to reserve. It's one of the most basic commands you can get in the world of optical drives. Once a command has been submitted, ImgBurn has to wait for a response. That's it, period. Your drive should either process the command successfully and return 'ok' or fail and return an error. ImgBurn will continue waiting until one of those two happen. If something else in your system is preventing the ok / error from reaching ImgBurn, I'm afraid that's out of my control. As to what might be causing it - either in terms of software or the drive just getting 'stuck' - I have no idea on the root cause and I can't do anything to diagnose the problem because I'm not the one sat at your PC. It's something you have to troubleshoot yourself and that means a bit of messing around an potentially trying different hardware etc. (which I do understand isn't an option for a lot of people). The program sees as much space on the disc as the drive reports to it. All of the sizes etc. are in the disc information pane and written in the log at the start of the burn. You'd also get a warning the second you clicked the 'Write' button if what you're attempting to burn won't fit on the disc.

The boot catalog is part of the eltorito specs and that's just for optical discs. Nothing you've uploaded is bootable as there simply isn't enough of it. I booted the ISO you started with... Gandalfs one from the link you provided early on. I think it's almost 3GB in size or something.

I doubt it's really empty, your drive just isn't seeing that it just burnt it. Look at the bottom of the disc, is there any visible ring on it? It might be worth trying another burn having enabled the 'perform opc before write' option in the settings. After that, you're going to have to try some different discs, cleaning the drive and possibly even replacing it. 8x wasn't supported by your drive / firmware / media combo, so it burnt at 16x that first time anyway. 24x would be the next one to try.

Your untouched source image (Gandalfs Win8.1U1SE_x64 updateable final.iso) worked fine in EFI mode for me... as did the one I rebuilt in ImgBurn. They've both booted ok and gone right into Windows. I'm on the desktop screen as I type this.

I wouldn't expect any legacy images to boot in efi mode, they aren't supposed to. Each mode would look for entries in the el Torito boot catalog that they're meant to look for and ignore the others. Based on your last screenshot, I don't believe you issue is related to anything to do with the el Torito / bootable disc stuff at all. After all, it *has* booted, it's just falling over sometime after that. I will shortly be testing your source ISO in VMware to see if it boots in uefi mode before then rebuilding it with the same settings I used for the install disc and see how it goes.

I just took an original Windows 8.1 image, mounted it in a virtual drive, pointed build mode at the virtual drive it and configured the 'bootable disc' tab with the UEFI platform, the efisys.bin boot image and set the 'sectors to load' to the value I gave you earlier (2880) and it's booted fine in VMware (set in EFI mode). I also created a legacy bios bootable version (so just changing the boot image to etfsboot.com, sectors to load to 8 and the platform id to 80x86) and that failed to boot in the EFI enabled VMware. Switch VMware out of EFI mode and the legacy one booted fine.

Does it even look like its attempting to load anything from the disc? I don't have anything uefi capable but legacy bios boot sometimes shows error messages when something about the el Torito boot configuration isn't quite right. It's not supposed to be this difficult. It's just meant to look for the 0xEF platform id entry in the boot catalogue and boot accordingly (run the boot image it points to).

Try 2880 for 'sectors to load'. If that still doesn't work, try disabling Unicode within the UDF file system.

No, don't worry it and just continue as normal.

Post the log from the 8x burn please.

Ok, so what I need then is the image that's uefi bootable. I download the image you said you'd used as your source image... But if that in fact isn't uefi bootable, I guess I needn't have done so.

It turns out that I need roughly the first 12000 sectors from the mkisofs image in order to look at the boot catalogue. That equates to 24,576,000 bytes. So 25MB will do it if that's possible please? Sorry, I don't know the answer to your question. It would probably depend on what it's meant to be for the file you're pointing it to as the boot image. Normally you'd get the information from a disc that works.

Can you also upload the same first chunk of the working ISO... Assuming the one on there now is the non working one? Oh and you should have pressed the 1999 button on the iso9660 restrictions tab. The Joliet restrictions don't apply as you aren't adding that one. I'd stick with udf 1.02 too.

The first megabyte of each image should be enough to examine things. If it isn't, I'll let you know.

Maybe you need to adjust the iso9660 restrictions / settings so it can use longer file names etc. Basically so it's the same as whatever ISO level 4 in mkisofs is.

Your drive is reporting a write error, so it's having trouble burning to the discs you're using. Try setting the write speed to 8x rather than max or use some different discs.

I'd have expected number 1 to work. Which parameters are you passing to mkisofs? That should give us a clue. Beyond that, I'd have to examine a chunk of each image and see how they differ.