LIGHTNING UK!

Personally I'd burn it again. Do so after updating to the 1.04 firmware. http://www.sonynec-optiarc.eu/uploads/iW/L...540A_win104.zip You could also try slowing the write speed to 12x, it'll give you a better quality burn.

They both burnt and verifed fine so there's no way the discs are blank. Examine them with something like IsoBuster to be sure. It could just be that your drives aren't able to read those CD-RW very well.

T035 firmware can be found here: http://support.toshiba-tro.de/tools/eula/c...la.asp?ID=59113 http://support.toshiba-tro.de/tedd-files2/...70810092748.zip

Ok well I give up for tonight now! Assuming your forum email accepts files, I'll mail you a build where you have to 'ok' each of the 3 TOC related commands in the morning and we'll take it from there. Night!

Sorry cynthia, I got bored!

Maybe you could catch the crash if you opened (ran) ImgBurn from within something like windbg - available for free from microsoft.com

I doubt it would mention ImgBurn by name but it could be in the 'Application' log or the 'System' one. Basically any sort of error around the time of it crashing would help! Also, do you have DEP enabled? Is it on for all programs / services or just the main ones? That's in System Properties -> Advanced -> Performance Settings -> Data Execution Prevention.

You can't burn the split files like that. Once you've split them you have to use Build mode to write them to disc - so you actually burn a copy of the image file (as a real file) to the disc. Due to the additional overhead of the new filesystem etc it's best to split at 690mb rather than 700 - as 700 is the limit of the disc.

ok well for the sake of ruling out the dodgy SPTD driver, please try the following... load up Device Manager and click 'View' -> 'Show hidden devices'. Expand the 'Non-Plug and play drivers' branch and locate the 'sptd' entry. Double click it to bring up it's properties, click on the 'Driver' tab (2nd one) and change 'Startup' from 'Boot' to 'Disabled'. Click ok (a few times) and reboot the PC. Then give 2.4.0.0 another go. Change it back to 'Boot' when you're done testing. Event viewer can be found in Administrative Tools (in control panel - classic view).

You're obviously running Alcohol / DAEMON Tools there.... is it the most recent version and with v1.55 of the SPTD driver? Did you look in event viewer for any clues? (Note that I don't mean the 'log' window when I say that... which is what I think you took it to mean the first time around )

Sorry, I meant a discovery test with those types of media. It's the only way to rule certain things out.

I don't prevent it in the first place as far as I know. Either the commands are accepted or they aren't.

Ok, I'm stumped. I can't fault the code, the last 2 calls are identical (apart from 1 byte to go from 'Formatted' to 'Raw' TOC) and there should be a 3rd just after that to get ATIP data. NOTHING happens between them so there is nowhere for it to go wrong! I don't know exactly how the logging tool works so I can't tell if the ATIP one is being sent or not. Either way, it still makes no sense! Any chance you could try the drive in another PC? Or do you have another drive in that PC you could try? Even a virtual drive would probably do! After that, all I can do is make the program display a message box after each of those calls so we'll know if it's returning nicely or not.

Just to be clear, it does it on data cd's, audio ones too etc? I certainly can't reproduce it here and the bit where it's getting that TOC info is in a thread whereby errors should really be caught in try/catch statements. It's got to be something pretty hardcore to totally wipe out the application without even a 'this application has crashed' box from windows. Is anything logged in event viewer? What I/O interface are you using? Assuming it is something in the data returned by the drive that's throwing ImgBurn off, the only way to find out what that is, is to snoop in on the commands. For that you'll need a SPTI sniffing tool (SPTI Tracer) http://club.cdfreaks.com/f86/spti-scsi-tra...ailable-108669/

DVD might be different to CD though. I guess it needs to be a 8x DVD+RW / 6x DVD-RW to be a fair test (assuming you don't want to waste a WORM disc on it).

Blimey, so even that disc makes 2.4.0.0 close down?! I was at least hoping it was something a little more complex. I don't have that exact model drive to test with but I'll give a H22L and H62N a go.

What are the buffers doing during the verify stage? Is it the same if you do a transfer rate test in CDSpeed? (i.e. really slow and dodgy looking graph) (No need to install that one, it's just an exe)

Does this happen on every disc you have in the drive tray? Both CD's and DVD's ? 2.4.0.0 has loads of new stuff so it's hard to compare it to previous versions like that. 2.3.2.0 probably didn't issue the command or use it's info in the same way. What drive do you have? Can you copy + paste the info from the panel on the right (from 2.3.2.0 obviously ) when a disc is in the drive that makes 2.4.0.0 close. Many thanks.

Just some super old firewire/usb thing from svp with and extended power cable and normal akasa rounded ide cable on it - to aid with quick removal. Obviously there's no lid - the IDE cable wouldn't fit. The long pause before filling buffer was me in the debugger btw.

Sorted...

Ok, you're in luck! I've dug out my old (understatement!) Sony DRU-500AX and it has the same problem. It wants a field set to value that's clearly invalid going by the MMC v2... v6 specs. I'll implement a workaround ready for 2.4.1.0.

You can just send me/upload the IBG file if you don't want DVDInfoPro installed.

If you look at this... http://forum.imgburn.com/index.php?s=&...ost&p=40747 How does your own graph compare?

You turned debug OFF before pressing start! I need it ON I don't expect it to work btw, I just want to get to the root of the problem.

Ok, there's no reason for that to be failing like it is. The image is as basic as it could possibly be. Please give it one more go but this time, press F8 before you press the Start button to enable I/O debug mode. Save that new log and upload it just as you did the last one. Thanks