I have two bluray drives of the same exact model and brand installed in my computer. I occasionally like to use either of them to burn CDs or DVDs using various software (Windows Media Player 12, Zune, ImgBurn, Windows DVD Maker, etc). It will get through the burning process and complete successfully, but with either drive, it will not release the resource lock on the disc, meaning the disc continues to spin, the access light flashes continuously, and I cannot eject the drive. When I use ImgBurn to burn a disc, it will typically do a verify step after burning, which cycles the drive tray. Because the lock is not released, it will not be able to cycle the drive tray. Right now, I've just burned a CD in Windows Media Player, and it completed successfully (I can even play the CD in WMP) but I cannot eject the drive. The only reliable way I've found of getting the disc out is to reboot the machine and then when it powers back up I can eject the disc.

Why would this be happening? It's consistently doing this 100% of the time. I've updated my drivers but it didn't change anything.

Has anyone run into this kind of issue before? What can I do to fix it?

EDIT

Note, I also just updated the firmware for the drives, which didn't help. Additionally, I unplugged one of them (on the off chance that the fact that there were 2 identical drives was causing conflicts somewhere) and it made no difference.

Also, I found a way to force the ability to get the drive tray open without rebooting. Through ImgBurn, I went to the Tools menu, then Drive, then clicked "Close session" and it let me open the tray again.

Also of note, if I instead tried clicking "Eject" in the Drive menu in ImgBurn, it gave me a descriptive error message, basically stating lots of technical junk and the error "Logical unit not ready - Long write in progress". I think this long write is what's keeping the drive occupied. But it doesn't appear to ever finish. So is this a driver issue then? It does happen across programs.

EDIT #2

Per Paperlantern's suggestion below, I tried using a Linux LiveCD session to burn a disc. I booted into Kubuntu and burned a small audio CD using k3b. Interestingly, it worked perfectly. It burned the CD and then ejected the disc at the end. So this apparently is not a hardware issue, but a Windows one.

EDIT #3

After some troubleshooting with the help of a couple people here, I've determined that the likely cause is a problem with how Windows is issuing commands to ATAPI devices. This Windows installation originally was installed to an IDE drive, but it was switched over to RAID without doing a reinstall. This may have put Windows in a state where it isn't properly communicating with the drives. I did a fresh install of Windows on the machine (after backing up my previous installation) and did a couple test burns and Windows operates properly, ejecting the drive at the end of the burn job. I will restore my backup image and proceed from there.

It sounds like a driver/OS issue. Is there a way to view what process is locking the drive?
–
soandosDec 29 '11 at 4:38

@soandos I know which program initiates the lock. It's always the one that I am using to burn the drive, whether it be Windows Media Player, ImgBurn, or something else. I don't believe that there's an intermediary process that one of these communicates with to burn the disc, is there?
–
Ben RichardsDec 29 '11 at 4:44

3 Answers
3

So this happens on any and all types of burns? To alleviate ANY issues with current driver or software being the problem, what I would do, being as frustrated as you probably are, is to load a copy of linux mint or ubuntu linux onto a spare drive in the machine. Or use the live CD in one drive and try to burn something on the other drive, to see if the problem occurs in another OS and software environment altogether. It could at least tell us if the problem is the hardware (maybe bad batch of CD ROM drives with messed up cache or something equally bizarre?), or if the issue resides with your OS or driver in some way.

If it is OS related, running a sysprep on the machine would force a redetect and reinstall of the key components involved (CDROM drivers and the ATAPI interface software), and will most likely solve this issue since a new install worked.

Yes it does, as far as I know. I've tested it lately with music CDs but burning video DVDs have reproduced the same situation. That's a good idea. Unfortunately my previous attempts to load Ubuntu using Wubi were met with errors. I'll see if a LiveCD is good enough, though.
–
Ben RichardsDec 30 '11 at 1:53

Another option might be pendrivelinux, basically a bootable USB stick of the live cd of really almost any distro under the sun. I use it extensively for troubleshooting.
–
PaperlanternDec 30 '11 at 2:00

Well, I was able to get into a Kubuntu LiveCD and tried burning an audio CD using k3b, and it worked. It was only a single track, but it burned it quickly, and ejected the disc at the end. So it appears that it's a Windows issue, and not a hardware problem. I'll add this info to the main question, too.
–
Ben RichardsDec 30 '11 at 3:34

Okay, now we at least know that if we try drivers or OS troubleshooting, we aren't wasting our time with a hardware problem. If you pull up hardware manager and expand DVD/CD-ROM drives, do the drives list properly. ie, drives listed, are the models installed. Additionally, if they are, when was the driver released? Does it show who made it? Is it maybe using a MS driver where in we could then swap in the mfr driver, or vice versa? Perhaps even trying a right click and "update driver software" could yield a newer driver. Perhaps attempting to remove them and reboot to redetect them may help.
–
PaperlanternDec 30 '11 at 13:50

I checked this and they are Microsoft drivers (and the latest ones available), and the devices are installed properly. I'll look at installing a manufacturer driver.
–
Ben RichardsDec 30 '11 at 15:26

This sounds to me like it's a problem that Windows is having interfacing with your motherboard's chipset. Specifically, in speaking ATAPI to the CD Drive. Things I would recommend:

(NOTE: Please don't try more than one of these things at a time. It's never fun to solve something and not know exactly which step was the final piece to the puzzle. =) )

Update Motherboard Chipset

Go to the manufacturer's website for your motherboard and download the latest chipset drivers. It will require a reboot, but shouldn't require any kind of pre-Windows boot media. You should be able to update from within Windows.

Update storage controller

If your PC has a storage controller in it or a storage chipset (perhaps Matrox or Nvidia, as is the case in some consumer level PCs), update those chipsets / drivers.

Update BIOS

It's possible that part of the problem is in the BIOS's presentation of the attachment. Consider
updating to the latest BIOS from your PC manufacturer for the model in question.

Move the drive to a different SATA channel

If you have multple SATA ports, especially if you have ports that are on different controllers, move the optical drive to a new port on the motherboard.

Curiosities

I would be interesting in knowing if your BIOS is in IDE or AHCI mode. I would expect it to be in IDE mode, but it's possible that it's in AHCI.

EDIT 1

After finding out that the PC was switched from IDE to RAID/AHCI mode without a reinstall of Windows (and apparently it was something of an ordeal to get Windows to handle the change correctly) I believe that this might be the cause. Windows may be handling ATAPI communications slightly wrong now. I'm not sure yet what the solution would be. Perhaps a repair installation.

Also, I am using 2 hard drives in RAID0 so it's in RAID mode (AHCI, then, I would suspect), not IDE.
–
Ben RichardsJan 2 '12 at 1:50

@sidran32 In my understanding, no, those things aren't necessarily OS agnostic. The chipsets still need to be interacted with by the OS, so the OS is still a variable factor. Perhaps Windows needs the hardware layer to have updated firmware for it to more properly interact with it. The Linux OS you tried may have been capable of interfacing with the chipset in its current state as opposed to Windows.
–
WesleyJan 2 '12 at 1:58

I just updated my BIOS and had a look through. There's three options for the SATA mode-IDE, RAID, and AHCI. I've had it in RAID mode all this time (because of my RAID0 setup). Would it be more desirable if it was in AHCI mode? By the way, the BIOS update did nothing, as well as the chipset driver update. Both my drives act the same and are on two different SATA channels, obviously. Same controller/
–
Ben RichardsJan 2 '12 at 4:40

I tried installing a fresh version of Windows after not being able to run a repair console. The fresh installation of Windows handles the disc burning properly. So it may be, as suggested, something wrong with how Windows is communicating with ATAPI devices.
–
Ben RichardsJan 3 '12 at 4:22

Have you tried using different burning software? I'm a big fan of ImgBurn but too have found it often doesn't release the drive. Normally if I launch MakeMKV it will allow me to eject the disc (although it sounds like you already have a workaround).