ImgBurn confused about drive state after cancellation of multiple copies burn

[scuzzy]

The following repeatably causes ImgBurn 2.4.4.0 to get confused about the state of the drive while burning CDRs on my Win2K Pro system. It's a bit of an obscure corner case, but it seemed worth reporting anyway.

1. Launch IB by double-clicking on a CD-sized ISO image.
   
2. Set no. of copies to 2 and load a CDR blank in the drive.
   
3. As an afterthought (in my case !), request a test mode burn (check the checkbox).
   
4. After the first successful test burn IB asks for the second disc to be inserted.
   
5. Cancel the request because this would be a waste of time.
   
6. At this point IB fails to recognise the blank CD in the burner drive (although it did eject & re-load it at the end of the first test burn) :
   
   • the device details pane on the RHS of the window stays blank and dimmed
     
   • The status bar states "Device Not Ready (the handle is invalid.)"
     
   • The burn button is dimmed out
     

[*]Manually ejecting and reloading the drive does not clear the problem.

[*]Switching mode to 'read' seems to clear the problem and IB recognises the empty disc in the drive (the device details pane now shows the expected disc information). Switching back to 'write' mode, IB continues to recognise the disc in the drive.

[*]Then repeat the original burn request (it doesn't matter what values are set for no. of copies, verify or test mode now).

[*]IB claims it couldn't lock the drive for exclusive access (access is denied, another program must be using it).

[*]The problem is completely cleared by restarting IB.

 

Relevant log extract :

 

I 01:13:42 Operation Started!

I 01:13:42 Source File: J:\ctupdate52\iso\wsusoffline-wxp-enu.iso

I 01:13:42 Source File Sectors: 346,516 (MODE1/2048)

I 01:13:42 Source File Size: 709,664,768 bytes

I 01:13:42 Source File Volume Identifier: ctou_wxp_enu

I 01:13:42 Source File Application Identifier: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER etc. etc.

I 01:13:42 Source File Implementation Identifier: [snipped due to 'daggers' bug - scuzzy]

I 01:13:42 Source File File System(s): ISO9660, Joliet

I 01:13:42 Destination Device: [1:3:0] ASUS DRW-1608P2S 1.39 (F:) (ATA)

I 01:13:42 Destination Media Type: CD-R (Disc ID: 97m27s06f) (Speeds: 4x, 10x, 16x, 24x, 32x)

I 01:13:42 Destination Media Sectors: 359,845

I 01:13:42 Write Mode: CD

I 01:13:42 Write Type: SAO

I 01:13:42 Write Speed: 24x

I 01:13:42 Lock Volume: Yes

I 01:13:42 Test Mode: No

I 01:13:42 OPC: No

I 01:13:42 BURN-Proof: Enabled

E 01:13:50 Failed to lock volume for exclusive access.

E 01:13:50 Reason: Access is denied.

E 01:13:50 Operation Aborted! - Duration: 00:00:07

I 01:13:50 Average Write Rate: N/A - Maximum Write Rate: N/A

[LIGHTNING UK!]

Pressing F5 is enough to clear this problem. I've seen it myself but haven't looked into it.

[LIGHTNING UK!]

I think I've traced the source of this problem to a race condition and multiple open/closes of the drive whilst attempting send it some commands.

 

I've synchronised the relevant functions (via critical sections) so hopefully it'll be fine in 2.5.0.0

[Dstruct]

Cool, thanks! I think I also stumbled over this once.