dotnet/runtime · error

%s(%d) : error : %s at token '%s' in: %s

Error message

%s(%d) : error : %s at token '%s' in: %s

What it means

This is the Unicode-file branch of ilasm's generic IL parse-error reporter (grammar_after.cpp:244-246). When the parser encounters an unexpected token in a UTF-16 source file, it formats `file(line) : error : <msg> at token '<tok>' in: <source line>` to stderr using MAKE_UTF8PTR_FROMWIDE conversions of the token and current line. The actual cause is identified by the `str` argument (the grammar-specific error text), with this printf being only the carrier.

Source

Thrown at src/coreclr/ilasm/grammar_after.cpp:245

        len &= ~(size_t)1;
    }
    memcpy(tokBuff, PENV->curTok, len);
    tokBuff[len] = 0;
    tokBuff[len+1] = 0;
    if(PENV->bExternSource)
    {
        szfile = PASM->m_szSourceFileName;
        iline = PENV->nExtLine;
    }

    const char* fmt = "%s(%d) : error : %s at token '%s' in: %s\n";
    if(Sym == SymW) // Unicode file
    {
        // CodeQL [SM02986] Casting tokBuff to WCHAR* is safe because tokBuff is WCHAR-aligned and properly null terminated
        MAKE_UTF8PTR_FROMWIDE(tokBuffUtf8, (WCHAR*)tokBuff);
        // CodeQL [SM02986] Casting yygetline result to WCHAR* is safe because buff is guaranteed to be WCHAR-aligned
        MAKE_UTF8PTR_FROMWIDE(curLineUtf8, (WCHAR*)yygetline(PENV->curLine));
        fprintf(stderr, fmt,
                szfile, iline, str, tokBuffUtf8, curLineUtf8);
    }
    else
    {
        fprintf(stderr, fmt,
                szfile, iline, str, tokBuff, yygetline(PENV->curLine));
    }
    parser->success = false;
}

/********************************************************************************/
/* looks up the typedef 'name' of length 'nameLen' (name does not need to be
   null terminated)   Returns 0 on failure */
TypeDefDescr* findTypedef(_In_reads_(NameLen) char* name, size_t NameLen)
{
    TypeDefDescr* pRet = NULL;
    static char Name[4096];
    if(PASM->NumTypeDefs())

View on GitHub (pinned to 290d5ab72c)

Solutions

1. Read the `<msg>` (the `%s` error text) and the highlighted source line to find the exact grammar violation.
2. Open the .il file at the reported line and fix the offending token.
3. If unsure, re-disassemble a known-good DLL with ildasm and diff the IL.
4. Save the file as plain ANSI/UTF-8 if Unicode handling is the suspect.

Example fix

// before (Unicode .il, line 12): .method void Foo(bar)
// after:                                .method void Foo(bar) { ret }

// In a code generator, validate IL tokens before writing .il files.
// Reject unknown opcodes / undeclared symbols so ilasm never sees them.
if (!isKnownOpcode(tok) || !symbols.contains(operand)) {
    fail('IL syntax error would occur at line ' + lineNo);
}

When it happens

Trigger: Any IL syntax error while assembling a Unicode (.il) source file: a malformed instruction, an undeclared symbol, a bad signature, a misplaced keyword.

Common situations: Hand-written or generated IL with a typo; copy-paste between files that changed an encoding; a code generator emitting IL the current ilasm grammar rejects.

Related errors

• Out of memory!
• Out of memory!
• Out of memory in Indx256::IndexString!
• Out of memory!
• OpenSSL is not available, but required for build determinism

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