LIGHTNING UK!

You'd have to pad the ISO to the required size (so it's uses 99% of the disc or whatever) when building it. You could do that with dummy files etc.

I'd say there's something in the background going on that's making your drive thrash around a bit. It's taking 7 - 8 seconds for the buffers to recover and your buffer is only 80MiB. That's a pretty awful recovery rate. Most drives should be able to do that in 1 second if a sequential transfer.

What's the Realtek usb thing mentioned in the last line? It isn't responding and is what's causing the program to get stuck.

Leaving the write speed on AWS does nothing if you don't actually configure the AWS feature. It'll just use MAX speed. As db says, if your drive has issues with discs, only a firmware update (and/or cleaning the drive) can fix it. Sometime a drive may do a slightly better job if the 'perform opc before write' option is enabled in the settings. Of course sometimes it does nothing or makes things worse. Might be worth a shot though.

Can you show me anything that actually shows there's a size issue here?! There isn't one. You're barking up the wrong tree. Even if a disc only has 10 sectors and I issue a request to reserve 20 (because I'm stupid like that), the drive would hopefully be more competent and return an error. What's happening is the deviceiocontrol API call is being issued and control is never being returned to the program. Don't forget that imgburn always issues that same command. The only thing that changes is the number of sectors it asks the drive to reserve. I'm happy to show you the error your drive should be returning if you attempt to overburn a disc and the 'reserve track' command returns an error. What it should never do though is just get stuck.

I can only speak for the direct imgburn mirror. That one has the file I uploaded to it back on the day or its release a couple of years ago. The setup is meant to use the OpenCandy plugin, so its presence is expected. I use a program called hashtab for checking md5 etc on files.

The Disc ID / MID (Manufacturer ID) is what's important here, not the brand name stamped on them. The MID is displayed in the box on the right before you click the 'Write' button.

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.