Question about locking volume when burning

[yaluen]

After I switched to 2.4.0.0 ImgBurn has been taking a long time locking the volume, usually about 3 to 4 minutes. Is this normal or does that mean something is up with ImgBurn? Sorry if this is a stupid or already asked question, can't find anything about this.

[LIGHTNING UK!]

Is this normal or does that mean something is up with ImgBurn?

 

No so much with ImgBurn as your system!

 

It retries 5 times with a second between each and I've never seen it take any length of time to fail once the API call has been made to perform the locking. So basically it should take 5 seconds before it errors out - assuming it fails all 5 times of course.

 

The code behind it hasn't changed so I'd be very surprised if previous versions act differently.

 

Are you sure nothing you've installed is using the drive but actually letting go of it (VERY slowly) so the lock can succeed?

[yaluen]

I've never quite understood what's locking, the optical drive or the hard disk? If I'm burning from an external hd and accessing it for something else at the same time would that be the problem?

[LIGHTNING UK!]

Nope, it's for locking the burner so nothing else can access it and mess up your burn.

[yaluen]

That's weird then...well, I rebooted my computer and tried to burn and this time it locked the drive instantly. Any idea what's causing the lag before? Only thing I can think of is that I've left my pc on for a few days and didn't reboot after updating to 2.4.0.0

[blutach]

You on some sorta home network where something else might have been trying to get a hold of the drive? Or running any other app that involves the drive?

 

Regards

[fordman]

You on some sorta home network where something else might have been trying to get a hold of the drive? Or running any other app that involves the drive?

 

Regards

 

I have to admit that I'm encountering "unable to lock volume" messages with 2.4.0.0 while I never once had that with 2.3.2.0, and when I ran process explorer (from sysinternals/Microsoft) and searched for "cdrom" in the handles, it showed that internet explorer was utilizing the DVD writer! Strange, but once I closed all instances of internet explorer it burned fine without the error.

 

This is on my workplace system where I'm locked to user mode and antivirus scans run regularly.

 

So, now that I'm using 2.4.0.0 I make sure that I close everything before using ImgBurn, and then open them back up once burning starts...

[blutach]

Very very unusual that IE will want to take a hold of your burner. I really can't think of any instance that it would do that.

 

Regards

[Cynthia]

Perhaps an added toolbar/plugin?

[fordman]

Perhaps an added toolbar/plugin?

 

I agree with blutach that this is very odd. As for a plugin causing it, I NEVER received the warning message with 2.3.2.0 on this same computer, and was burning with it right before installing 2.4.0.0. Then once I installed 2.4.0.0 I received it with my very first burn attempt, and the log showed a list of progams with "access denied," and it looked like just about every process that I had running, including Symantec Antivirus modules. I let ImgBurn continue burning despite it the message for the first two instances and the burned copy compared exactly to the image. I have since encountered times when having internet explorer open did not cause and issue, but then later it will. The only sure way for me to avoid the message is to close all other programs before beginning a burn, and then to start them after burning begins.

 

Over in the DVDFab forum in CDFreaks, you can see the author made a new version with one fix being to work around the "unable to lock volume for excluse access" in ImgBurn 2.4.0.0, and he had previously allowed Imgburn as the burning program to be called from within DVDFab, so perhaps there was a change from 2.3.2.0 to 2.4.0.0 that makes this check by ImgBurn much more agressive? I can only conclude that since the DVDFab author found it necessary to recode DVDFab once 2.4.0.0 was released and users of DVDFab began getting this error. Apparently there were no such complaints wit 2.3.2.0...

Edited February 24, 2008 by fordman

[LIGHTNING UK!]

fordman,

 

You're not interpreting the debug log properly, that's all.

 

The 'access denied' stuff is nothing to do with the actual locking.

 

As mentioned a million and one times, process explorer will help you find out which app is also using the drive, preventing ImgBurn from taking exclusive use of it.

 

DVD Fab seems to keep a handle open to all drives all the time, that's why the lock failed - and it's failed in ever version.

 

I added a switch in 2.4.0.0 so apps that call ImgBurn via CLI (knowing full well they'll prevent it from locking the drive) can tell it to ignore the 'Access Is Denied' error. THAT is what fengtao seems to have added support for in his most recent release.