MS-XLSB clarification: record type 3072 (0x0C00) and PtgAttrIfError byte-offset calculation

Question

MS-XLSB clarification: record type 3072 (0x0C00) and PtgAttrIfError byte-offset calculation

Jasuja, Om 0

Hello,

I am implementing a read-only comparator for Excel binary (.xlsb) files and would appreciate clarification on two points in the MS-XLSB specification.

Record type 3072 (0x0C00)

Does decoded record type value 3072 (0x0C00) identify BrtUid?

If so, could you point me to the authoritative record-type mapping, structure definition, and applicable version information? Please also clarify any requirements for preserving this record when copying worksheet content.

PtgAttrIfError byte-offset calculation

The PtgAttrIfError structure defines its offset field as an unsigned integer specifying a byte offset.

Could you clarify:

The exact starting point from which the offset is measured.
The target location the offset must identify.
Which token bytes are included or excluded from the calculation.

A minimal worked example showing the formula token sequence, token lengths, and resulting offset would be very helpful.

This request concerns interpretation of the public MS-XLSB specification only. No workbook or business data is attached.

Thank you.

Jasuja, Om 0 Reputation points

2026-11-03T12:57:51.6533333+00:00
Thank you. The AI-generated answer leaves both clarification points open. Could a Microsoft Open Specifications engineer please review?

Please provide the authoritative record-number table entry establishing whether decoded record type 3072 (0x0C00) maps to BrtUid.

The illustrated PtgAttrIfError calculation produces 7 bytes by including the following PtgAttrGoTo. Is there any documented version-specific exception or alternative encoding under which the offset excludes that four-byte token and is instead 3? If not, please confirm the required interpretation and applicable specification section.

Public-specification clarification only; no workbook or business data is attached.

2 answers

Your answer

Jasuja, Om 0 Reputation points

2026-11-03T12:57:51.6533333+00:00

Thank you. The AI-generated answer leaves both clarification points open. Could a Microsoft Open Specifications engineer please review?

Please provide the authoritative record-number table entry establishing whether decoded record type 3072 (0x0C00) maps to BrtUid.

The illustrated PtgAttrIfError calculation produces 7 bytes by including the following PtgAttrGoTo. Is there any documented version-specific exception or alternative encoding under which the offset excludes that four-byte token and is instead 3? If not, please confirm the required interpretation and applicable specification section.

Public-specification clarification only; no workbook or business data is attached.

Answer 1

Kai-H 30,315 Microsoft External Staff Moderator

Hi, Jasuja, Om

I can help with both points, though the record mapping has a gap I can't close from public sources.

Record 3072. I couldn't find a published record-number table entry that ties 3072 to BrtUid. The BrtUid page (section 2.4.857) only defines the payload, a 16-byte GUID whose meaning depends on the record sequence it's in, and it gives no type value or version note. Mapping 3072 to BrtUid is a common convention in open-source XLSB parsers, not something the spec states. The SheetJS project ran into this same "unexpected record 3072" case back in 2018. They treated it as BrtUid as a best guess and flagged the missing table entry as a spec gap. For a read-only comparator, it is recommended that you treat 3072 as "probably BrtUid," show it as an opaque GUID, and not flag GUID-only differences as content changes. If you need an official ruling, you can contact the Open Specifications support team through the Support section of the Open Specifications Dev Center on Learn. Mention section 2.3 (Record Enumeration) and section 2.4.857. That team handles spec corrections and can confirm or add the entry.

PtgAttrIfError offset. I couldn't find any documented version-specific exception or alternative encoding where the offset is 3. Both the PtgAttrIfError and PtgAttrIf pages only say the offset is an unsigned byte offset. The actual rules are in the Rgce grammar (section 2.5.98.88), which measures offsets as EXPRESSION_SIZE.

The 7-byte reading also follows from how the jump works. When the first expression isn't an error, the evaluator skips past the fallback and the GoTo token, so it lands right on the IFERROR function token. With an offset of 3, it would land on the GoTo instead, and the GoTo would then jump past the function token. In that case IFERROR would never run.

Here's a quick way to check with a real file. Save =IFERROR(A1,0) as .xlsb and look at the formula bytes. You should see the A1 reference (7 bytes), then PtgAttrIfError (4 bytes, offset 7), then the integer 0 (3 bytes), then PtgAttrGoTo (4 bytes, offset 2), and finally the IFERROR PtgFunc (3 bytes, function number 480). That gives 3 + 4 = 7 for the PtgAttrIfError offset, and 3 - 1 = 2 for the GoTo.

Jasuja, Om 0 Reputation points

2026-11-04T10:46:32.44+00:00

Thank you for the Rgce grammar reference. Could you confirm whether the token sequence and offset values shown were measured from an Excel-generated XLSB file or derived from the specification? If measured, please provide the Excel version/build and a minimal non-sensitive token-byte example.

The observed value of 3 remains unexplained, so we would appreciate clarification of the exact byte-counting boundaries. Could the unresolved record-type 3072 mapping also be referred to the Open Specifications team?
Jasuja, Om 0 Reputation points

2026-11-04T10:47:20.3566667+00:00

Thank you for the Rgce grammar reference. Could you confirm whether the token sequence and offset values shown were measured from an Excel-generated XLSB file or derived from the specification? If measured, please provide the Excel version/build and a minimal non-sensitive token-byte example.

The observed value of 3 remains unexplained, so we would appreciate clarification of the exact byte-counting boundaries. Could the unresolved record-type 3072 mapping also be referred to the Open Specifications team?
Kai-H 30,315 Reputation points Microsoft External Staff Moderator

2026-11-05T06:27:47.37+00:00

Hi, Jasuja, Om

To answer your first question directly, those values were worked out from the specification and the standard token sizes. I didn't measure them from an Excel-generated file, so I can't give you an Excel version or build for them.

Here's the counting rule as I read the Rgce grammar. Counting starts at the first byte after the 4-byte PtgAttrIfError. It stops after the last byte of the PtgAttrGoTo that follows the fallback expression. The PtgAttrIfError itself, the first expression, and the final PtgFunc are all left out. The offset field is a little-endian 16-bit value stored in the last 2 bytes of the PtgAttrIfError token.

As for the 3, it is recommended that you double-check a few things before treating it as a spec issue. First, make sure the 3 actually comes from the PtgAttrIfError token and not from the PtgAttrGoTo. The GoTo offset is the size of the following function token minus one, so it comes out to 3 when that token is a 4-byte PtgFuncVar. Second, check that your parser reads the offset from bytes 3 and 4 of the token, not bytes 2 and 3. Third, confirm that you're walking the formula bytes themselves and not the 4-byte length field that comes before them in the formula structure.

If none of those explain it, please post the raw bytes of the formula, written as decimal values, along with the formula text and the Excel build that saved the file. That would let us compare it with the spec line by line.

On the 3072 mapping, I can't open a case with the Open Specifications team for you. I'd still recommend contacting them directly through the Support section of the Open Specifications Dev Center on Microsoft Learn. That way you get your own case number and an official answer on both the record table entry and the IFERROR offset question.

Hope this helps.

Answer 2

The specification confirms that BrtUid contains a 16-byte GUID, but the supplied authoritative sections do not establish that decoded record type 3072 (0x0C00) maps to BrtUid; that mapping should therefore not be implemented without checking the record-number table in the applicable MS-XLSB revision.

`BrtUid`

MS-XLSB section 2.4.857 defines BrtUid as follows:

It specifies a unique identifier for an object.
Its payload is exactly one 16-byte uid GUID.
The object being identified is determined by the record sequence containing the record—not by BrtUid alone.^1^

The section number 2.4.857 is a document section number, not a record-type value. Nothing in the available authoritative material provides the normative record-type-table entry connecting BrtUid to 0x0C00. Also verify that 3072 is the value produced after decoding the XLSB variable-length record-type field, rather than a raw two-byte little-endian interpretation.

For a comparator, keep these concepts separate:

record type: decoded from the record header
record size: decoded from the record header
record data: for BrtUid, 16-byte GUID
meaning: determined by the enclosing record sequence

Version and preservation

The current BrtUid page does not include a product-version note in the supplied text, so it is not sufficient to claim which Excel release first introduced that record. XLSB itself dates from Excel 2007, but that does not prove that every record in the current specification applies to every XLSB-producing version.^2^

No BrtUid-specific copying rule is present in the supplied MS-XLSB sections. Consequently:

A read-only comparator can compare the 16 payload bytes and report the containing record sequence.
Do not treat two differing UIDs as proof that the identified worksheet content differs semantically.
Do not claim a normative requirement either to preserve or regenerate the UID without the applicable enclosing record-sequence rule.
If performing a byte-preserving transformation rather than using Excel’s object model, retaining an unmodified, understood record is the conservative implementation choice, but that is not established here as an MS-XLSB requirement.

`PtgAttrIfError.offset`

PtgAttrIfError is a four-byte control token:

Component	Size
`ptg` plus `reserved1`	1 byte
`reserved2` plus `bitIfError`	1 byte
`offset`	2 bytes
Total	4 bytes

Its ptg value must be 0x19, bitIfError must be 1, and offset is an unsigned two-byte integer.^3^

The governing Rgce grammar is:

iferror-expression =
    expression
    PtgAttrIfError
    expression
    PtgAttrGoTo
    PtgFunc

The offset equals the total encoded size, in bytes, of every Ptg after PtgAttrIfError through and including the first PtgAttrGoTo.^4^

Therefore:

Starting boundary: immediately after the complete four-byte PtgAttrIfError.
Target boundary: immediately after the first following PtgAttrGoTo.
Excluded: all bytes of PtgAttrIfError, the expression before it, and the trailing PtgFunc.
Included: every byte of the fallback expression following PtgAttrIfError, plus every byte of the first PtgAttrGoTo.
Count complete serialized Ptg structures, including their opcode and fields—not merely operand data.

Worked offset calculation

Assume the parser measures this serialized token stream:

Token	Encoded size	Running position
First expression	5	0–4
`PtgAttrIfError`	4	5–8
Fallback expression	3	9–11
First `PtgAttrGoTo`	4	12–15
`PtgFunc(IFERROR)`	N	16 onward

Then:

PtgAttrIfError.offset
    = size(fallback expression) + size(first PtgAttrGoTo)
    = 3 + 4
    = 7 bytes

Equivalently, using zero-based stream positions:

offset = position immediately after PtgAttrGoTo
       - position immediately after PtgAttrIfError
       = 16 - 9
       = 7

The final PtgFunc is excluded. Its iftab must be 0x01E0, identifying IFERROR. Separately, the PtgAttrGoTo.offset equals one less than the encoded size of that trailing PtgFunc.^4^

These conditional control tokens prescribe short-circuit evaluation and may be ignored only when converting the parsed expression to textual formula syntax—not when validating or reproducing the binary token stream.^5^

References