dotnet/wpf · error · OutOfMemoryException

message (formatted LS error message, e.g. SR.SetTabsFailure…

Error message

message (formatted LS error message, e.g. SR.SetTabsFailure + lserr)

What it means

TextFormatterContext.ThrowExceptionFromLsError converts a native line-services (LS) error code into a managed exception: OutOfMemory becomes OutOfMemoryException, anything else becomes a plain Exception carrying the formatted LS error message. Callers like Init, SetBreaking, SetDoc, and SetTabs pass an LS error code when the unmanaged line-layout engine rejects an operation. It signals a failure inside the low-level text shaping/breaking engine rather than a caller-side misuse.

Solutions

Check the appended lserr value in the message to identify the specific native failure
Retry on a smaller text chunk to rule out resource exhaustion
Ensure text source is not modified between format passes (TextSource consistency)
If reproducible, capture the lserr and report; most LS errors are internal-invariant issues

Example fix

try { formatter.FormatLine(...) } catch (Exception ex) when (ex.Message.Contains("lserr")) { /* inspect lserr, retry or log native failure */ }

Defensive patterns

Strategy: try-catch

Try / catch

try { formatter.FormatLine(...); } catch (Exception ex) when (ex is OutOfMemoryException || ex.Message.Contains("lserr")) { logNativeFailure(ex); }

Prevention

Keep TextSource stable across format passes
Avoid formatting pathologically large text in one pass
Log lserr codes for support when reproducible

When it happens

Trigger: Any TextFormatterImp operation where the underlying LS engine (CreateLine, AddTextRun, SetTabs, etc.) returns a non-None LsErr, e.g. internal line-layout failure or native out-of-memory during formatting.

Common situations: Formatting extremely large or corrupt text payloads exhausting memory, passing runs/properties the LS engine cannot handle, or native component state corruption mid-layout.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14). Data as JSON: /api/errors/b72580090ed28ea0. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/textformatting/TextFormatterContext.cs:391

            Invariant.Assert(_ploc != System.IntPtr.Zero);
            LsErr lserr = UnsafeNativeMethods.LoSetTabs(
                _ploc,
                incrementalTab,
                tabStopCount,
                tabStops
                );

            if(lserr != LsErr.None)
            {
                ThrowExceptionFromLsError(SR.Format(SR.SetTabsFailure, lserr), lserr);
            }
        }


        internal static void ThrowExceptionFromLsError(string message, LsErr lserr)
        {
            if (lserr == LsErr.OutOfMemory)
                throw new OutOfMemoryException (message);

            throw new Exception(message);
        }


        internal static bool IsSpecialCharacter(char c)
        {
            return _specialCharacters.ContainsKey(c);
        }

        private static void SetSpecialCharacters(ref LsContextInfo contextInfo)
        {
            Dictionary<char,bool> dict = new Dictionary<char,bool>();

            /* The first three char fields do not designate special characters
            dict[contextInfo.wchUndef] = true;
            dict[contextInfo.wchNull] = true;
            dict[contextInfo.wchSpace] = true;

View on GitHub (pinned to 81131a70a4)