STATUS_STACK_OVERFLOW (0xC00000FD) in UiPath.Executor.exe, on CoreCLR 10.0.9

Help Community
, , ,
1

Captured a full memory dump (WER LocalDumps, DumpType 2) from the latest crash and ran !clrstack, kb, and !analyze -v against it. All three point to the same thing.

Exception: STATUS_STACK_OVERFLOW (0xC00000FD) in UiPath.Executor.exe, on CoreCLR 10.0.9.

Call chain: TelemetryClient.Implementations.Operations.Operation.Dispose() → Newtonsoft.Json.JsonConvert.SerializeObjectInternal → thousands of repeating JsonSerializerInternalWriter.SerializeObject / SerializeDictionary frames, each against a distinct object instance (confirmed via differing addresses in kb, so this isn’t simple self-reference, it’s a genuinely deep, real object graph). The exact frame where the stack finally gives out varies by run (GC internals one night, StringBuilder.AppendWithExpansion the next), same underlying recursion both times, just caught at whatever ordinary call happens to be running at that instant.

Reproduction: happens on long (8+ hour), high-iteration executions, consistently many hours and dozens of iterations in, never early. Confirmed on multiple runs.

Ruled out:

  • Studio’s debugger: reproduced via a published package run through Assistant, no debugger attached.
  • UiPath.UIAutomation.Activities version: reproduced on both 26.1.0-preview and stable 26.10.3.
  • My own workflow: the entire call chain is inside UiPath’s shipped assemblies (TelemetryClient, UiPath.Core.Activities), not user code.

Environment

  • UiPath Studio 2026.0.201 (STS channel). Run on recent upgrade showed the same symptoms
  • Robot/Executor build 26.0.200-cloud.24638 (please confirm current build matches before triaging, may have moved since capture)
  • CoreCLR 10.0.9 (.NET 10)
  • UiPath.UIAutomation.Activities: reproduced on both 26.1.0-preview and stable 26.10.3
  • Windows 10 (build 19041 per dump), attended execution via UiPath Assistant, no Studio debugger attached
    clrstack-trimmed.txt (11.9 KB)
    kb.txt (50.1 KB)
    analyze.txt (71.2 KB)

Why such long runs? The automation takes it’s time between iteration events deliberately. Allowing back-office systems to do their work before proceeding.

Suspected cause: something the Operation telemetry wrapper holds or chains grows across the life of a long execution rather than resetting, and gets serialized in full at Dispose(). The Newtonsoft.Json call doesn’t appear to have a MaxDepth set, so an unusually deep object graph causes an uncatchable stack overflow (kills the whole process) instead of a handled exception.

Dump analysis attached (kb.txt, analyze.txt, clrstack-trimmed.txt, full !clrstack output was ~5000 lines, so I trimmed the repeating middle section). Happy to provide the full 3GB dump privately if that helps, would rather not post a raw memory dump publicly.

2

Hi Dave,

Thank you for sharing such a detailed investigation. The dump analysis and the fact that you reproduced the issue across multiple runs and UIAutomation package versions are very helpful.

Since the stack trace appears to stay entirely within UiPath’s telemetry and JSON serialization code, and the issue only occurs after long-running, high-iteration executions, your observation about an object graph growing over time sounds worth investigating.

The fact that the crash occurs at different frames on different runs also seems consistent with the stack gradually reaching its limit rather than a problem with one specific activity.

As a temporary workaround, have you tried splitting the long execution into smaller runs or restarting the process after a certain number of iterations? It would be interesting to see whether that prevents the stack overflow.

Since you already have a full memory dump and detailed stack traces, this looks like something the UiPath product/engineering team may need to investigate. Providing the dump privately through an official support channel would probably be safer than sharing the 3GB dump publicly.

Hopefully someone from the UiPath team can confirm whether this is a known issue with the current Robot/Executor build or telemetry implementation.

3

@DaveF From the dump, it looks like the crash is happening while UiPath telemetry is trying to serialize a very deep object structure. Since it only happens after many hours/iterations, I would check whether any Dictionary, List, DataTable, JObject, exception object, or custom object is continuously growing inside the loop.

Please try b elow steps:

  • Reinitialize/clear large variables after each iteration if they are no longer needed.
  • Avoid logging complete complex objects. Log only required values/strings.
  • Reduce verbose/trace logging and test again.
  • Update Robot/Studio and activity packages to the latest compatible version.
  • Run the process in smaller batches and monitor whether memory/object count keeps increasing.

The main stack pattern is:

Operation.Dispose() → JsonConvert.SerializeObjectInternal() → repeated SerializeObject/SerializeDictionary

So I would focus on identifying which object is reaching the telemetry/logging serializer and becoming very deep over time.

If possible, share a few stack frames just before the repeated Newtonsoft calls and whether you are using any custom logging or large JSON/Dictionary objects.

4

Hi @DaveF

Thanks for sharing such a detailed analysis. The dump findings do seem to point to a deep object graph being serialized during the telemetry operation disposal.

Since you have reproduced it consistently on long-running executions and across different UI Automation package versions, this looks worth investigating as a potential product issue.

I would recommend opening a UiPath Support ticket and sharing the full dump privately with the UiPath team, as it could help them identify what is growing during the execution.

5

Do you have any workflows that invoke themselves? or something like that? Or variables such as lists or dictionaries that keep getting added to?

This could genuinely be you blowing out the stack by doing that and after 8 hours the stack just becomes too big?

Its a tangent, but if you need to pause between steps, you can suspend the process btw, you dont need to keep it logged in and active for hours between as you wait for data.

6

Thanks for the suggestions, I’ll do some experimenting over the next few nights.

A year ago this would run for up to 15h without issue, performing consistently while executing each iteration through the job file. As the run is an overnight job, breaking it into smaller batch runs is a little tricky as the script needs a password entered manually when initiated. Given the performance degradation each iteration until crash happening now I would assume the batches would stop the crash.

There have been some changes to the script since then - mainly to remove one of the large files from memory and only write out to append to it, and replacing some packages with use official UiPath packages. Both of those I would have thought would have improved the situation. Other minor changes I can’t think of right now may have introduced the issue.

All packages are the latest versions.

I did try to log a support ticket but was unable to login for some reason. I’ll try again from another device.

7

Sounds very strongly that you genuinely have an infinite loop somewhere that creates a stack that keeps getting bigger causing the degredation.

8

The whole run is a loop in a way, with some smaller loops within it - it cycles through a list each night and each item in the list will have up to 12 years of data to process and record the output to file. To that end, none of the loops should be infinite.

Tips on how to identify if and which of my loops are the problem over the evidence for CoreCLR appreciated, although I have done a lot of analysis/testing on that point to no avail.

9

While one of the DTs is large as it’s holding the file. It doesn’t typically grow so much as get updated as the bot cycles through it.
No main workflow is a series, not a loop. One part of the workflow contains a while loop that works through the file, with a few small while loops in it as time series data is captured and updated. It should never get stuck in a repeated loop on a single row or sections of data, and the logs back that up.
I’m not saying you’re wrong, I just haven’t been able to find evidence of that with my potentially limited investigating skills.
Of the few variables are written to logs, all are converted to strings first, and all of them are small/short.

10

Also, @MayureshOfficial_45, I’m on the Community Licence, and as such I am unable to log a support ticket. That’s not to say the issue isn’t real. and the above will be all the company can use to try to fix it