[redbluevn]

The problem

CadOle2FrameTemplate.build recovers the frame's four corners by parsing the OLE2 payload, and builds a StreamIO over CadObject.BinaryData without checking there is one:

if (this.Chunks.Any())
{
    this.CadObject.BinaryData = this.Chunks.SelectMany(c => c).ToArray();
}

StreamIO reader = new StreamIO(CadObject.BinaryData);   // null here

AutoCAD's own DXF export writes an OLE2FRAME's geometry as XDATA — 1001 ACAD / 1000 OLEBEGIN / 1070+1040 pairs — and emits no binary chunk at all. So Chunks is empty, BinaryData stays null, and new MemoryStream(null) throws ArgumentNullException.

That exception comes out of CadDocumentBuilder.BuildDocument, so it is not one frame that is lost — it is the whole file. A drawing of 32,571 entities holding twenty OLE frames could not be read back from AutoCAD's own DXF export of it at all:

Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'buffer')
   at CSUtilities.IO.StreamIO..ctor(Byte[] arr)
   at ACadSharp.IO.Templates.CadOle2FrameTemplate.build(CadDocumentBuilder builder)
   at ACadSharp.IO.CadDocumentBuilder.BuildDocument()
   at ACadSharp.IO.DXF.DxfDocumentBuilder.BuildDocument()

The fix

Return early when there is no payload, or one too short for the block that follows (two bytes plus four points of three doubles), and notify rather than fail silently. The corners keep their defaults, which is all that can honestly be said when the data they come from is absent.

How it was found

By asking a question the round-trip census cannot: not "did we keep what we read" but "did we read what is there". Comparing a reading of a DWG against a reading of AutoCAD's DXF export of the same drawing crashed on the second half before it could compare anything.

Tests

Ole2FrameWithoutPayloadTests writes a real document, splices in an OLE2FRAME shaped the way AutoCAD writes one — subclass, flags, an OLE label, and no 310 anywhere — and asserts the rest of the document survives.

Worth noting how the first attempt at this test was useless: constructing an Ole2Frame in code and round-tripping it passed against the unfixed code, because the writer never emits an entity in that state. Only a fixture that reproduces AutoCAD's actual shape goes red. It does, with exactly the exception above.

dotnet test on this branch: 2314 passed / 17 failed, against master at 592d70a on this machine at 2313 / 17 — the same pre-existing failures, plus the one test added here.

Related

#1223-#1232, DomCR/CSUtilities#23.