Apparent decade-old bug prevents a Blu-ray disc from being fully written – error 0x80071AC3 examined.

[xio]

This post was originally going to be a question, but upon further examination, I have figured out a likely cause. The error 0x80071AC3 which could occur while copying files to a BD-R (Blu-ray disc recordable) is likely caused by a decade-old bug in the UDF 2.60 live file system driver of Windows, which prevents the metadata track on Blu-ray discs from being fully made use of.

Here is the text of the original post I was going to make, below which is a possible explanation:

The error 0x80071AC3 occured while archiving files onto a single-layer Blu-ray disc (BD-R).

I suspect that the cause of this is that the space on the UDF metadata partition is exhausted. Can an expert confirm this?

Below are some signs that support and contradict this idea.

On BD-R (Blu-ray disc recordable) media, a new feature called "pseudo-overwrite" was introduced. This feature was added to the UDF (universal disk file system) version 2.60, which was made for the Blu-ray disc. As I understand it, instead of appending new sessions where new files and their meta data (file name, time stamps, etc.) are written after the existing data, as is done on CD-R and DVD-R and DVD+R, Blu-ray reserves some space at the beginning for meta data to speed up the reading process, since the list of files is in one centralized location rather than spread out over the entire media, or does not have to be re-written in its entirety for each session. To achieve this, some space is reserved at the beginning. I suspect that this error occured because said space was exhausted.

I don't know of any way to allocate a larger space for the meta data area. Perhaps I will create a new thread for it, except if someone posts a method here, for which I would be thankful.

A sign that contradicts this idea is that the first non-resident file starts at sector 549888, and the blocks 72000 to 549887 are just null bytes, suggesting it is unallocated space. I tested this by searching for the hexadecimal value "01" in HxD starting after sector 71999. "Resident" means that the file is small enough that it can be housed directly into the file table rather than being written "out there" in the data area, which, for reference, is a feature the default Windows file system NTFS has as well but FAT32 and exFAT do not. However, it also seems unlikely to be a co-incidence that the last written sector within the data area happens to be 71999. If the last written block in the meta data track were something random such as 72237, the likelihood of some hardware-based error having occured would be higher, but it is exactly 71999.

This is the text of the error message that appeared when the process of copying a few thousand files was interrupted, unfortunately in German since that is my system language:

1 unterbrochene Aktion
Aufgrund eines unerwarteten Fehlers können Sie die Datei nicht kopieren. Wenn der Fehler weterhin ausgegeben wird, können Sie mithilfe des Fehlercodes in der Hilfe nach diesem Problem suchen.
Fehler 0x80071AC3: Der Vorgang konnte aufgründ einer Verunreinigung des Volumes nicht abgeschlossen werden. Führen Sie "chkdsk" aus, und wiederholen Sie den Vorgang.

In short, the error says copying was interrupted due to an "unexpected error" with the code 0x80071AC3, that the volume is "unclean", and it wants me to run CHKDSK.

Here is the command line output from CHKDSK /F D:\ . The diacritic characters Ä, Ö, Ü, and ß were not written correctly; "besch„digt" ("beschädigt") means damaged, "Hauptmetadatei" means main meta data, and "Spiegelmetadatei" means mirror meta data.

Der Typ des Dateisystems ist UDF.
Das Feld fr aufgezeichnete Bl”cke im ICB in Block "25312" wird korrigiert.
Die Hauptmetadatei in Block "25312" ist besch„digt.
Das Feld fr aufgezeichnete Bl”cke im ICB in Block "25376" wird korrigiert.
Die Spiegelmetadatei in Block "25376" ist besch„digt.
Die Hauptvolumebeschreibungssequenz ist besch„digt oder nicht lesbar.
Es wird versucht, die Reservevolume-Beschreibungssequenz zu lesen.
Ein logisches Volume konnte nicht mithilfe der Haupt- oder
Reservevolumebeschreibungssequenz definiert werden. Chkdsk wurde abgebrochen.

CHKDSK reports that the main meta data in block 25312 and the mirror meta data in block 25376 are damaged, meaning it is unable to repair the file system, leaving it in a read-only state. This means that the remaining free space on the disc is wasted since it is not useable.

I looked into the sectors 25312 and 25376 using HxD (freeware hex editor), and they sectors contain only null (00) bytes.

The time a file is written to disc is thankfully recorded in the "last access time" attribute, so when sorting the directory by descending last access time, I can examine that the final written file, the third-last, and the fourth-last files are blank (only null bytes), however, strangely, the second-last written file appears as normal. The last written file also lost its last modification date and time, and it is the same as the last access time, meaning the time it was written to disc. If this happened during a move instead of a copy, several files could have been deleted from the source without having been transferred to the target disc. This is why the safe way to transfer files is to copy, compare file count and byte size, and only delete from source if they match.

---

While drafting this post, the same fault occured on a BD-R DL (dual layer) on a different computer, also running Windows 10. Windows made the USB disconnect sound and then the USB connect sound, which I observed since I was in the room of the computer and not absent like the previous time.

This time, the last written sector in the metadata area is 63327, and the first non-resident file sector is 550295, so both are different. The meaning of "resident" is explained inside the quote above, which was originally going to be this post. However, CHKDSK also reports that the main meta data in block 25312 and the mirror meta data in block 25376 are damaged, which are the exact same numbers as in the CHKDSK result from the single-layer Blu-ray disc mentioned in the quote.
The same results occur on a different Blu-ray drive and a different computer with Windows 10, so the common denominator is the Windows UDF driver, which seems to be unable to handle a high number of files (over 10000) reliably.

On optical discs, the written and unwritten parts are visible using the bare eye. On both these discs, there is a writing gap near the beginning, meaning that this part is not written to.

I think a fix in the UDF driver by Microsoft could solve this problem and also make the rest of the space useable again, but I doubt that much about the UDF driver has changed since the days of Windows Vista, where it was introduced into its current form. I presume that it was developed once and barely touched since then. I even doubt that the original developers of the UDF drivers are still working at Microsoft. So all that could fix this is a third-party packet writing software. However, those presumably were barely developed since the Windows Vista era due to its native packet writing support, which usurped third-party software that might not had such bugs. The integration of UDF packet writing since Windows Vista appeared to have rendered third-party software obsolete, but some third-party software might not have this bug.

Another way would be to author and append to Blu-ray discs using conventional multi-session with a software like ImgBurn or InfraRecorder or CDBurnerXP, but that is of course far less convenient than the USB-stick-like file management workflow in Windows Explorer. If I wanted to rename something, it would have to wait for the next writing session.

One could also pack many files into a ZIP or 7-Zip archive, which reduces the file count and hence the usage of the metadata track, and indeed, it makes sense for many small text-based files such as saved pages with resources inside a _files sub folder. But for multimedia (photographs, videos, audio), it is far more convenient to be able to play the files back directly from the media and having a miniature view directly in Windows Explorer, rather than having to extract the files first.

 

[xio]

Use CMD or powershell for writing to Blu-ray.
You can place files you wish to write to a BD-R into a temporary folder, then use the "copy" or "move" commands in CMD or powershell to write it to the disc. For powershell copying, make sure to use the -Recurse parameter or it will create a blank folder only.

Why use CMD or powershell?

It appears that writing files using the copy and move commands of CMD or powershell causes fewer ICB (information control blocks) to be written per file. In other words, the list of existing files on the BD-R is updated less often, because when writing to Blu-ray using CMD or powershell, the Blu-ray writer changes speed less frequently, and there are fewer movements from the optical pickup system (laser lens movement). These noises are hearable less often.

UDF 2.60 appears to place ICB (Information Control Blocks) at the beginning of the disc rather than interspersed with written files, so the laser lens has to go to the beginning of the disc (inner edge) repeatedly while writing files. Whenever the laser lens goes to the beginning (inner edge), the drive spins up. If data is written using CLV (constant linear velocity), the same writing speed causes a faster spin when the laser lens is at the inner edge of the disc.

The only disadvantage of writing ICBs (Information Control Blocks) less often is that an unexpected power-off while files are being written to the disc would cause more files to disappear from the directory listing. But the benefit, it appears, is that it reduces the likelihood of the 25312 25376 bug occurring.

Sadly, there appears to be no way to manually specify how often ICB (information control blocks) should be written. If the computer is connected to a stable power supply, there is less of a need to write ICB (information control blocks).

It can also be assumed that a high number of ICBs (information control blocks) slows down the loading of file lists. As a reference, loading file lists on UDF 2.60, the file system used for Blu-ray, is similarly as slow as on MTP (Media Transfer Protocol), which is used by smartphones through USB.

25312 25376 - the numbers of death.

That 25312 25376 bug makes the BD-R read-only. The remaining space on the BD-R becomes unusable, hence wasted. This is especially bad for BDXL and M Discs, which are expensive per piece.

User GaryWaldon48 from Microsoft's own forum has reported this problem in 2016: Redirecting .

His CHKDSK output:

The type of the file system is UDF.
Correcting Recorded Blocks field in ICB at block 25312.
Main metadata file at block 25312 is corrupt.
Correcting Recorded Blocks field in ICB at block 25376.
Mirror metadata file at block 25376 is corrupt.
Main Volume Descriptor Sequence is corrupt or unreadable.
Attempting to read the Reserve Volume Descriptor Sequence.
Cannot define a logical volume using main or reserve Volume
Descriptor Sequence. Chkdsk aborted.

This is the same output I get in German, since that is my system language. My output is in the first post.

Possibly this could be fixed by ignoring the ICBs (information control blocks) 25312 and 25376 and reverting to an earlier state. While this would probably cause the last few added files to disappear, at least it would make the free space on the BD-R useful again, and get the BD-R out of the write-protected state! But Microsoft probably last worked on their UDF (Universal Disk Filesystem) driver and the UDF part of CHKDSK in 2009. This is not good, given that optical discs are the only sane media for multi-decade-long archival, and even centuries in the case of M-Disc.