First of all Imgburn is an awesome tool and although I have many burning applications I tend to go back to this one for my disc copying needs.

I ran into a problem I have not seen before with the new version Imgburn 2.4.0.0.

After burning an ISO image for Visual Studio 2008, the verify seems to hang at 99%. I let it go for 15 minutes before I terminated. I restared Imgburn and did just a verify with the same results. This has always worked before for me with 100s of discs and verify usually takes ~5 minutes or so.

I compared the same DVD written in Imgburn against the ISO in DVDInfoPro and it compare straight away no issues.

I am using some of my old but very good quality TDK 4x ( before they outsourced disc production). I am going to try another brand of disc to see if it makes a difference and when I have time I will let Imgburn run as long as needed to see if it ever completes on the original but wanted to see if others have experienced a similar issue.

I know the pitfalls of comparing ISO images but all here are unencrypted and just the contents of disc and ISO should be verified.

Images attached for reference.

After I posted the above, I installed the VS2008 that I had just burned and rebooted as requested at the end of the installation.

I started Imgburn and re-ran the verify and it completed this time in < 5 minutes

I run a very clean rig with almost all startup apps disabled for my video work. Other than downloading the ISO and burning it, I did not run any other programs.

I am going to chalk this one up to a random event and move on.

Are you running AnyDVD? Be the only thing i can think of. LUK! stops by once in a while.

Thanks for the reply.

Nope, I have never used AnyDVD.

One other thing I probably should have mentioned is that when it did "hang" at 99% it took less than 5 minutes to get to 99%. It sat there for another 10 minutes trying to complete the last 1% when I stopped it.

Like I said, I will chalk this to a random event and watch it in the future.

I've seen it before where the drive reports the wrong size for the track and so it runs out of data to compare to the image file and just sits there.

It was a condition I'd not really planned for (as I've never run into it before now!).

Needless to say it has already been sorted for the next version.

Awesome!

Thanks for the excellent work