What causes "no such ctf intrinsic called: {ctf_type}" in dotnet/runtime?

Add an elif branch in generateFieldList (after line 213) that handles the new ctf_type value and constructs an appropriate field_body string.

dotnet/runtime · error · Exception

no such ctf intrinsic called: {ctf_type}

Error message

no such ctf intrinsic called: {ctf_type}

What it means

Thrown by generateFieldList() in the LTTng provider code generator when a Windows ETW manifest data type maps to a CTF (Common Trace Format) intrinsic that has no code-generation case in the if/elif chain. The generator looks up the CTF type from ctfDataTypeMapping and must emit a matching field body for ctf_string, ctf_integer/ctf_float, or ctf_sequence; reaching the final else means a new or unexpected CTF type was encountered that the generator was never taught to handle.

Source

Thrown at src/coreclr/scripts/genLttngProvider.py:216

            if fnparam.prop:
                #this is an explicit struct treat as a sequence
                ctf_type = "ctf_sequence"
                sizeofseq = fnparam.prop
                field_body = ", ".join((typewName, varname, varname, "size_t", sizeofseq))

            else:
                ctf_type = ctfDataTypeMapping[wintypeName]
                if ctf_type == "ctf_string":
                    field_body = ", ".join((varname, varname))

                elif ctf_type == "ctf_integer" or ctf_type == "ctf_float":
                    field_body = ", ".join((typewName, varname, varname))

                elif ctf_type == "ctf_sequence":
                    raise Exception("ctf_sequence needs to have its memory expilicitly laid out")

                else:
                    raise Exception("no such ctf intrinsic called: " +  ctf_type)

            field_list.append("        %s(%s)" % (ctf_type, field_body))

        field_list = "\n".join(field_list)

    return header + field_list + footer

def generateLttngHeader(providerName, allTemplates, eventNodes, runtimeFlavor):
    lTTngHdr = []
    for templateName in allTemplates:
        template = allTemplates[templateName]
        fnSig   = allTemplates[templateName].signature

        lTTngHdr.append("\n#define " + templateName + "_TRACEPOINT_ARGS \\\n")

#TP_ARGS
        tp_args = generateArgList(template, runtimeFlavor)
        lTTngHdr.append(tp_args)

View on GitHub (pinned to 290d5ab72c)

Solutions

Add an elif branch in generateFieldList (after line 213) that handles the new ctf_type value and constructs an appropriate field_body string.
If the type should not be a sequence, verify that the ctfDataTypeMapping entry for the offending win:* type is correct and maps to a supported intrinsic (ctf_integer, ctf_float, ctf_string, or ctf_sequence).
Run the generator with --dry-run to identify which template/parameter triggers the error before it raises, then inspect the manifest for the offending win:* type.

Example fix

// before (genLttngProvider.py, ctfDataTypeMapping extended but no handler)
ctfDataTypeMapping["win:MyNewType"] = "ctf_enum"
// ... generateFieldList hits else branch -> Exception

# after: add a handler branch
elif ctf_type == "ctf_enum":
    field_body = ", ".join((typewName, varname, varname))

Defensive patterns

Strategy: validation

Validate before calling

# Before calling generateFieldList, validate that all CTF types are handled
valid_ctf_types = {'ctf_string', 'ctf_integer', 'ctf_float', 'ctf_sequence'}
for template_name, template in allTemplates.items():
    fnSig = template.signature
    for params in fnSig.paramlist:
        fnparam = fnSig.getParam(params)
        if not fnparam.prop:
            ctf_type = ctfDataTypeMapping.get(fnparam.winType)
            if ctf_type and ctf_type not in valid_ctf_types:
                print(f"WARNING: unhandled ctf_type '{ctf_type}' for win:{fnparam.winType} in template {template_name}")

Type guard

def is_supported_ctf_type(ctf_type: str) -> bool:
    supported = {'ctf_string', 'ctf_integer', 'ctf_float', 'ctf_sequence'}
    return ctf_type in supported

Try / catch

# This is a build-time code generator; failures should surface immediately.
# No try-catch needed — let the exception propagate to halt the build with context.

Prevention

When adding a new entry to ctfDataTypeMapping, always add a corresponding branch in generateFieldList's if/elif chain.
Use a code review checklist that verifies ctfDataTypeMapping keys have matching handlers in generateFieldList.
Run the generator with --dry-run after manifest changes to catch errors before file generation.

When it happens

Trigger: Called during generateLttngHeader() -> generateFieldList() when iterating template parameters whose fnparam.prop is falsy (non-struct). The ctf_type resolved from ctfDataTypeMapping[wintypeName] does not match 'ctf_string', 'ctf_integer', 'ctf_float', or 'ctf_sequence'. This happens if the ctfDataTypeMapping dictionary is extended with a new CTF intrinsic value but the if/elif chain at lines 206-216 is not updated to emit a field_body for it.

Common situations: A developer adds a new win:* type to ctfDataTypeMapping (e.g., a hypothetical 'ctf_enum') without adding a corresponding branch in generateFieldList. Alternatively, a manifest introduces a data type that, through the mapping chain, resolves to an unhandled CTF category. This is a build-time code-generation failure, not a runtime error in production tracing.

Related errors

{eventNode} event does not have a symbol

AI-assisted analysis of dotnet/runtime@290d5ab72c (2026-08-06). Data as JSON: /api/errors/c97e09cfacbbeae3. Report an issue: GitHub.