@uipath/skills 1.199.0 → 1.200.0

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/job-consecutive-system-exceptions.md

@@ -0,0 +1,47 @@
+---
+confidence: medium
+---
+
+# Maximum Consecutive System Exceptions Reached
+
+## Context
+
+A job (typically REFramework or any retry-looping process) aborts after hitting its consecutive-System-Exception ceiling. **The message is a symptom, not the root cause** — the real fault is the underlying System Exception that recurs on every transaction until the threshold trips.
+
+What this looks like:
+- `The maximum number of consecutive system exceptions was reached. Consecutive retry number: <N>`
+- Job Faulted after processing 0 (or very few) transactions successfully
+- The SAME underlying exception appears N times in the logs just before the abort line
+- Common in REFramework processes where a system-level dependency is broken
+
+What can cause it (the underlying recurring exception):
+- A broken selector / UI change — `SelectorNotFoundException` on the same activity every transaction
+- An application that fails to launch or is not in the expected state
+- A down/unreachable dependency (database, API, network share, Orchestrator asset/queue)
+- Credential/permission failure repeated per transaction
+
+The threshold itself (`MaxConsecutiveSystemExceptions` in REFramework `Config.xlsx` / an asset) only decides *how many* failures before giving up — it does not cause the failure.
+
+## Investigation
+
+1. Get the failing job and confirm the abort signature:
+   `uip or jobs get <job-key> --output json` — `Info` = "maximum number of consecutive system exceptions was reached".
+2. **Find the underlying recurring exception** — this is the real target:
+   `uip or jobs logs <job-key> --level Error --output json` — look at the errors BEFORE the "max consecutive" line. The same System Exception (type + activity) repeated N times is the root cause.
+3. Confirm the repeated failing activity in traces:
+   `uip or jobs traces <job-key> --output json` — the same activity Faulted across consecutive transactions.
+4. Classify it: is the recurring error a **System** exception (environment/UI/dependency — retried and counted) or a mis-classified **Business** exception? Business rule violations should be thrown as `BusinessRuleException` so they do not consume the system-exception budget.
+
+## Resolution
+
+- **Fix the underlying recurring System Exception** — that is the root cause. Examples:
+  - Broken selector → re-indicate the element / use Object Repository / add a reliable anchor; add `Check State` before the action.
+  - App not in expected state → fix the init/launch sequence; add `Activate`/wait-for-ready.
+  - Down dependency → restore/repoint the database/API/share; verify the asset/credential.
+- **Do NOT just raise `MaxConsecutiveSystemExceptions`** — a higher threshold only delays the same abort while burning more attempts. Raise it only after the underlying fault is fixed and you have a legitimate reason to tolerate more transient failures.
+- **Re-classify mis-typed exceptions** — throw genuine business-rule violations as `BusinessRuleException` so they route to the business-exception path instead of the system-exception counter.
+- **Rerun** after fixing the underlying exception.
+
+Prevention:
+- Treat "max consecutive system exceptions" as an alert to investigate the *first* recurring exception, not as the fault itself.
+- Keep System vs Business exception classification correct so the counter reflects real environmental failures.

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/job-faulted-session-timeout.md

@@ -14,37 +14,37 @@ What this looks like:
 - Crucially, there is **NO** Windows logon-failure/locked/RDP-refused signature: no `Logon failed for user`, no `account is locked`, no `RDP connection failed`, no `0x0000052E` / `0x00000775` / `0x00000532` / `Last error: 131092`. A pure timeout, not an LSA verdict.
 - Often intermittent — a re-run of the same job on the same machine may succeed.
 
-What can cause it (pick the branch from evidence):
+What can cause it — session creation legitimately took longer than the timeout window. Common drivers:
 
-1. **Known Robot defect on versions earlier than 23.10** (primary documented cause) — a session-creation defect in the Robot times out even on a healthy host; the fix shipped in the Robot 23.10 release. Fingerprint: the executing Robot's version is **< 23.10** AND the host is otherwise healthy (no resource saturation, interactive logon is not abnormally slow). Confirm the exact fixed version against the KB (see Investigation step 5) — the minor-version threshold can move.
-2. **Slow interactive Windows logon on the host** — a heavy roaming/mandatory profile, synchronous GPO processing, logon scripts, or real-time AV scanning delays session creation past the timeout. Fingerprint: Robot version **≥ 23.10**, and interactive logon on the host is observably slow for humans too.
-3. **Host resource exhaustion** — CPU/RAM/session saturation on the target machine prevents timely session creation. Fingerprint: host metrics show saturation around the fault time.
+1. **Slow interactive Windows logon on the host** — a heavy roaming/mandatory profile, synchronous GPO processing, logon scripts, or real-time AV scanning delays session creation past the timeout. Interactive logon on the host is observably slow for humans too.
+2. **Host resource exhaustion** — CPU/RAM/session saturation on the target machine prevents timely session creation; host metrics show saturation around the fault time.
+3. **Infrastructure / network latency** — slow domain-controller reachability, profile-share latency, or general network/server performance between the Robot and the resources session creation needs.
+
+> **Not a Robot-version defect.** There is no documented Robot version that "fixes" this error and no version below which it is inherent — the UiPath KB attributes it to host resources, Robot/Orchestrator configuration, and infrastructure latency, and it is reported across current Robot versions. Do NOT diagnose it as "upgrade the Robot to version X." Check the Robot version only as general hygiene, never as the cause.
 
 What to look for:
 - Exact `Info` / robot-log wording — `Creating user session timed out` with NO logon-failed/locked/RDP-failed code (this is what separates it from `job-faulted-logon-failure.md`).
 - Job entered **Running** and then Faulted after ~the timeout window (separates it from Pending / no-host).
-- The Robot version installed on the executing machine (`machines list` → `robotVersions[].version`).
-- Whether the host is healthy — other jobs/users create sessions on the same machine around the same time.
-
-**Discriminator vs [job-faulted-logon-failure.md](./job-faulted-logon-failure.md):** both start with `Could not start executor`. That playbook covers an active LSA **rejection** — a Windows code (`0x000005..`), `Logon failed`, `account is locked`, or `RDP connection failed`. This playbook is the **timeout** case: `Creating user session timed out` with none of those codes. If the log carries a `0x000005..` code or `Logon failed`, route to `job-faulted-logon-failure.md`, not here.
+- Host health — CPU/RAM/session pressure at the fault time, and whether interactive logon on the host is slow for humans too.
+- Whether the failure is intermittent (a retry sometimes succeeds) — consistent with a host/latency margin problem, not a hard fault.
 
 ## Investigation
 
 1. **Get the faulted job** — `uip or jobs get <job-key> --output json`. Capture `State`, `Info`, `StartTime`, `EndTime` (duration ≈ session-creation timeout), `HostMachineName`, `RuntimeType`. Confirm `Info` contains `Could not start executor. Creating user session timed out.` and carries **no** logon-failure code.
 2. **Get error logs** — `uip or jobs logs <job-key> --level Error --output json`. Confirm the robot-service entry attributes the fault to a session-creation timeout, not an LSA logon rejection.
 3. **Confirm it entered Running** — `uip or jobs history <job-key> --output json`. A Pending → Running → Faulted transition rules out the no-host / stuck-Pending playbooks (the job was dispatched and started; session creation is what timed out).
-4. **Identify the Robot version on the executing machine** — `uip or machines list --output json` (add `--all-fields` if the version is not in the default projection). Read `robotVersions[].version` for the machine/template that ran the job (correlate on `HostMachineName`).
-   - Version **< 23.10** AND host otherwise healthy → **cause 1** (known Robot defect). Stop.
-   - Version **≥ 23.10** → the version defect is ruled out; investigate host-side session latency (cause 2) or resource exhaustion (cause 3) from host logs/metrics. These are host evidence outside the `uip` surface — report what the runtime data supports and hand the host checks to the user.
-5. **(Optional) Corroborate the known issue** — `uip docsai ask "Could not start executor Creating user session timed out Robot version" --source technical_solution_articles`. Use to confirm the exact fixed Robot version and any documented workaround. An empty KB result is not disconfirming — the version evidence in step 4 is load-bearing.
+4. **Assess host health and logon latency** — the root sub-cause lives on the host, outside the `uip` surface. Establish from the host/customer: CPU/RAM/session saturation around the fault time, whether interactive logon for a human on that host is abnormally slow (heavy profile / GPO / logon scripts / AV), and any network / DC / profile-share latency. Correlate `HostMachineName` with `uip or machines list --output json` only to identify the host and confirm the Robot is on a supported version (hygiene) — the version is **not** the cause.
+5. **(Optional) Corroborate the remediation** — `uip docsai ask "Could not start executor Creating user session timed out UIPATH_SESSION_TIMEOUT" --source technical_solution_articles`. Confirms the documented `UIPATH_SESSION_TIMEOUT` workaround and the host-side causes. An empty KB result is not disconfirming.
 
 ## Resolution
 
-Map the branch from Investigation to the fix:
+Two parts: give session creation enough time, and remove the host-side latency that pushed it past the limit.
+
+- **Raise the session-creation timeout — set the `UIPATH_SESSION_TIMEOUT` environment variable** on the Robot host to a higher value in seconds (the documented workaround; e.g. `300`–`500`), so a legitimately slow session creation completes instead of being cut off. This is the direct remediation for the timeout itself.
+- **Reduce interactive-logon latency on the host** — trim the roaming/mandatory profile, make GPO/logon-script processing lighter or asynchronous, and exclude the Robot working directories from synchronous AV scanning.
+- **Relieve host resource pressure** — reduce concurrent slots, add CPU/RAM/capacity, or move the workload so the session can be created within the window; use the `Kill Processes` activity to close leftover apps that accumulate and saturate the host.
+- **Address infrastructure latency** — check domain-controller reachability, profile-share performance, and network health between the Robot and the resources session creation needs.
+- **Interim:** a re-run sometimes succeeds when the host is momentarily less loaded — a stopgap only; raising `UIPATH_SESSION_TIMEOUT` and relieving the host is the durable fix.
+- Do **not** treat this as a Robot-version defect — upgrading the Robot is not the documented fix and will not resolve a host-latency / resource cause.
 
-- **Cause 1 — Robot version < 23.10:**
-  - Upgrade the Robot on the executing machine(s) to **23.10 or later** (the release that fixes the session-creation-timeout defect). Verify the exact fixed version via the KB (Investigation step 5) before committing the target version.
-  - Interim mitigation: **re-run the job** — the timeout is intermittent on the affected versions, so a retry often succeeds while the upgrade is scheduled.
-  - Prevention: keep unattended Robots on a supported/patched version; standardize the Robot version across the machine template so one stale host cannot reintroduce the defect.
-- **Cause 2 — Slow interactive logon:** reduce logon latency on the host — trim the roaming/mandatory profile, make GPO/logon-script processing lighter or asynchronous, exclude the Robot working directories from synchronous AV scanning. Where supported, raise the session-creation timeout to cover a legitimately slow logon.
-- **Cause 3 — Host resource exhaustion:** relieve CPU/RAM/session pressure on the target machine (reduce concurrent slots, add capacity, or move the workload) so the session can be created within the timeout.
+Source: UiPath KB — "How To Troubleshoot The Error 'Could Not Start Executor. Creating User Session Timed Out'" (host resources / Robot-Orchestrator configuration / infrastructure latency; `UIPATH_SESSION_TIMEOUT` workaround, `Kill Processes`, RDS session-limit GPO).

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/job-output-too-large.md

@@ -0,0 +1,47 @@
+---
+confidence: medium
+---
+
+# Could Not Retrieve Result — Output Too Large / Malformed Output Arguments
+
+## Context
+
+A job runs to the end of its workflow but faults at the very last step because the executor cannot return its result to Orchestrator: the `OutputArguments` payload is too large (or non-serializable) for the result message channel. The work often completed — only the hand-back failed.
+
+What this looks like:
+- `Could not retrieve the result of the job execution. This might be because a message was too large to process.`
+- Job state Faulted, but `jobs traces` shows every activity Succeeded and the workflow reached its end
+- `OutputArguments` on `jobs get` is empty, truncated, or malformed
+- More likely on processes that return bulk data (DataTables, byte arrays, large strings/JSON) as output arguments
+
+What can cause it:
+- A large `DataTable`, `List`, byte[]/file content, or big string/JSON returned as an **OutputArgument** — the result message exceeds the channel limit
+- A non-serializable or cyclic object set as an output argument
+- (Also a Robot defect on some older versions that was later fixed — version-sensitive)
+
+What to look for:
+- The process's declared output arguments (`project.json` `entryPoints[].output`, or the Main workflow's `Out_*` arguments) — is any of them a bulk type?
+- `jobs traces`: did the workflow actually finish? (If yes, the failure is result hand-back, not workflow logic.)
+- Whether the same process succeeds when its output payload is small (few rows) and fails when large
+
+## Investigation
+
+1. Get the failing job and read `Info` + `OutputArguments`:
+   `uip or jobs get <job-key> --output json` — the `Info` names the result-retrieval failure; `OutputArguments` is empty/truncated.
+2. Confirm the workflow actually completed (distinguishes hand-back failure from a mid-run fault):
+   `uip or jobs traces <job-key> --output json` — all activities Succeeded, execution reached the end.
+3. Read logs for the point of failure:
+   `uip or jobs logs <job-key> --level Error --output json` — work-complete logs followed by the result-retrieval error.
+4. Inspect the process output-argument definition in the project source: `project.json` `entryPoints[].output` (or the Main `.xaml` `Out_*` arguments). Identify the bulk output argument.
+
+## Resolution
+
+- **Move bulk data out of output arguments.** Do not return large DataTables, collections, files, or big JSON/strings as `OutputArguments`. Instead write the payload to a **Storage Bucket**, **Queue**, or **Data Fabric** entity inside the workflow and return only a small **reference** (bucket key, file path, queue reference, or record ID) as the output argument. The parent/caller reads the payload from that reference.
+- **Trim or paginate** the returned data if a reference pattern is not viable — return only the fields/rows the caller needs.
+- **Ensure output types are serializable** — replace non-serializable/cyclic objects with plain DTOs or a serialized reference.
+- **Update the Robot** to a current version if the payload is genuinely small (rules in the version-specific known-issue path), then rerun.
+- **Rerun** the job after applying the fix.
+
+Prevention:
+- Treat `OutputArguments` as a control channel, not a data channel — pass references, not payloads.
+- Cap output-argument size in design review; route bulk results through storage/queues.

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/job-stopped-generic-exit-code.md

@@ -0,0 +1,55 @@
+---
+confidence: medium
+---
+
+# Job Stopped — Unexpected Exit Code (Generic, non-0x40010004)
+
+## Context
+
+A job faults with `Job stopped with an unexpected exit code: <code>` where the code is an **OS/CLR process exit code**, not a UiPath error. These are the executor process's raw exit status — the real fault is upstream (an unhandled exception, a native crash, a session teardown). When an exception escapes to the process boundary with no top-level handler, the job `Info` and error logs can carry only this exit code while the real exception stays in the execution traces. The diagnostic job is to recover the real cause, not stop at the code.
+
+> `0x40010004` (`DBG_TERMINATE_PROCESS`) has its own playbook — the executor was killed externally. See `job-stopped-exit-code-0x40010004.md`. This playbook covers the other codes.
+
+What this looks like:
+- `System.Exception: Job stopped with an unexpected exit code: 0xE0434352`
+- `... 0xC0000005`
+- `... 0xC000026B`
+- `... 0x00000001` / `... 0xFFFFFFFF` / `... 0x00000033`
+- Job state Faulted; the workflow's own logs may stop abruptly with no handled-exception entry
+- The job `Info`/error logs may carry only the exit code when no top-level handler logged the exception before the process exited
+
+Code → meaning (map the code first):
+- **`0xE0434352`** — CLR unhandled exception (`.NET` managed exception escaped to the process boundary). The real fault is an unhandled exception inside the workflow. **Most common.**
+- **`0xC0000005`** — `STATUS_ACCESS_VIOLATION`; a native component crashed (Excel/Office COM interop, a native UIAutomation/driver, an unmanaged library). Not a managed exception.
+- **`0xC000026B`** — `STATUS_DLL_INIT_FAILED_LOGOFF`; the process was terminated during Windows logoff/shutdown — the session ended under the job (cross-reference session-teardown / RDP-drop).
+- **`0x00000001` / `0xFFFFFFFF` / `0x00000033`** — generic non-zero process exit; the executor died without a clean UiPath fault. Carries little signal by itself — recover the real error from traces/logs.
+
+What can cause it:
+- An unhandled exception in the workflow (no Try/Catch at the top level) — surfaces as `0xE0434352`
+- A native crash in a COM/UIAutomation/driver component — `0xC0000005`
+- The Windows session ending mid-run (logoff, shutdown, RDP drop) — `0xC000026B`
+- Any of the above escaping to the process boundary with no top-level handler, so only the exit code is logged and the exception detail is left in traces
+
+## Investigation
+
+1. Get the failing job and read the exact code from `Info`:
+   `uip or jobs get <job-key> --output json` — extract the `0x...` code and map it above. Note `RuntimeType`, `HostMachineName`, `StartTime`/`EndTime`.
+2. Recover the **real** error — do not stop at the code. Pull job traces (the executor records the underlying activity/exception even when the job surfaces only the OS code):
+   `uip or jobs traces <job-key> --output json` — look for the last executed activity and any exception detail (e.g. `NullReferenceException`, `KeyNotFoundException`, a COM `HRESULT`). Redirect to a file and read back only the error/activity entries.
+3. Read error logs for a managed stack trace that preceded the exit:
+   `uip or jobs logs <job-key> --level Error --output json`.
+4. Confirm the host Robot is on a supported/current version to rule out a known robot-build defect (general hygiene):
+   correlate `HostMachineName` with `uip or machines list --output json`. The exit code is produced by the unhandled exception itself, not the robot version — do not expect a version bump to reveal the exception; recover it from traces (step 2).
+5. For `0xC000026B`: check `uip or jobs history <job-key>` and the host for a logoff/shutdown at the failure timestamp (session teardown, not a workflow bug).
+
+## Resolution
+
+- **`0xE0434352` (unhandled .NET exception) — primary path:** the code is a symptom; fix the underlying unhandled exception surfaced in step 2/3. Add top-level exception handling (Global Exception Handler or a top-level Try/Catch) so the real error is logged instead of collapsing to an OS code.
+- **`0xC0000005` (access violation):** a native component crashed — identify it from the last activity in traces (commonly Excel/Office COM interop or a UIAutomation driver). Update the offending activity package / Office / driver, ensure the interop dependency is installed on the host, and prefer non-COM alternatives where available.
+- **`0xC000026B` (terminated during logoff):** the session ended under the job — keep the unattended session stable (do not log off the target user while jobs are scheduled; use Login to Console / a dedicated unattended user). Rerun. If it recurs, treat as a session-stability problem, not a workflow bug.
+- **`0x00000001` / `0xFFFFFFFF` / `0x00000033` (generic non-zero exit):** these carry little signal alone. Recover the real error from traces/logs (step 2/3); if none is captured, **add a Global Exception Handler / top-level Try-Catch** so the next run logs the exception type and stack instead of collapsing to the raw code, then rerun and diagnose the exception it reports.
+
+Prevention:
+- Ship a Global Exception Handler so unhandled exceptions are logged with a stack trace instead of collapsing to an OS code.
+- Keep robots on a current, supported version as general fleet hygiene.
+- Keep host prerequisites (Office/COM, drivers) patched to avoid native crashes.

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/known-issue-robot-defect.md

@@ -0,0 +1,40 @@
+---
+confidence: medium
+---
+
+# Known-Issue Robot Defect — Match Before Root-Causing
+
+## Context
+
+Some `Could not start executor` faults are **documented known Robot defects** already fixed in a specific Robot version — not a configuration problem to root-cause. When a fault's signature matches a known issue, the fastest resolution is: correlate with the customer-portal known-issues feed, check the host's Robot version, and upgrade to the fix version. Do not burn an investigation on a bug that is already fixed.
+
+What this looks like — signatures commonly tied to known Robot defects:
+- `Could not start executor. Could not find a part of the path 'C:\Windows\TEMP\UiPath\CredProvider'.` — known defect on builds up to **23.4.9 / 23.10.8 / 24.10.4**, fixed in **23.4.11 / 23.10.10 / 24.10.7** (UiPath KB 799589). Cause: the Robot stores Credential Provider logs under `C:\Windows\TEMP\UiPath\CredProvider`, a TEMP location that can be cleaned up mid-run; the fix relocates these logs to `%programdata%`.
+- `Could not start executor. ERROR_INVALID_PARAMETER=0x00000057 : The parameter is incorrect.` — known issue, robot-version-sensitive
+- `Rdp connection failed ... Last error: 131085` / `... 65548` — RDP-transport codes that, when they recur, are often known Robot/RDP-stack defects (distinct from the credential-side RDP handling in `job-faulted-logon-failure.md`)
+- Faults that appear only below a certain Robot version and vanish after upgrade
+
+What can cause it:
+- A defect in the Robot/executor build on the host, corrected in a later release
+- Host running an outdated Robot version that predates the fix
+
+## Investigation
+
+1. Get the failing job and capture the exact `Info` signature + code:
+   `uip or jobs get <job-key> --output json`.
+2. Identify the Robot version on the host:
+   `uip or machines list --output json` — read the template/host Robot version. Correlate with `HostMachineName` from the job.
+3. **Correlate with known issues** — check the customer-portal known-issues feed (https://customerportal.uipath.com/known-issues/) for a matching signature and its fix version. If the running version predates the fix version, this is the known defect.
+4. Rule out a live config cause: if the signature is NOT in the known-issues feed and the Robot is already current, treat it as a real fault and fall back to the matching `Could not start executor` playbook (logon / session / credential-store) instead.
+
+## Resolution
+
+- **Signature matches a known issue AND the host Robot predates the fix version:** upgrade the Robot on the affected host(s) to the fix version (e.g. ≥ 23.10.10 for the `CredProvider` path defect on the 23.10 line), then rerun. No further root-causing needed — the defect is in the Robot build.
+- **CredProvider path (`C:\Windows\TEMP\UiPath\CredProvider`):** fixed in 23.4.11 / 23.10.10 / 24.10.7 (UiPath KB 799589) — upgrade the Robot to the fix version on the host's release line.
+- **`ERROR_INVALID_PARAMETER` / `0x00000057`:** if it matches a known issue for the running version, upgrade; otherwise rerun once (some occurrences are transient) and escalate with the job evidence if it persists.
+- **RDP `131085` / `65548`:** if recurring and matching a known RDP-stack issue for the version, upgrade the Robot; also verify RDP session stability on the host (see `job-faulted-session-console-contention.md`).
+- **No matching known issue / already on the fix version:** do NOT treat as a known defect — fall back to the specific `Could not start executor` playbook (logon, session/console, or credential-store) for a real root cause.
+
+Prevention:
+- Keep robots on a current, patched version — most executor-start defects are fixed in later releases.
+- Before deep-diagnosing a `Could not start executor` fault, spend 2 minutes matching it against the known-issues feed + the host Robot version; a known-and-fixed defect is a version bump, not an investigation.

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/platform-incident-correlation.md

@@ -0,0 +1,45 @@
+---
+confidence: medium
+---
+
+# Platform Incident Correlation — Many Jobs Fault at Once
+
+## Context
+
+Applies to **any** job type (RPA, Agent, Maestro, AgentHub, API Workflow). When a burst of failures hits **multiple unrelated processes across multiple folders in a tight time window** — especially with infrastructure-flavored errors and often self-recovering — the cause is usually a **UiPath platform incident**, not a bug in any one automation. Chasing a single job's root cause here wastes the investigation.
+
+What this looks like (the fan-out fingerprint):
+- Many DISTINCT processes / DIFFERENT folders fault inside a short window (minutes), not one process failing repeatedly
+- Infrastructure-flavored errors, e.g.:
+  - `503 Service Unavailable` / `The remote server returned an error: (503)`
+  - `Could not obtain the user token from Orchestrator`
+  - `connection reset` / gateway / timeout talking to Orchestrator or a shared service
+- Failures start and stop together; jobs succeed again after the window
+- No common automation dependency links the affected processes
+
+What can cause it:
+- A UiPath cloud/Orchestrator platform incident (identity, gateway, storage, or regional outage)
+- A tenant-wide dependency blip (Identity Server, LLM Gateway, Integration Service)
+
+Do NOT mistake this for: a single automation's logic bug, one robot's credential problem, or one machine's session issue — those are scoped to one process/robot/folder, not fanned out across many.
+
+## Investigation
+
+1. Establish the fan-out — list faulted jobs across folders in the reported window:
+   `uip or jobs list --state Faulted --output json` (cross-folder; add `--created-after/--created-before` to bound the window). Count DISTINCT `ProcessName` / `FolderName`. Many unrelated automations in a tight window ⇒ suspect platform.
+2. Confirm the error shape on a sample:
+   `uip or jobs get <job-key> --output json` on two or three of the affected jobs — infrastructure errors (503 / token / gateway), not automation-logic exceptions, and different processes carrying the SAME class of error.
+3. Correlate with platform status:
+   - Check **status.uipath.com** for a reported incident overlapping the failure window (region/service).
+   - Check the customer-portal **known-issues** feed for a matching active issue.
+4. Rule out a shared automation dependency: if all affected processes DO share one dependency (same queue, same connection, same asset), that shared dependency — not a platform incident — may be the cause; investigate it instead.
+
+## Resolution
+
+- **If a platform incident overlaps the window:** do NOT debug the individual automations. Monitor status.uipath.com for resolution, rerun the affected jobs after the incident clears, and — if the incident is not already listed — report it via the customer portal with the correlated job evidence (timestamps, affected processes, error text). Communicate to stakeholders that this is a platform-side outage, not an automation defect.
+- **If NO incident is listed but the errors are infrastructure-type and fanned out:** escalate to UiPath Support with the correlated evidence (the cross-folder fault list + sample errors + window) rather than filing per-automation bugs.
+- **If the failures actually share one automation dependency:** drop the platform hypothesis and investigate that dependency (queue/connection/asset) with the relevant playbook.
+
+Prevention:
+- Alert on cross-folder fault bursts (N distinct processes faulting within a short window) — this is the platform-incident signal.
+- Build rerun/resume handling so jobs caught in a transient platform outage can be replayed cleanly after recovery.

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/screen-capture-handle-invalid.md

@@ -0,0 +1,43 @@
+---
+confidence: medium
+---
+
+# Screen Capture Failed — Win32 "The handle is invalid" (no interactive desktop)
+
+## Context
+
+A screen-surface activity (Take Screenshot, image-based / Computer Vision capture, `CopyFromScreen`) throws a Win32 exception because there is **no valid interactive desktop to capture** — the unattended session has no live console/RDP surface, or the session was disconnected/locked while the job ran. GDI screen capture needs a real, active desktop; without one, the handle is invalid.
+
+What this looks like:
+- `System.ComponentModel.Win32Exception (6): The handle is invalid. at System.Drawing.Graphics.CopyFromScreen(...)`
+- Faults at a screenshot / image-capture / screen-scrape step, not at job start
+- Happens on unattended runs, disconnected RDP sessions, or locked/minimized sessions — and typically NOT when a human is watching the session live
+- Intermittent: works when the session is active/connected, fails when it is not
+
+What can cause it:
+- **Unattended robot attached to the physical console (`LoginToConsole` = Yes) with no interactive console logon** — the machine's single physical console session has no rendered desktop to capture. (Login to Console = **No** is the recommended unattended config: the robot opens its own RDP session with a live desktop.)
+- **RDP session disconnected / logged off** mid-run — the desktop surface went away under the job
+- **Session locked / screensaver / minimized** — the desktop is not renderable for capture
+- Occasionally a Robot/driver defect (see `known-issue-robot-defect.md` — check version)
+
+## Investigation
+
+1. Get the failing job and read the exception:
+   `uip or jobs get <job-key> --output json` — `Info` shows the `Win32Exception (6): The handle is invalid` at `CopyFromScreen`.
+2. Find the failing activity in traces:
+   `uip or jobs traces <job-key> --output json` — the screenshot / image-capture activity Faulted; prior non-screen activities succeeded.
+3. Check the robot user's session configuration:
+   `uip or users get <user-key> --output json` — `LoginToConsole` (**true** ⇒ the robot attaches to the machine's single physical console session; with no interactive logon there, it has no rendered desktop. **false** ⇒ the robot opens its own RDP session with a desktop — the recommended unattended setting) and whether this is an unattended user expected to have its own session.
+4. Check session stability around the failure: whether an RDP session was disconnected/logged off or the host locked at the failure timestamp (job history + host events).
+
+## Resolution
+
+- **Unattended run with no session surface (`LoginToConsole` = Yes on a host with no interactive console logon):** set **Login to Console = No** for the unattended user (Orchestrator → Tenant → Users/Robots → Execution Settings) so the Robot opens its own RDP session with a real desktop, then rerun. Login to Console = Yes attaches to the machine's single physical console, which has no rendered desktop unattended and is not recommended.
+- **RDP session disconnected/logged off:** keep the session alive — do not log off or "X" out of the RDP window (use Disconnect deliberately, or run via Login to Console). Ensure the session stays connected for the duration of screen-surface work.
+- **Session locked / minimized:** prevent lock/screensaver on the robot host during unattended runs; ensure the target window is activated (`Activate`) before capture.
+- **Design alternative:** avoid raw full-screen `CopyFromScreen` in headless contexts — prefer element-scoped capture, or capture a specific window/UI element rather than the whole desktop.
+- **If it persists on a current session with a live desktop:** check the Robot version against known issues (`known-issue-robot-defect.md`) — a driver/build defect can also surface as an invalid handle.
+
+Prevention:
+- For any unattended automation that takes screenshots or uses image-based/CV activities, guarantee a live interactive session — set Login to Console = No so the robot maintains its own RDP session with a desktop; do not rely on the physical console for unattended capture.
+- Keep RDP sessions connected and unlocked for the duration of screen-surface steps.

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/serverless-license-quota.md

@@ -0,0 +1,43 @@
+---
+confidence: medium
+---
+
+# Serverless Automation Cannot Be Started — License / Quota Exceeded
+
+## Context
+
+A **serverless** (cloud robot, `RuntimeType` Serverless / `runtimetype = 9`) job fails to start with one of:
+
+```
+Automation cannot be started. Your user's monthly Personal Automation quota has been exceeded.
+Automation cannot be started. Your user's assigned Robot Units have been exceeded.
+Automation cannot be started. Your tenant's assigned Robot Units have been exceeded. Allocate more Robot Units to your tenant to continue.
+```
+
+What this looks like:
+- The automation never starts — it is rejected at allocation time, not faulted mid-run. There is **no Windows session, executor, logon, or workflow** involved.
+- The message names a **quota / Robot Units** limit at **user** or **tenant** scope.
+
+> A serverless job that **started and ran ~15 minutes before stopping** is a different case — the serverless execution time limit, not an allocation/quota block: see [serverless-time-limit-exceeded.md](./serverless-time-limit-exceeded.md).
+
+What causes it (this is a licensing/allocation state, NOT a code/config/robot bug):
+- **Personal Automation monthly quota exceeded** — the user's free monthly Personal Automation run allowance is used up for the period.
+- **User's Robot Units exceeded** — the serverless capacity **assigned to that user** is exhausted by concurrent/accumulated runs.
+- **Tenant's Robot Units exceeded** — the **tenant-level** serverless Robot Unit pool is exhausted; every user in the tenant is affected until more units are allocated.
+
+What to look for:
+- **`RuntimeType` = Serverless / `runtimetype = 9`** on the job — confirms this is the serverless surface, not unattended.
+- The **scope word** in the message — `user's ... Personal Automation quota` vs `user's ... Robot Units` vs `tenant's ... Robot Units` selects the branch and where the fix is applied.
+
+## Investigation
+
+1. **Get the job:** `uip or jobs get <job-key> --output json` → confirm the quota/Robot-Units message and `RuntimeType` Serverless / `runtimetype = 9`.
+2. **Read the scope from the message** — user Personal Automation quota, user Robot Units, or tenant Robot Units.
+3. **Check current licensing/allocation state** — tenant Robot Unit allocation and the user's assignment (Automation Cloud → Admin → Licenses / tenant licensing; the specific figures may not be exposed via `uip`). Rule out that this is an infrastructure fault — the message is explicit about quota.
+
+## Resolution
+
+- **Tenant Robot Units exceeded:** allocate more Robot Units to the tenant (Automation Cloud → Admin → tenant → Licenses), or reduce concurrent serverless usage until the pool frees up.
+- **User Robot Units exceeded:** raise the user's assigned Robot Units, or spread the workload / reduce concurrency for that user.
+- **Personal Automation monthly quota exceeded:** wait for the monthly quota to reset, move the workload to a licensed serverless/unattended allocation, or upgrade the plan — Personal Automation is a capped free tier, not a production allocation.
+- This is **not** fixed by rerunning, updating the robot, or fixing credentials — it is a licensing/allocation limit. Rerunning before units free up (or the quota resets) just re-hits the limit.

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/serverless-time-limit-exceeded.md

@@ -0,0 +1,34 @@
+---
+confidence: medium
+---
+
+# Serverless Run Cancelled — 15-Minute Execution Time Limit
+
+## Context
+
+A **serverless** (Automation Cloud Robot – Serverless, `RuntimeType` Serverless / `runtimetype = 9`) job **starts, runs, and is then terminated mid-execution** on reaching the serverless per-job time limit. Per UiPath docs, **each serverless job is limited to 15 minutes; jobs that take longer are terminated when they reach 15 minutes of execution time.** This is an **execution ceiling**, not a start-time block.
+
+> **Distinct from [serverless-license-quota.md](./serverless-license-quota.md).** That playbook is for a serverless job that **never starts** (rejected at allocation time with a Robot-Units / Personal-Automation-quota message, near-zero runtime). This one is for a job that **ran ~15 minutes and was cut off** at the ceiling. Run duration is the discriminator.
+
+What this looks like:
+- `RuntimeType` Serverless / `runtimetype = 9`, and the job reached **Running** (it was not rejected at start).
+- Run duration ≈ **15 minutes** (`EndTime − StartTime`), then the job stops (Faulted / Stopped / Cancelled).
+- The status/`Info` indicates the run was cancelled on reaching the time limit (wording such as "reached the time limit" / "cancelled" — the exact user-facing string is not documented and may vary by surface, so key off the ~15-minute duration, not a verbatim message).
+- No quota / Robot-Units message, no `Could not start executor`, and no in-workflow exception that explains the stop on its own.
+
+What causes it:
+- The workflow legitimately needs **more than 15 minutes** on a serverless robot — long loops, large data volumes, slow external systems, or waits — and hits the hard serverless ceiling.
+
+## Investigation
+
+1. **Get the job:** `uip or jobs get <job-key> --output json` → confirm `RuntimeType` Serverless / `runtimetype = 9`, that the job reached **Running**, and compute `EndTime − StartTime` ≈ 15 min.
+2. **Rule out the license/quota case:** confirm there is **no** `Automation cannot be started … Robot Units` / `Personal Automation quota` message and that runtime is ~15 min (not near-zero). A job that never ran → [serverless-license-quota.md](./serverless-license-quota.md) instead.
+3. **Rule out an in-workflow fault:** `uip or jobs logs <job-key> --level Error --output json` — if the stop is explained by a workflow exception rather than the time ceiling, diagnose that exception instead.
+
+## Resolution
+
+- **Bring the run under 15 minutes** — optimize the workflow (batch or cap the data processed per run, remove avoidable waits, parallelize independent work), or **split it into multiple shorter jobs** chained via a trigger/orchestration so each run stays under the serverless ceiling.
+- **Move long-running workloads off serverless** — run them on an **unattended (VM / machine-template) robot**, which is not subject to the 15-minute serverless per-job limit.
+- Rerunning as-is does **not** help — a workflow that needs more than 15 minutes hits the ceiling every time until it is shortened or moved.
+
+Source: UiPath docs — *Executing unattended automations with Serverless robots* ("Each job is limited to 15 minutes. Jobs that take longer are terminated when they reach 15 minutes of execution time.").

package/skills/uipath-troubleshoot/references/products/orchestrator/playbooks/workstation-in-use-machine-slots.md

@@ -0,0 +1,40 @@
+---
+confidence: medium
+---
+
+# Could Not Start Executor — Workstation In Use (machine slots over-provisioned)
+
+## Context
+
+An unattended job faults at start with:
+
+```
+Could not start executor. The workstation is in use by another user. Please retry after the user logs off or disconnects.
+```
+
+What this looks like:
+- Job state: Faulted, near-zero runtime; the executor never started.
+- One job on the machine may succeed while a **concurrent** one fails — the failure correlates with **how many jobs run on the same physical host at once**, not with the user's credential.
+
+What causes it:
+- The **machine template allocates more runtime slots than the workstation's OS actually supports as concurrent interactive/RDP sessions.** A Windows **client** OS (Win 10/11) and a non-RDSH Windows Server allow only **one** interactive session. If the template grants 2+ unattended slots on such a host, Orchestrator dispatches a second concurrent job, Windows has no second session to give it, and the executor start is refused with "workstation is in use by another user."
+- This is a **template/host capacity mismatch**, not a credential/logon problem (no `Logon failed` / `0x000005..` code) and not a human holding an RDP slot (that is the RDP-slot branch of [job-faulted-logon-failure.md](./job-faulted-logon-failure.md)).
+
+What to look for:
+- The **slot counts** on the machine template vs the host OS's real concurrent-session capacity.
+- Whether failures coincide with **overlapping** job schedules on the same machine.
+- Absence of any Windows logon-failure code in the message (rules out logon-failure).
+
+## Investigation
+
+1. **Get the faulted job:** `uip or jobs get <job-key> --output json` → confirm the `The workstation is in use by another user` message, `HostMachineName`, and near-zero runtime.
+2. **Read the machine template slots:** `uip or machines list --all-fields --output json` → for the host that ran the job, read `unattendedSlots` / `headlessSlots` / other slot counts. A count **> 1** on a single-session OS is the fingerprint.
+3. **Correlate concurrency:** `uip or jobs list --folder-key <key> --output json` → check whether another job was Running on the same `HostMachineName` in the same window (the "other user" holding the session).
+4. **Confirm the host OS class** (ask the user / check the machine description): Windows client or non-RDSH Server → only one interactive session exists.
+
+## Resolution
+
+- **Reduce the template's slot count to the host's real capacity** — for a Windows client / single-session Server, set unattended slots to **1** so Orchestrator never dispatches overlapping jobs to a host that cannot seat them.
+- **Or add real session capacity:** move the workload to a **multi-session** host — Windows Server with the Remote Desktop Session Host role and enough RDS CALs, or a High-Density-capable configuration — then size slots to the licensed concurrent-session count.
+- **Or serialize** the schedules so two jobs never target the same single-session host at once.
+- Do not "fix" this by rerunning blindly or updating credentials — the credential is fine; the host cannot seat the concurrent session the template promised.

package/skills/uipath-troubleshoot/references/products/orchestrator/summary.md

@@ -6,10 +6,22 @@
 |-------|:---:|-------------|----------|
 | Robot Credentials / Machine Mismatch | High | "Wrong machine credentials", PendingReason `RobotNoMatchingUsernames`, or `TemplateNoLicense` — robot/machine configuration cannot execute unattended jobs | [robot-credentials.md](./playbooks/robot-credentials.md) |
 | Could Not Start Executor — Logon Failed | Medium | Unattended job faults immediately with `Could not start executor` / `Logon failed for user` / `RDP connection failed` (codes `0x0000052E`, `0x00000775`, `0x00000532`, `131092`). Covers session-config mismatch, AD lockout, password mismatch, lockout loop, MFA/Conditional Access, and RDP slot conflict | [job-faulted-logon-failure.md](./playbooks/job-faulted-logon-failure.md) |
-| Could Not Start Executor — Creating User Session Timed Out | Medium | Unattended job enters Running then faults after ~the session-creation timeout with `Could not start executor. Creating user session timed out.` and NO logon-failure/locked/RDP code. Primary cause: known Robot defect on versions < 23.10 (fix: upgrade to ≥ 23.10). Also slow interactive logon or host resource exhaustion | [job-faulted-session-timeout.md](./playbooks/job-faulted-session-timeout.md) |
+| Could Not Start Executor — Creating User Session Timed Out | Medium | Unattended job enters Running then faults after ~the session-creation timeout with `Could not start executor. Creating user session timed out.` and NO logon-failure/locked/RDP code. Session creation exceeded the window — causes: slow interactive logon, host resource exhaustion, or infra/network latency. Fix: raise `UIPATH_SESSION_TIMEOUT` + relieve host latency. NOT a Robot-version defect | [job-faulted-session-timeout.md](./playbooks/job-faulted-session-timeout.md) |
 | Queue Items Failing | Medium | Queue items transitioning to Failed status with various error types | [queue-items-failing.md](./playbooks/queue-items-failing.md) |
 | Job Stuck in Running | Low | Job remains in Running state indefinitely with no progress | [job-stuck.md](./playbooks/job-stuck.md) |
 | Job Pending — No Available Host | High | Job stuck in Pending with "No host is available on the machine template" error AND template has zero connected runtimes | [job-pending-no-host.md](./playbooks/job-pending-no-host.md) |
 | Job Pending — Stale Dispatch-Time PendingReasons | High | Job stuck in Pending with no-host-family `PendingReasons.Errors` BUT a runtime IS connected, credentials/mode/license are valid, and `JobHistory` has only the original entry — Orchestrator never re-evaluated. Fix: stop + re-trigger | [job-pending-stale-dispatch.md](./playbooks/job-pending-stale-dispatch.md) |
 | Foreground Process Already Running | Medium | `InvalidOperationException: A foreground process is already running. Only one foreground process can run at a time.` — Robot rejects concurrent foreground jobs on the same session | [foreground-already-running.md](./playbooks/foreground-already-running.md) |
 | Job Stopped — Exit Code 0x40010004 | Medium | `System.Exception: Job stopped with an unexpected exit code: 0x40010004` — executor was killed via `TerminateProcess` (operator Kill, service restart, session logoff, OOM, native crash, or platform recycle) | [job-stopped-exit-code-0x40010004.md](./playbooks/job-stopped-exit-code-0x40010004.md) |
+| Screen Capture Failed — Win32 "The handle is invalid" | Medium | `System.ComponentModel.Win32Exception (6): The handle is invalid. at System.Drawing.Graphics.CopyFromScreen(...)` — a screenshot / image-capture activity has no live interactive desktop to capture (unattended with no session surface, disconnected RDP, or locked session). Fix: set Login to Console = No so the robot uses its own RDP session, keep RDP connected/unlocked | [screen-capture-handle-invalid.md](./playbooks/screen-capture-handle-invalid.md) |
+| Known-Issue Robot Defect — Match Before Root-Causing | Medium | `Could not start executor` faults that are documented, already-fixed Robot defects: `CredProvider` path (fixed 23.4.11 / 23.10.10 / 24.10.7, UiPath KB 799589), `ERROR_INVALID_PARAMETER` / `0x00000057`, recurring RDP `131085`/`65548`. Correlate with the customer-portal known-issues feed + host Robot version and upgrade to the fix version rather than root-causing a fixed bug | [known-issue-robot-defect.md](./playbooks/known-issue-robot-defect.md) |
+| Credential Store Unavailable | Medium | `Unable to retrieve credentials from Orchestrator Database credential store …` (or an external CyberArk / Azure Key Vault / HashiCorp error) — the credential STORE backend is unreachable/misconfigured, so no logon is even attempted (distinct from a wrong password). Branches: Orchestrator DB down, external vault unreachable, secret missing/access-denied, store misconfig | [credential-store-unavailable.md](./playbooks/credential-store-unavailable.md) |
+| Platform Incident Correlation — Many Jobs Fault at Once | Medium | Any job type. A burst of failures across MULTIPLE unrelated processes/folders in a tight window with infrastructure errors (503, `Could not obtain the user token`, gateway/connection reset), often self-recovering — the fingerprint of a UiPath platform incident, not one automation's bug. Correlate the cross-folder fault list with status.uipath.com / known-issues; monitor + rerun + report rather than debug individual jobs | [platform-incident-correlation.md](./playbooks/platform-incident-correlation.md) |
+| Maximum Consecutive System Exceptions Reached | Medium | `The maximum number of consecutive system exceptions was reached. Consecutive retry number: <N>` — symptom, not cause: a System Exception recurs on every transaction (broken selector, app/dependency down) until the REFramework threshold trips. Find the recurring underlying exception in logs/traces and fix THAT; raising the threshold only delays the abort | [job-consecutive-system-exceptions.md](./playbooks/job-consecutive-system-exceptions.md) |
+| Could Not Retrieve Result — Output Too Large | Medium | `Could not retrieve the result of the job execution. This might be because a message was too large to process.` — workflow completed but the executor could not hand back its result: an `OutputArguments` payload (DataTable / collection / file / big string) exceeds the result-message limit or is non-serializable. Fix: return a reference (storage bucket / queue / Data Fabric), not the payload | [job-output-too-large.md](./playbooks/job-output-too-large.md) |
+| Job Stopped — Unexpected Exit Code (generic) | Medium | `Job stopped with an unexpected exit code: <code>` for OS/CLR codes other than 0x40010004 — `0xE0434352` (unhandled .NET exception), `0xC0000005` (native access violation), `0xC000026B` (terminated during logoff), `0x00000001`/`0xFFFFFFFF`/`0x00000033` (generic non-zero exit). Recover the real fault from traces/logs; add a Global Exception Handler so it is logged instead of collapsing to the code | [job-stopped-generic-exit-code.md](./playbooks/job-stopped-generic-exit-code.md) |
+| Could Not Start Executor — Workstation In Use | Medium | `Could not start executor. The workstation is in use by another user...` — the machine template allocates **more slots than the host OS supports concurrent sessions** (Windows client / non-RDSH Server = 1). A second concurrent job has no session to seat. Fix: reduce slots to the host's real capacity, or move to a multi-session host. NOT a logon/credential fault. | [workstation-in-use-machine-slots.md](./playbooks/workstation-in-use-machine-slots.md) |
+| Could Not Start Executor — Console Conflict (HD) | Medium | `Another interactive job is using the machine's console. Only one interactive job can use the console at a time.` — HD robots with **Login to Console = True** all attach to the single physical console; only one runs at a time. Fix: disable Login to Console for the HD robot so each job gets its own session. | [console-conflict-login-to-console.md](./playbooks/console-conflict-login-to-console.md) |
+| Serverless — License / Quota Exceeded | Medium | Serverless (`RuntimeType` Serverless / `runtimetype = 9`) job rejected at start: `Automation cannot be started. Your user's monthly Personal Automation quota...` / `user's ... Robot Units have been exceeded` / `tenant's assigned Robot Units have been exceeded`. A licensing/allocation limit, not a code/robot bug. Fix: allocate Robot Units (user/tenant) or wait for the Personal Automation quota to reset. | [serverless-license-quota.md](./playbooks/serverless-license-quota.md) |
+| Serverless — Run Cancelled at 15-Minute Time Limit | Medium | Serverless (`RuntimeType` Serverless) job that **reached Running and ran ~15 min, then was terminated** — each serverless job is capped at 15 minutes of execution. An execution ceiling, distinct from the license/quota block (which never starts). Fix: optimize/split the workflow under 15 min, or move long runs to an unattended (VM) robot. | [serverless-time-limit-exceeded.md](./playbooks/serverless-time-limit-exceeded.md) |
+| Executor Start / Session — Transient (rerun-class) | Medium | Transient session/service blips at executor start or mid-run: `Job faulted due to service shutdown or disconnect`, `Rdp connection failed ... 131085` / `... 65548`, `A specified logon session does not exist (0x80070520)`, `User is running another job. Waiting ... timed out`, `... cleanup action for jobs in Terminating state`. Shared fix: **rerun** (± Robot update if recurring). Confirm no persistent logon/slot/console/quota marker first. | [executor-start-transient-rerun.md](./playbooks/executor-start-transient-rerun.md) |

package/version-manifest.json

@@ -1,5 +1,5 @@
 {
   "schemaVersion": 2,
-  "skillsVersion": "1.199.0",
-  "targetCli": "^1.199.0"
+  "skillsVersion": "1.200.0",
+  "targetCli": "^1.200.0"
 }