[Marc-André Moreau (mamoreau-devolutions)]

Problem

ClientConnector.WithStaticChannelRdpdr in the .NET FFI announces a smartcard device backed by NoopRdpdrBackend. That backend's handle_scard_call returned no messages, so the client never completed any MS-RDPESC IOCTL the server sent (EstablishContext, ListReaders, GetStatusChange, ...). Server-side WinSCard calls in the session hung, which can stall logon and UAC prompts that check for readers. ironrdp-client attaches the same backend when RDPDR is enabled with no native backend.

Fix

The noop backend answers every smartcard call. It replies with the return structure the server expects for that IOCTL, with ReturnCode = SCARD_E_NO_SERVICE and IoStatus = STATUS_SUCCESS, as MS-RDPESC 3.1.4 requires for smart card errors. Shared helpers in ironrdp-rdpdr build these replies, and the Windows backend now uses them too:

• ScardCall::error_response builds the completion for a failed call. An IOCTL with no known return structure gets STATUS_UNSUCCESSFUL and no output, as in FreeRDP; this path is unreachable today.
• esc::complete_call replies STATUS_BUFFER_TOO_SMALL when the structure does not fit the server's output buffer, so the server retries with a larger one (3.2.5.2).
• Error returns zero every field besides ReturnCode (2.2.3): empty context and handle (ScardContext::empty, ScardHandle::empty), NULL buffers, and no reader states (kept on SCARD_E_TIMEOUT, as FreeRDP does). This also fixes failure replies in the Windows backend (Connect, Transmit, Reconnect, GetTransmitCount, GetDeviceTypeId).

Real WinSCard redirection in the FFI on Windows. WithStaticChannelRdpdr now backs the smartcard with the WinSCard passthrough from ironrdp-rdpdr-native, the same backend the viewer and ActiveX use. Other platforms keep the noop backend.

The native backend runs blocking calls (GetStatusChange, Connect, Transmit, ...) on worker threads, and their completions only reach the server through Rdpdr::poll_deferred_messages. So:

• ActiveStage.Process sends deferred RDPDR completions after each frame, as ironrdp-client does, except after DeactivateAll or Terminate.
• New ActiveStage.PollRdpdrDeferred() returns them while the server is idle. Hosts should call it about every 50 ms, serialized with their other ActiveStage calls.
• The Avalonia example polls every 50 ms from its read loop, and starts the next read only after the current frame's outputs are handled, so reactivation reads are not raced.

The existing .NET API is unchanged; PollRdpdrDeferred is an addition. The regenerated bindings only add the new method and doc comments.

Related PRs

This PR builds on #2161 and #2162, both now merged into master:

• fix(ffi): use an async lock for Framed writes #2161 makes Framed.Write safe for concurrent writers, which the example's 50 ms poll relies on.
• fix(ffi): lock ActiveStage in the Avalonia example #2162 locks every ActiveStage call in the Avalonia example. This PR only adds the RDPDR poll, the read-ordering fix and a null guard in SendFastpath on top of it.

Testing

• Testsuite tests send an EstablishContext IOCTL through Rdpdr with the noop backend, cover the STATUS_BUFFER_TOO_SMALL and no-structure paths, and check that error replies for eight call types are all zero after ReturnCode.
• cargo test passes for ironrdp-rdpdr, ironrdp-rdpdr-native and the testsuite's rdpdr tests.
• cargo xtask check fmt, cargo xtask check locks, cargo xtask ffi build and cargo xtask ffi bindings (which builds the .NET library) pass, and the Avalonia example builds.
• Clippy with -D warnings is clean on ironrdp-rdpdr, ironrdp-rdpdr-native, ironrdp-testsuite-core and ffi. The full cargo xtask check lints could not run locally because the libopus_sys CMake build fails on that machine.

Not tested: a live session with a reader and card, and building the FFI for non-Windows targets (left to CI).

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The Avalonia example introduces competing reactivation reads and unsynchronized polling of mutable native session state.

2 open issues

• Serialize polling with all other ActiveStage operations · New
• Start the next read only after handling current outputs · New

What changed in this PR

Adds Windows smartcard redirection to the .NET FFI and completes unsupported smartcard requests instead of leaving server calls waiting.

Changes:

• Uses the native WinSCard backend on Windows.
• Adds deferred-completion polling and updates the Avalonia example.
• Adds IOCTL-specific error responses and regression tests.

File	Description
ffi/​src/​session/​mod.rs	Exposes and integrates deferred-completion polling.
ffi/​src/​connector/​mod.rs	Selects the Windows native backend.
ffi/​dotnet/​Devolutions.IronRdp/​Generated/​RawClientConnector.cs	Documents smartcard behavior.
ffi/​dotnet/​Devolutions.IronRdp/​Generated/​RawActiveStage.cs	Adds native polling declaration.
ffi/​dotnet/​Devolutions.IronRdp/​Generated/​ClientConnector.cs	Documents backend selection and polling.
ffi/​dotnet/​Devolutions.IronRdp/​Generated/​ActiveStage.cs	Adds managed polling wrapper.
ffi/​dotnet/​Devolutions.IronRdp.AvaloniaExample/​MainWindow.axaml.cs	Polls completions during idle reads.
ffi/​Cargo.toml	Adds Windows backend dependency.
crates/​ironrdp-testsuite-core/​tests/​rdpdr/​mod.rs	Tests noop responses and buffer limits.
crates/​ironrdp-rdpdr/​src/​pdu/​esc/​mod.rs	Builds call-specific error returns.
crates/​ironrdp-rdpdr/​src/​backend/​noop.rs	Completes smartcard calls with no-service errors.
Cargo.lock	Records the FFI backend dependency.

_{Review effort: Balanced}

[github-actions]

The PR fixes a real hang: NoopRdpdrBackend previously returned no completion for smartcard IOCTLs, stalling server-side WinSCard. The new ScardCall::error_return plus the noop handle_scard_call completion follow MS-RDPESC 3.1.4/3.2.5.2 (ReturnCode in the IOCTL-specific return, IoStatus SUCCESS, BUFFER_TOO_SMALL retry path) and are covered by new testsuite tests. The Windows WinSCard passthrough, FFI deferred-poll API, and Avalonia lock/poll rework are coherent. Two low-severity wire deviations remain in the new error path: error returns carry nonzero cbContext/cbHandle from ScardContext::from_native(0) where MS-RDPESC 2.2.3 requires all non-ReturnCode fields to be zero, and unrecognized IOCTLs are completed with IoStatus SUCCESS plus a Long_Return body instead of an NTSTATUS error with no output. Maintainability findings are confirmed against pr-head: error_return duplicates ironrdp-rdpdr-native's private unsupported() mapping variant-for-variant, and the noop completion body re-imple…

Push a commit after addressing these findings. If no code change is needed, you may resolve inline threads and comment @github-actions review-ready to request human review.

[github-actions]

The PR correctly fixes the noop-backend smartcard hang by completing every MS-RDPESC IOCTL via ScardCall::error_response, centralizes error/buffer-too-small completion in esc::complete_call, and adds Windows WinSCard passthrough to the .NET FFI plus an additive PollRdpdrDeferred API. Protocol behavior matches MS-RDPESC 3.1.4/2.2.3/3.2.5.2. Six valid candidates remain: an open question on opt-in deferred polling (medium), an unverified STATUS_UNSUCCESSFUL fallback, a dead/discarding factory error arm, an abandoned pending ReadPdu in the example loop, and two low-severity duplication issues. All six are published; the factory-error finding is refined with a corrected line range; the rest are accepted substantially unchanged.

1. [skeptical] Hang fix relies on hosts voluntarily adopting the new PollRdpdrDeferred API — medium 🟠 ❓ — ffi/src/session/mod.rs
   Deferred RDPDR completions only reach the server via the per-frame flush in ActiveStage::process (lines 130-134) or the new opt-in poll_rdpdr_deferred (lines 137-145). A host that never polls on a timer gets completions only when the server sends traffic, but a server blocked in a WinSCard call awaiting the pending completion may send nothing, reproducing the hang. MAX_DEFERRED back-pressure (SCARD_E_NO_MEMORY) does not unblock it either. Nothing in the FFI enforces the polling contract; whether a Windows server always sends frames during an outstanding IOCTL, and whether all .NET consumers adopted the new API, could not be verified.
2. [skeptical] Unreachable factory error arm discards the underlying cause — low 🟡 — ffi/src/connector/mod.rs
   with_static_channel_rdpdr builds the backend via WindowsRdpdrBackendFactory::from_drives(Vec::new()). Per factory.rs (from_drive_configuration, lines 139-157), every error variant (DuplicateDeviceId/RepeatedInitialSelection/UnconfiguredInitialSelection) requires at least one drive, so this call cannot fail and the '?' arm is dead code today. Its map_err also replaces any future, more specific factory error with the generic 'invalid RDPDR backend configuration', misdiagnosing a real failure if validation is added. Propagate the actual error or use a non-fallible construction for the smartcard-only configuration.
3. [skeptical] Read loop can exit while readPduTask is still pending and unobserved — low 🟡 — ffi/dotnet/Devolutions.IronRdp.AvaloniaExample/MainWindow.axaml.cs
   In ReadPduAndProcessActiveStage, the deferred-poll branch assigns keepLooping from HandleActiveStageOutput(deferred); if it returns false (e.g. Terminate), the while loop exits without awaiting the pending readPduTask started earlier in the iteration. If the abandoned ReadPdu subsequently faults (connection reset, stream error), the exception is unobserved and surfaces as UnobservedTaskException rather than the loop's Trace error path, hiding the disconnect cause. Await or observe the task before returning.

Push a commit after addressing these findings. If no code change is needed, you may resolve inline threads and comment @github-actions review-ready to request human review.