Segfault when using `asc-fdl` python library inside Nuke 16+ on Windows (MSVCP140.dll related)

[eden-annn]

Hello,

My name is Eden (eden.an@eyelinestudios.com), and I'm a Software Engineer at Eyeline Studios. First of all, congratulations on the successful first release of ASC‑FDL. This is a big achievement, and I'm sure it will bring significant benefits to the industry.

We've started testing the Python library internally as well, and we've encountered a crash in a specific DCC (Nuke) when using a particular command. After a brief investigation, I'm filing this issue report with the details below.

Context

asc-fdl (installed via pip) works fine with standalone Python 3.11 but segfaults inside Foundry Nuke 16 and 17 on Windows when calling add_framing_intent.

Environment

• OS: Windows 10 Pro (x64)
• asc-fdl: 1.0.2
• Standalone Python: 3.11.9 — works
• Nuke 16.0, 17.0 (embedded Python 3.11) — crashes

Steps to Reproduce

Run the following in Nuke 16's Script Editor or embedded Python:

from fdl import FDL, DimensionsInt

my_fdl = FDL()
my_fdl.add_framing_intent(
    id="FI178",
    label="1.78-1 Framing",
    aspect_ratio=DimensionsInt(width=16, height=9),
    protection=0.088,
)
# Segmentation fault

Cause

We found that Nuke 16 ships an older MSVCP140.dll (version 14.36) in its application directory, while the system-installed version is 14.44. We think fdl_core.dll might dynamically link to MSVCP140.dll, and pick up Nuke's older copy at runtime, causing a segfault.

Verified with PowerShell:

(Get-Item 'C:\path\to\Nuke16.0v4\MSVCP140.dll').VersionInfo.FileVersion
# 14.36.32532.0

(Get-Item 'C:\WINDOWS\SYSTEM32\MSVCP140.dll').VersionInfo.FileVersion
# 14.44.35112.1

Workaround

Pre-loading the system MSVCP140.dll before importing fdl works in Nuke's command-line Python:

import ctypes
ctypes.CDLL(r"C:\WINDOWS\SYSTEM32\MSVCP140.dll")

from fdl import FDL, DimensionsInt  # works

This does not work in Nuke GUI mode though, as Nuke loads its own MSVCP140.dll at process startup before any Python code executes.

Suggested Fix

We wonder if a static link the MSVC C++ runtime when building fdl_core.dll could eliminate the external MSVCP140.dll dependency entirely and is the standard approach for native libraries distributed as Python wheels intended for use inside VFX DCC applications (Nuke, Maya, Houdini, etc.), which typically ship their own (possibly older) MSVC redistributables.