OleSetClipboard fails in sandbox on Win11 22631 (RPC_S_UNKNOWN_IF), but works on Win11 26200 with same config

Describe what you noticed and did

[1.17.5] OleSetClipboard fails with RPC_S_UNKNOWN_IF (0x800706B5) in sandbox on Windows 11 Build 22631 when SandboxieLogon=y is active

Summary

OleSetClipboard (used by applications for rich-format clipboard write, e.g. Ctrl+C in Telegram Desktop) silently fails inside a sandbox on Windows 11 Build 22631. The same Sandboxie version and sandbox configuration works correctly on Windows 11 Build 26200. Win32 SetClipboardData (plain text) is unaffected.

• Machine A (Windows 11 Enterprise, Build 22631.6936) — domain-joined: OleSetClipboard → 0x800706B5 (RPC_S_UNKNOWN_IF) FAIL
• Machine B (Windows 11 Home, Build 26200) — MSA account: OleSetClipboard → S_OK OK

The issue is reproducible and stable across Sandboxie-Plus versions 1.17.5, and has also been observed on 1.16.9 / 1.17.2 / 1.17.4.

Environment

Sandbox Configuration (TG2, no workaround applied)

[GlobalSettings]
SandboxieLogon=y
# Still fails if removes SandboxieLogon=y, this is not root cause.

[TG2]
Enabled=y
BlockNetworkFiles=y
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
RecoverFolder=%Personal%
RecoverFolder=%Desktop%
BorderColor=#00fd00,ttl,6,192
Template=OpenBluetooth
Template=SkipHook
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=AutoRecoverIgnore
ConfigLevel=10
UseFileDeleteV2=y
UseRegDeleteV2=y
AutoRecover=y

Steps to Reproduce

1. Run any application that calls OleSetClipboard inside the sandbox (e.g. Telegram Desktop — press Ctrl+C on any message).
2. Paste in an unsandboxed application. Content is missing.

To reproduce programmatically: compile a small Win32 program that calls OleInitialize then OleSetClipboard(pDataObject) and observe the HRESULT.

Actual Result

OleSetClipboard  hr = 0x800706B5  (RPC_S_UNKNOWN_IF)

Under partial workaround (Template=OpenCOM + OpenIpcPath=\RPC Control\ClipServiceTransportEndpoint-* without NoSecurityIsolation=y):

OleSetClipboard  hr = 0x8007000E  (E_OUTOFMEMORY)

Expected Result

OleSetClipboard should succeed (return S_OK) in sandbox on Build 22631 with the same configuration that works on Build 26200.

Root Cause Analysis

Step 1 — Identifying kernel vs. hook layer

We probed NtAlpcConnectPort two ways:

• [hook] — via SbieDll's hooked ntdll (normal call path)
• [raw] — via a hand-assembled raw syscall stub that reads the syscall number from ntdll.dll on disk, bypassing the in-memory hook entirely

Results on both machines inside sandbox:

Both machines show identical SbieDrv kernel-level behaviour: epmapper and clipsfk are both blocked (ACCESS_DENIED) at kernel level. The hook fabricates COLLISION for epmapper and NOT_FOUND for clipsfk, then tries to proxy through SbieSvc.

Step 2 — Why Machine B succeeds despite the same kernel blocks

SbieDll's hook proxies the epmapper query through SbieSvc. SbieSvc queries the real epmapper outside the sandbox and returns the clipboard service endpoint name:

This is confirmed by \RPC Control\ enumeration outside the sandbox:

• Machine A (22631) exposes two ALPC ports:
  • clipsfk
  • ClipServiceTransportEndpoint-00001 ← clipboard service endpoint on this build
• Machine B (26200) exposes only:
  • clipsfk

Windows 11 23H2 (Build 22631) uses ClipServiceTransportEndpoint-* as the cbdhsvc ALPC endpoint name; 24H2+ reverted to (or never changed from) clipsfk. SbieDll's clipboard forwarding logic only handles clipsfk.

Step 3 — Secondary failure: Sandboxie DACL blocks cbdhsvc callback

Even when Template=OpenCOM + OpenIpcPath=\RPC Control\ClipServiceTransportEndpoint-* are added (allowing the initial ALPC connection), OleSetClipboard still fails with 0x8007000E (E_OUTOFMEMORY).

After the sandboxed process connects to cbdhsvc's ALPC port and registers an IDataObject, cbdhsvc must call back into the sandboxed process's COM LRPC server port (\RPC Control\OLE*) to marshal the object. Sandboxie applies a custom restrictive DACL to LRPC ports created by sandboxed processes, preventing cbdhsvc (which runs unsandboxed) from connecting → cbdhsvc returns the error to COM → E_OUTOFMEMORY.

NoSecurityIsolation=y disables the custom DACL modification on sandbox-created objects → cbdhsvc's callback succeeds.

Additional Investigation: Domain Membership

Machine A is joined to an enterprise AD domain. We investigated whether domain group membership or domain GPO DCOM restrictions contribute to the failure.

Conclusion: domain membership is coincidental and does not contribute.

Evidence:

1. Full token dump (62 groups) confirms S-1-5-11 (Authenticated Users) and S-1-5-4 (Interactive) are present and enabled in the token — no missing well-known SIDs.
2. Machine B added SandboxieLogon=y explicitly. Its raw syscall results are identical (epmapper=DENIED, clipsfk=DENIED). It still succeeds — proving the token composition is not the differentiator; the Build version is.
3. Domain GPO sets DefaultLaunchPermission to BA+IU+SY, but cbdhsvc is a per-user service running as the interactive user — covered by the IU ACE.

Workaround (confirmed working on Build 22631)

Add to [TG2] in Sandboxie.ini:

Template=OpenCOM
OpenIpcPath=\RPC Control\ClipServiceTransportEndpoint-*
NoSecurityIsolation=y

Note: OpenIpcPath=\RPC Control\clipsfk is not needed — clipsfk is only accessed by cbdhsvc itself, which runs unsandboxed.

Proposed Fix

In SbieDll, extend the clipboard endpoint forwarding to handle ClipServiceTransportEndpoint-* in addition to clipsfk, so the SbieSvc proxy path works on Windows 11 Build 22631 (23H2) without requiring NoSecurityIsolation=y.

Specifically: wherever SbieDll special-cases the port name clipsfk as a clipboard ALPC endpoint (in the NtAlpcConnectPort hook and the SbieSvc forwarding path), apply the same logic to any port name matching ClipServiceTransportEndpoint-*.

This would make the fix self-contained at the hook layer and avoid the need for NoSecurityIsolation=y, which is a broad security reduction.

LLM Declaration

This issue was drafted with the assistance of a Large Language Model (LLM). The diagnostic tool (clipboard_test.exe) was developed collaboratively during the investigation.
All test results, log outputs, and conclusions have been reviewed and verified by the reporter.

How often did you encounter it so far?

Everytime

Expected behavior

Copy and paste success.

Affected program

A tiny diagnostic tool shows the key issue

Download link

NA

Where is the program located?

The program is installed both inside and outside the sandbox.

Did the program or any related process close unexpectedly?

No, not at all.

Crash dump

No response

What version of Sandboxie are you running now?

1.17.5

Is it a new installation of Sandboxie?

I recently did a new clean installation.

Is it a regression from previous versions?

1.16.8 1.17.2 1.17.4

In which sandbox type you have this problem?

In a standard isolation sandbox (yellow sandbox icon).

Can you reproduce this problem on a new empty sandbox?

I can confirm it also on a new empty sandbox.

What is your Windows edition and version?

Windows 11 Enterprise, Build 22631.6936

In which Windows account you have this problem?

Not relevant to my request.

Please mention any installed security software

NA

Did you previously enable some security policy settings outside Sandboxie?

No response

Trace log

No response

Sandboxie.ini configuration

[GlobalSettings]
SandboxieLogon=y
# Still fails if removes SandboxieLogon=y, this is not root cause.

[TG2]
Enabled=y
BlockNetworkFiles=y
RecoverFolder=%{374DE290-123F-4565-9164-39C4925E467B}%
RecoverFolder=%Personal%
RecoverFolder=%Desktop%
BorderColor=#00fd00,ttl,6,192
Template=OpenBluetooth
Template=SkipHook
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=AutoRecoverIgnore
ConfigLevel=10
UseFileDeleteV2=y
UseRegDeleteV2=y
AutoRecover=y