Fusion 2705.1.11: adsk.drawing DrawingManager.createDrawing crashes Fusion (reproducible 3/3, also on 2704)

[wuttichai]

Product: Autodesk Fusion 2705.1.11 (Windows 11 Pro 26200), embedded Python 3.14.0. Also reproduced on 2704.1.53 (2026-09-02, twice). Reproducible 3 out of 3 runs.

API used (Python script, attached as createDrawing_crash_repro.py.txt - the forum does not accept .py, so rename it back to .py):
adsk.drawing.DrawingManager.get().createDrawingInput(dataFile, AutomaticDrawingCreationMode), then baseDocumentType = FromTemplateBaseDocumentType, templateFile = a saved .f2t title-block template resolved with app.data.findFileById, standard = ISO, units = mm, sheetSize = A3ISO, orientationType = Landscape, sheetCreationType = FirstLevelOnly, automationPreferences.globalPreferences (flat pattern + folded model + component sheets on, assembly/animation off, autoDimension on), flatPatternPreferences.orthogonalViewSheetPreferences.isBendTableIncluded = True (TopRight), isFoldedModelIsometricViewAdded = True, autoDimensionPreferences (Overall strategy, hole + thread notes), then mgr.createDrawing(inp).

Source document: a saved sheet-metal design with one body and one flat pattern (a configured design with 13 rows; the 09-02 runs used a plain single part). Everything else was saved and closed; only the source document was open.

Result: Fusion terminates about 4 s after "Workflow start: drawing" is logged, before any drawing canvas opens (FusionDrawing.log receives no entry at all). The AppLogFile shows the script's own main thread crashing:

Crashing thread ID: 502700
(module:KERNELBASE) UnhandledExceptionFilter
(module:VCRUNTIME140) memmove
(module:NsBaseCore10) Ns::JSONNode::toIString
(module:DrawingXLayerUI10) Ns::BREP::IBodyFaceterClient::operator=
(module:_drawing) (function-name not available)
(module:python314) PySequence_Tuple
(module:python314) PyObject_Vectorcall
(module:python314) PyEval_EvalFrameDefault
(module:NsBase10) Ns::PythonManager::runPyFunc / runScriptEx / runScript

Log lines immediately before the crash: GET 200 .../lineages/<template lineage> workflow:WIPRequest4, "Workflow start: drawing 1-6a9bbf34-...", GET 200 .../lineages/<source lineage> workflow:drawing, then the crash at 14:05:28 local time on 2026-09-05 (AppLogFile20260905T130903.log, lines 22840-22900 attached as fusion-createDrawing-crash-log-excerpt.txt).

Observed on 2704 as well (2026-09-02): two runs, both crashed after the drawing document had been created and uploaded; on those runs the template was also NOT applied (FusionDrawing.log: "TitleBlock":"ISO","FDocTemplate":false) although templateFile had been set.

Expected: createDrawing returns the DataFile of the new drawing built on the given template, or returns null / raises, without terminating the application.

Steps to reproduce:
1. Open a saved sheet-metal design (one body with a flat pattern is enough). Close every other document.
2. Utilities > Add-Ins > Scripts and Add-Ins > add the attached createDrawing_crash_repro.py.txt (renamed to .py) and Run it. The script writes one line per step to %TEMP%\createDrawing-repro-report.txt; the last line before the crash is "input ready -> createDrawing (synchronous) ...".
3. Fusion terminates about 4 s later. The Fusion Error Report (CER) dialog appears afterwards.

The template lookup (TEMPLATE_IDS in the script) points at our own "Title Block 05" template; replace it with any saved .f2t lineage id, or leave the list empty to run with FromScratchBaseDocumentType (the 2704 runs crashed with the template not applied at all).

The full AppLogFile (2.9 MB) and the CER folder from the 14:05 crash are available on request.