Mouse input from seat still controls the console even with EnableKeyboardMouseIsolation: true and hooks confirmed active

[Lepipassier]

What happened

With a seat provisioned and EnableKeyboardMouseIsolation set to true, moving the mouse on the Moonlight client (laptop) also moves the console's mouse cursor. The reverse doesn't happen — console mouse movement doesn't affect the seat.

I confirmed:

appsettings.json on the installed copy (C:\Program Files\MultiSeat\appsettings.json) correctly shows "EnableKeyboardMouseIsolation": true
MultiSeatInputHook.dll is present in the install dir (built successfully via install-service.ps1 with MSYS2 installed)
Dashboard's Input tab shows Hooks: Installed, Target Session: Session #2 (the correct active seat)
Reprovisioned the seat after the config change, restarted the service, even rebooted the whole machine — same result every time

So by every signal the dashboard exposes, the hook looks correctly installed and targeting the right session, but isolation isn't actually happening in practice.

Possible related cause?

While digging into a separate issue, I found that Apollo isn't creating an isolated virtual display for this seat (SudoVDA driver missing from the Apollo install — separate report incoming on that). The seat is currently falling back to capturing the session's RDP surface instead of a proper virtual display.

Is it possible the mouse isolation hook depends on (or behaves differently without) an isolated virtual display for the seat? I.e. without SudoVDA giving the seat its own display surface, is there a shared surface/coordinate space that lets seat mouse events bleed into the console regardless of the hook being active? Or are these two things unrelated and I should keep looking elsewhere for the mouse leak?

Happy to provide Event Log output from MultiSeat.Service.Input.InputHookManager or anything else that'd help narrow it down.

[vibesoftwarecoder]

Your configuration is correct, your build is correct, and the dashboard is telling you the truth as
far as it goes. The feature is a no-op. EnableKeyboardMouseIsolation has never filtered anything,
on any host, including mine — so nothing you changed could have made a difference, and I'm sorry you
spent a reprovision, a service restart and a reboot proving that.

Why it cannot work

The low-level hooks (WH_KEYBOARD_LL / WH_MOUSE_LL) are installed from the MultiSeat service,
which runs in session 0. The filter decides using GetForegroundWindow():

DWORD fgSession = GetForegroundSessionId();

// If no foreground window exists ... pass through instead
if (fgSession == 0xFFFFFFFF)
    return TRUE;

return fgSession == g_targetSessionId;

In session 0 there is no interactive desktop, so GetForegroundWindow() returns NULL, fgSession
comes back 0xFFFFFFFF, and the pass-through branch fires for every event. The return FALSE
that would block input is unreachable from where the hook lives. On top of that, low-level hooks only
observe the active input desktop, which session 0 is not — so the hook is not seeing seat input in
the first place.

Hooks: Installed means SetWindowsHookEx returned a handle. That is all it has ever meant. It is
a true statement about the hook and a misleading one about isolation, and you read it exactly the way
anyone would.

That's on us, and it's now fixed (63a73bd):
turning the option on logs a warning saying it filters nothing and why, /api/input/hooks/status
gained a filtering field (always false) with a note, and the "DLL not found" message no longer
implies the feature would work once you build it. The option stays off by default and is documented
as a no-op in CLAUDE.md — that documentation existed, but nothing said it at the moment you switched
it on, which is the part that failed you.

Your hypothesis — unrelated, and you can stop pulling that thread

is there a shared surface/coordinate space that lets seat mouse events bleed into the console

No. There's no shared coordinate space between Windows sessions, and mouse injection is
session-scoped — SendInput reaches the desktop of the session doing the injecting and cannot cross
into another. A missing virtual display changes what Apollo captures; it cannot change where input
lands. The two are independent.

(Related, and worth knowing before you file the SudoVDA report: a seat never gets its own virtual
display anyway, on any host. The monitor is created and attaches to the console desktop; the seat
enumerates zero. @jmlopezdona measured it conclusively in #15. So SudoVDA "missing from the Apollo
install" is very likely not your bug either — the seat capturing the RDP surface is the normal,
expected path today. Do still file it if something else looks off.)

So what is actually moving your console cursor?

By design there is nothing to isolate: physical input goes to the console session, and Moonlight
input is injected by Apollo inside the seat's own session. If moving the client's mouse moves the
console cursor, the most likely explanation is that the Apollo your Moonlight client is connected
to is not running in the seat session — most often because the client is paired to the standalone
host Apollo rather than the seat's instance. That would produce precisely your asymmetry: the client
drives the console, while the console's own mouse does nothing to the seat.

Three commands will settle it. From an elevated PowerShell on the host, while the client is connected:

# 1. Which session is each Apollo in?  Seat Apollo must NOT be in the console session.
Get-Process sunshine -ErrorAction SilentlyContinue |
  Select-Object Id, SessionId, Path

# 2. Which sessions exist, and which is the console?
query session

# 3. Which port is your Moonlight client actually talking to?
#    MultiSeat seats start at 48100 (seat 0), 48130 (seat 1), ...
#    A standalone/stock Apollo sits near 47989.
Get-NetTCPConnection -State Established |
  Where-Object { $_.LocalPort -ge 47900 -and $_.LocalPort -le 48300 } |
  Select-Object LocalPort, RemoteAddress, OwningProcess

If #1 shows the sunshine.exe serving your client with the same SessionId as the console, or
#3 shows the client connected on ~47989 rather than your seat's port, that's the whole answer — you're
streaming the console, not the seat, and no amount of hook configuration would change it.

Please paste those three outputs and I'll take it from there. The Event Log lines you offered are
welcome too, though based on the above I expect them to show the hooks installing successfully and
nothing else of interest.

[Lepipassier]

Ran the three checks — all point away from the "wrong Apollo" theory:

Get-Process sunshine → single instance, correct seat SessionId (not the console session). No standalone host Apollo process exists at all right now — the dashboard's Host card shows "Not running."
query session → seat is rdp-tcp#0, correct account, Active.
Ports/connections: no TCP Established entries showed up on the seat's port even mid-stream (multiple minutes of uptime), which threw me off initially — I believe that's just because the actual media stream is UDP/ENet, not TCP, so Get-NetTCPConnection -State Established was never going to see it regardless. TCP listen state and UDP binds on the seat's port range all check out and match its PortBase.

Also checked Apollo's own web UI (https://localhost: on the host) → Device Management shows exactly one paired client, "Legacy Moonlight Client," on this seat's Apollo instance specifically. No standalone host Apollo is even running to have mistakenly paired with.

So the client is definitely talking to the seat's Apollo, on the right port, in the right session — not the console.

One more data point since then: I did a full clean reinstall (fresh clone of master at 9c052a4, wiped C:\Program Files\MultiSeat, C:\ProgramData\MultiSeat, and C:\Program Files\ApolloVibe, reran prerequisites + install-service from scratch, new account, new seat). Audio (PerSession mode) works perfectly again post-reinstall, as expected. Mouse behavior is identical to before — laptop mouse still moves the console cursor, console mouse doesn't affect the seat. So this isn't a stale-install or leftover-state issue either.

Given your earlier explanation that EnableKeyboardMouseIsolation is an architectural no-op (session 0 hook, GetForegroundWindow() always NULL), and now that the "wrong Apollo" theory is ruled out too, where should I look next?

[vibesoftwarecoder]

Thanks — and first, a correction I owe you.

The TCP check I gave you could never have worked. You were right about why: the media stream is
UDP/ENet, so Get-NetTCPConnection -State Established was never going to show anything on the seat's
port no matter how healthy the stream was. You worked that out yourself and still did the run, which
is more than the check deserved. I have stopped using it here too — the honest equivalents are the
UDP binds you already checked and Apollo's own CLIENT CONNECTED / CLIENT DISCONNECTED lines in
the seat's apollo.log.

Your three results do rule out the wrong-Apollo theory conclusively, so here is where I would look
next and why.

Why this shouldn't be possible, which is what makes it interesting

Apollo injects mouse motion with SendInput (ViGEm is only used for gamepads). SendInput is
delivered to the input desktop of the calling process's session. Your seat's Apollo is in the
seat session — you proved that — so its input should not be able to reach the console desktop at
all. That is exactly the reasoning behind our claim that this design has no cross-session
keyboard/mouse bleed, and your report contradicts it, so one of the two is wrong.

The one place that reasoning could break is Apollo's retry path. send_input() calls SendInput,
and if the call fails it re-syncs the thread's desktop (OpenInputDesktop + SetThreadDesktop)
and tries again. So the interesting question is whether injection inside your seat is failing.

The check that decides it

In the seat's apollo.log (C:\ProgramData\MultiSeat\apollo\<AccountName>\apollo.log), while you
move the mouse from the client, look for either of these exact strings:

Couldn't send input
Failed to Open Input Desktop [0x...]

• If they appear: injection is failing inside the seat, and whatever is moving your console
  cursor is a second input path, not Apollo delivering to the wrong place. That is a very different
  bug from the one this issue assumes.
• If they do not appear: Apollo believes it delivered the input into the seat session
  successfully — in which case the console movement needs a source we have not identified yet, and
  I would want the next two answers to narrow it.

Two questions that would narrow it a lot

1. Does the keyboard leak too, or only the mouse? Both go through the same SendInput path, so
   "mouse leaks, keyboard doesn't" and "both leak" point at very different causes.
2. When the console cursor moves, does the seat's own cursor move as well? Both moving means the
   input is being delivered twice or the two desktops are not as separate as we think; only the
   console moving means it is being delivered to the wrong session outright.

Unrelated bug found while reading that code, in case you see it in your logs

While tracing the retry path I found a real defect and fixed it
(30cc3859): syncThreadDesktop()
closed the desktop handle it had just assigned to the thread and then returned that dead handle,
which callers store and compare to decide whether to retry. A recycled handle value reads as "same
desktop, don't retry" and the input gets dropped with Couldn't send input.

I am not claiming this is your bug — it affects whether a retry happens, not which session input
lands in, and your symptom is input arriving somewhere it should not. But it is in the same code
path, so if you do see Couldn't send input in that log, tell me and it becomes much more relevant.

[Lepipassier]

Here are the results from the three checks:

1. Log check (apollo.log during mouse movement)
   Neither Couldn't send input nor Failed to Open Input Desktop appear anywhere in the logs. Apollo reports a normal stream startup (NVENC, 1080p, audio setup) and believes SendInput is delivering successfully into the seat session.

2. Keyboard leak
   Mouse only. The keyboard does not leak at all — typing on the Moonlight client stays strictly within the seat session and does not affect the console.

3. Cursor behavior
   Both cursors move simultaneously. Moving the mouse on the Moonlight client drives the cursor inside the seat and moves the physical console cursor at the same time.

[vibesoftwarecoder]

Your third answer is the one that cracked this open, so I went and measured the thing it implied
rather than theorising at you again. The short version: input from a seat cannot reach your console
session, and I can now show that rather than assert it — which means the cursor you are watching is
almost certainly not being moved by Apollo at all.

What I measured

On a host with a seat provisioned, I ran a probe inside the seat session that makes exactly the
calls Apollo makes — pulled out of src/platform/windows/input.cpp, not guessed:

what ran in the seat	result in the seat	console cursor
abs_mouse() — SendInput with MOUSEEVENTF_MOVE|ABSOLUTE|VIRTUALDESK, coords scaled to 0–65535	SendInput=1, cursor landed within 1 px of target, 3 points	no change
move_mouse() — SendInput with relative MOUSEEVENTF_MOVE	SendInput=1, cursor tracked each delta, 3 moves	no change
SetCursorPos() direct, 6 points	exact match every time	no change

The console side sampled GetCursorPos() every 75 ms throughout: 320 samples, 0 changes, over two
independent runs. Before trusting that, I made the watcher prove it could fail — it caught two
deliberate console-side moves with timestamps — and the seat probe logged its own session id, user,
and a per-point read-back, so "nothing happened" cannot be a probe that silently never ran.

Same architecture as yours: RDP-loopback seat, its own Windows account, its own Apollo, hidden
mstsc holding the session Active.

What that leaves

Since seat input demonstrably does not cross into the console, one of these two is true:

1. The console cursor is not actually moving — you are seeing the seat's cursor drawn on your
console screen. MultiSeat keeps a hidden mstsc.exe in the console session for the lifetime of
each seat (Apollo's display APIs stop working on a non-Active session, so something has to hold it).
That window is a full-screen RDP client showing the seat's desktop. An RDP client renders the
remote pointer wherever the server's cursor is, whether or not the window has focus — so if the
hide fails, a cursor moves on your console screen in perfect sync with the seat, and it is the same
cursor drawn twice.

This is not hypothetical: that window has escaped before, in #8 — the hide was running inside the
SYSTEM service in session 0, where window enumeration cannot see the console desktop, so it was a
silent no-op and the RDP window sat on the host's screen. That was fixed by moving the hide into a
console-session helper, but it is the fragile part of this design and your symptom is exactly what a
regression there looks like.

It also explains the two answers that otherwise do not fit together: there is no keyboard equivalent
of a rendered cursor (so the keyboard "does not leak"), and both cursors move simultaneously because
there is only one.

2. The console cursor really is moving, and something other than the seat's Apollo is moving it.
Possible, but it would not be this feature or this code path, and I would want to find out what.

The one command that tells us which

Run this on the host, in the console session, while you move the mouse from the Moonlight client.
It samples the real console cursor position and logs every change:

Add-Type -TypeDefinition @'
using System; using System.Runtime.InteropServices;
public struct PT { public int X; public int Y; }
public static class Cur {
  [DllImport("user32.dll")] public static extern bool GetCursorPos(out PT p);
}
'@
$p = New-Object PT; [void][Cur]::GetCursorPos([ref]$p)
$lx = $p.X; $ly = $p.Y; $n = 0; $c = 0
"start $lx,$ly"
$end = (Get-Date).AddSeconds(30)
while ((Get-Date) -lt $end) {
  if ([Cur]::GetCursorPos([ref]$p)) {
    $n++
    if ($p.X -ne $lx -or $p.Y -ne $ly) { $c++; "MOVED $lx,$ly -> $($p.X),$($p.Y)"; $lx = $p.X; $ly = $p.Y }
  }
  Start-Sleep -Milliseconds 75
}
"$n samples, $c changes"

• You see a cursor moving on screen but this prints 0 changes → it is the rendered remote
  cursor. Case 1, our bug, and I know where to look.
• It prints MOVED lines tracking your client mouse → case 2, something really is driving the
  console cursor, and that is a genuinely new fault.

Please don't move the host's own mouse while it runs, or the changes will be yours.

And if it turns out to be case 1, this confirms it

Same session, with the seat running — it reports whether the keepalive window is actually hidden:

Add-Type -TypeDefinition @'
using System; using System.Text; using System.Runtime.InteropServices;
public struct RC { public int L,T,R,B; }
public static class W {
  [DllImport("user32.dll")] public static extern bool IsWindowVisible(IntPtr h);
  [DllImport("user32.dll")] public static extern bool GetWindowRect(IntPtr h, out RC r);
  [DllImport("user32.dll")] public static extern int GetClassName(IntPtr h, StringBuilder s, int n);
  [DllImport("user32.dll")] public static extern bool EnumWindows(EnumProc cb, IntPtr p);
  [DllImport("user32.dll")] public static extern uint GetWindowThreadProcessId(IntPtr h, out uint pid);
  public delegate bool EnumProc(IntPtr h, IntPtr p);
}
'@
$mstsc = Get-Process mstsc -ErrorAction SilentlyContinue
if (-not $mstsc) { "no mstsc running - nothing is holding a seat session open"; return }
$mstscPids = @($mstsc.Id)
"mstsc pids: $($mstscPids -join ', ')"

# Collect inside the callback, print after: anything written to the output stream inside an
# EnumWindows callback is swallowed as the delegate's return value and never reaches the console.
$script:hits = @()
$cb = [W+EnumProc]{ param($h,$x)
  $wp = 0; [void][W]::GetWindowThreadProcessId($h, [ref]$wp)
  if ($mstscPids -contains $wp) {
    $sb = New-Object System.Text.StringBuilder 256
    [void][W]::GetClassName($h, $sb, 256)
    if ($sb.ToString() -eq 'TscShellContainerClass') {
      $r = New-Object RC; [void][W]::GetWindowRect($h, [ref]$r)
      $script:hits += "TscShellContainerClass  visible=$([W]::IsWindowVisible($h))  rect=$($r.L),$($r.T),$($r.R),$($r.B)"
    }
  }
  return $true
}
[void][W]::EnumWindows($cb, [IntPtr]::Zero)

if ($script:hits.Count -eq 0) { "mstsc is running but has no TscShellContainerClass window" }
else { $script:hits }

On my host that prints:

mstsc pids: 25320
TscShellContainerClass  visible=False  rect=-8,-8,1928,1040

Note the rect — that window is full-screen; visible=False is the only thing keeping it off the
console. If yours prints visible=True, that is the whole answer: the window is sitting on your
console showing the seat's desktop, and the "leak" is a picture of a cursor.

(Both snippets are tested on Windows PowerShell 5.1 as well as PowerShell 7, so either will do.)

Housekeeping

Two corrections I owe you from earlier in this thread, both already noted above but worth keeping
together: the Get-NetTCPConnection check could never have worked (UDP stream — you spotted that),
and the "second input path" I floated last time was speculation, which the measurement above has now
replaced. EnableKeyboardMouseIsolation remains a no-op and remains irrelevant to this, and none of
it was ever going to be fixed by anything you configured.

Thanks for running all of it — the keyboard-vs-mouse split and "both cursors move" are what made this
answerable, and neither was something I could have got without you.

[Lepipassier]

Here are the results:

Script 1 (Console Cursor Tracking):

start 798,159
MOVED 798,159 -> 767,174
MOVED 767,174 -> 753,200
...
373 samples, 88 changes
Script 2 (mstsc Keepalive Window):

mstsc pids: 7888
TscShellContainerClass visible=False rect=-8,-8,1928,1088

Takeaway
It's Case 2!

The mstsc window is properly hidden (visible=False), ruling out the RDP window overlay theory (Case 1).

The console cursor is genuinely moving (88 physical coordinate updates detected while only moving the Moonlight client mouse).

So something in this environment is driving the physical console cursor when the seat receives input. Let me know what you'd like me to trace next!

[vibesoftwarecoder]

That's conclusive, and it kills my theory. Thank you for running both — a result that disproves the
person who proposed it is the most useful kind.

88 coordinate changes in 373 samples, with visible=False on the keepalive window. The window is
hidden and the console cursor is genuinely moving. Not a rendered image, not the RDP overlay.

A correction I owe you, because it shaped my last reply

I measured 320 samples / 0 changes on my host and told you "input from a seat cannot reach the
console." What I was actually entitled to say is "cannot on my configuration." Your result proves
your host does something mine does not, and I generalised a negative from a single machine. That's on
me, and it means the interesting question now is what differs, not whether it happens.

The constraint that still holds

Mouse leaks, keyboard does not. That rules out anything forwarding input generically — a remote
control tool, a misrouted session, a second Apollo would all carry keystrokes too. Whatever is doing
this is pointer-specific, which is a much smaller family.

Four things, cheapest first

1. Do the clicks actually work? With the client connected, move the pointer over something on the
console — Start button, a window's title bar — and click.

• Console window activates / button responds → real input is reaching the console session.
• Cursor moves but clicks do nothing → only the cursor position is being driven, not input.
  Those are very different bugs, and this costs you ten seconds to tell apart.

2. What virtual HID input devices exist on the host?

Get-PnpDevice -Class HIDClass -ErrorAction SilentlyContinue |
  Where-Object { $_.FriendlyName -match 'pointer|touch|pen|virtual|mouse' } |
  Select-Object Status, FriendlyName, InstanceId | Format-Table -AutoSize

Worth running twice — once with the Moonlight client disconnected, once connected — and
comparing. Anything that appears only while streaming is very interesting. For calibration, my own
host lists a Logitech G HUB Virtual Mouse; peripheral software ships these routinely, and a virtual
HID pointer is not session-scoped the way SendInput is.

3. What else is running on that console session? Specifically RustDesk, AnyDesk, Parsec,
TeamViewer, Steam Remote Play, or vendor peripheral software (G HUB, Synapse, iCUE, SteelSeries GG).
Any of those can drive a pointer, and it would explain why my host behaves differently — I run none of
them on the console.

4. Set EnableKeyboardMouseIsolation back to false, reprovision, and retest. This is the one
configuration difference I can actually name between our hosts: yours true, mine false. I checked
the hook source before asking — MultiSeat.InputHook contains no SendInput, mouse_event or
SetCursorPos anywhere, so it never injects anything and should be incapable of causing this. But
it's the only delta I know of, and eliminating it takes two minutes.

The hypothesis I'd test if 1–3 point at Apollo

Apollo has a second pointer path besides SendInput: CreateSyntheticPointerDevice /
InjectSyntheticPointerInput, used for touch and pen. A synthetic pointer is a system-level device
object rather than a session-scoped call — and it has no keyboard equivalent, which fits your
asymmetry exactly. Your client identifies as "Legacy Moonlight Client", so if it's sending pointer/touch
events rather than plain relative mouse, that path could be in play. Trying a different Moonlight
client, or turning off touch/absolute-mouse on the client, would move that needle.

I'm holding it as a hypothesis rather than a conclusion — I haven't verified whether that path is
session-scoped, and after this round I'd rather not hand you another theory dressed as a finding.

One thing I did not send you

I tried to build a probe that answers "is this injected input or a real device" directly, using a
low-level mouse hook and the LLMHF_INJECTED flag. It reported zero events on my machine even for
mouse input I injected myself as a control, so it has a silent-failure mode I can't yet explain. Given
that's the second check I've handed you that couldn't have worked, I'm keeping this one until it
passes its own control. The four questions above are all things I've verified actually run.

[Lepipassier]

Here are the results for the 4 points:

1. Do clicks work on the console?
   No. Clicks on the Moonlight client do not activate windows or click buttons on the console. Only the cursor position moves on the console screen.

2. Virtual HID devices check:
   The PowerShell command returns empty results both when disconnected and connected. No new HID virtual devices are created.

3. Third-party software:
   None running (no RustDesk, AnyDesk, Parsec, Razer Synapse, G HUB, iCUE, etc.).

4. Setting EnableKeyboardMouseIsolation to false:
   Retested with "EnableKeyboardMouseIsolation": false -> Same behavior (console cursor position still tracks client mouse movements, but no clicks pass through).

Conclusion:
The fact that only position moves without click events seems to heavily support your hypothesis regarding InjectSyntheticPointerInput / CreateSyntheticPointerDevice (or absolute/synthetic pointer positioning) updating the global system cursor metrics across sessions!

[vibesoftwarecoder]

That's a clean set of results, thank you. I just checked the synthetic-pointer idea against Apollo's
source and it doesn't seem to be it. What rules it out is actually your own measurement.

Why it isn't the synthetic pointer

A mouse never gets near that code path. In src/platform/windows/input.cpp,
inject_synthetic_pointer_input is called from exactly three places, all inside repeat_touch,
repeat_pen, cancel_all_active_touches and touch_update. Touch and pen, nothing else. Mouse input
goes through abs_mouse, move_mouse, button_mouse and scroll, and all four of those end up in
send_input(), which is plain old SendInput. So unless your client is sending touch events,
CreateSyntheticPointerDevice never even gets called.

And your first result rules out more than that. You found that position moves but clicks don't.
The thing is, button_mouse uses the same send_input() as the movement calls. Same function, same
process, same session. If that path were leaking into your console, it'd leak the clicks too. It can't
leak one and not the other.

That rules out the whole "something is injecting input into your console" family, not just that one
variant. It doesn't explain your cursor yet, but it does mean we can stop digging around input
handling and start looking at what else touches both sessions at once.

So what moves a cursor but never clicks anything?

Nothing that's injecting input. Something that's mirroring the seat's cursor position onto your
console. Position only, no buttons, no keyboard, which is exactly what a remote desktop client does
when the server tells it where the pointer went.

Which brings us back to the hidden mstsc holding your seat's session open. I raised that two replies
ago and dropped it, because I tested it here and nothing happened: I moved the seat's cursor from
inside the seat with SetCursorPos and with Apollo's exact SendInput calls, and the console cursor
didn't budge across 320 samples, with the keepalive window hidden just like yours.

So your machine is doing something mine isn't, and I still don't know what.

Let's poke both machines with the same stick

Every round so far we've used a different stimulus on each host, which is a lousy way to find a
difference. This one is identical on both, and it runs with no Moonlight client connected, so
Apollo is out of the picture entirely.

1. Provision a seat as usual and don't connect Moonlight. Note the seat's session id (query session, or the dashboard).

2. Save this as C:\ProgramData\MultiSeat\seat-cursor.ps1:

$log = 'C:\ProgramData\MultiSeat\seat-cursor.log'
Add-Type -TypeDefinition @'
using System;
using System.Runtime.InteropServices;
public struct PT { public int X; public int Y; }
public static class Cur {
  [DllImport("user32.dll")] public static extern bool GetCursorPos(out PT p);
  [DllImport("user32.dll")] public static extern bool SetCursorPos(int x,int y);
}
'@
function Log($m) { Add-Content $log "$((Get-Date).ToString('HH:mm:ss.fff'))  $m" -Encoding ASCII }
Log "---- start ----"
Log "whoami    : $(whoami)"
Log "sessionId : $((Get-Process -Id $PID).SessionId)"
$p = New-Object PT
foreach ($pt in @(@(200,150), @(1500,150), @(900,800), @(200,900), @(1500,900))) {
    $ok = [Cur]::SetCursorPos($pt[0], $pt[1])
    Start-Sleep -Milliseconds 250
    [void][Cur]::GetCursorPos([ref]$p)
    Log "target=$($pt[0]),$($pt[1]) set=$ok seatpos=$($p.X),$($p.Y)"
    Start-Sleep -Milliseconds 1500
}
Log "---- end ----"

3. Register it to run as the seat account from an elevated console PowerShell. -LogonType Interactive drops it into the session that account already has open, so there's no password involved:

$act  = New-ScheduledTaskAction -Execute 'powershell.exe' `
        -Argument '-NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden -File "C:\ProgramData\MultiSeat\seat-cursor.ps1"'
$prin = New-ScheduledTaskPrincipal -UserId 'YOURHOST\SeatAccount' -LogonType Interactive -RunLevel Limited
Register-ScheduledTask -TaskName 'CursorProbe' -Action $act -Principal $prin

4. Start the console watcher from my last comment, then straight away:

Start-ScheduledTask -TaskName 'CursorProbe'

5. When it's done, Unregister-ScheduledTask -TaskName 'CursorProbe' -Confirm:$false, and post
C:\ProgramData\MultiSeat\seat-cursor.log along with the watcher output.

What the two outcomes mean

• Console cursor moves. The RDP layer is mirroring the seat's cursor onto your console, Apollo and
  Moonlight have nothing to do with it, and it's a MultiSeat architecture problem I can go and work
  on. It'd also mean there's a setting differing between our machines that I need to find.
• Console cursor sits still. Then it only happens while a client is streaming, which narrows
  things a lot and tells me to look at what changes on connect rather than at input injection.

Please send the seat log too, not just the watcher output. It shows the probe actually ran, which
session it landed in, and that the seat's own cursor really moved. Without it, "the console didn't
move" doesn't mean anything.

I ran this exact procedure here before sending it to you, on a seat with no client connected, so
you've got a baseline to compare against and I'm not handing you something untested for a third time:

seat   : sessionId 13, all five points set=True, seatpos matched the target every time
console: 281 samples, 0 changes

If yours moves under the same stimulus, that's the difference between our two machines.

Where we are

Five rounds in and this has cost you a lot of test runs. They've bought something, though: the
isolation setting turned out to be irrelevant and now says so out loud, the wrong-Apollo theory is
gone, the rendered-cursor theory is gone, and as of today so is the entire "something is injecting
input into your console" family. What's left is the one bit of MultiSeat's own design that touches
both sessions at once.

I've been confidently wrong twice in this thread already, so I'd rather run one clean comparison than
hand you a third theory.

[Lepipassier]

Here are the results from the probe run:

Console Watcher Output:

start 1135,580
191 samples, 0 changes
C:\ProgramData\MultiSeat\seat-cursor.log:

12:05:37.115 ---- start ----
12:05:37.202 whoami : lepipassier\lockall
12:05:37.217 sessionId : 2
12:05:37.504 target=200,150 set=False seatpos=1273,683
12:05:39.268 target=1500,150 set=False seatpos=1273,683
12:05:41.023 target=900,800 set=False seatpos=1273,683
12:05:42.786 target=200,900 set=False seatpos=1273,683
12:05:44.538 target=1500,900 set=False seatpos=1273,683
12:05:46.043 ---- end ----
Key Observations:
Console stayed completely still (0 changes) while no Moonlight client was connected.

SetCursorPos returned False for every single call inside Session 2 (likely because without an active stream/input session, there is no active input desktop for SetCursorPos to target).

This narrows it down significantly: the cursor movement on the console only happens while a Moonlight client is actively connected and streaming.

[vibesoftwarecoder]

Thanks for running it, and for posting the seat log — it shows the run didn't actually test
anything.

The probe never fired

target=200,150  set=False  seatpos=1273,683
target=1500,150 set=False  seatpos=1273,683
... all five, set=False, seatpos never changes

SetCursorPos returned False every time and the seat's own cursor stayed at 1273,683 from start to
finish. So the seat cursor never moved, which means the console cursor had nothing to mirror. 191 samples, 0 changes is what that run had to produce no matter what your machine does — it can't tell
us that the leak only happens while streaming, or anything else.

That's on the script I sent you. It printed set=False and then carried on as if the test had
happened; it should have refused to report a result. Fixed below.

But set=False is the most interesting line in this thread so far

It returned True on all five points here. So we finally have a concrete, reproducible difference
between our two hosts, and it's in exactly the area we were suspicious of.

SetCursorPos fails like that when the calling thread isn't on the session's input desktop.
Usual causes:

• the seat session is locked or sitting on the secure desktop, so Winlogon owns input and a
  normal process on Default is refused;
• the session is Disconnected rather than Active;
• the process landed on a different window station / desktop than the one receiving input.

Notice the first two are about the state of the seat session — and the thing that's supposed to keep
that session Active is the hidden mstsc keepalive, which is the one piece of MultiSeat that touches
your console and your seat at the same time. If your seat sits in a different state than mine, that
would be worth knowing regardless of the cursor question.

Your process could read the cursor fine (seatpos was a real position) but not move it, which is
consistent with a permissions/desktop problem rather than a broken script.

New scripts — these check themselves before they report anything

seat-cursor-probe.ps1 — same idea, but it now logs where it actually is and whether the
stimulus landed:

• window station, its own desktop, and the input desktop name, plus whether they match;
• GetLastError() on any call that fails, so set=False comes with a reason;
• if it isn't on the input desktop, it attaches to it with SetThreadDesktop first — the same thing
  Apollo's syncThreadDesktop() does — and logs whether that worked;
• a second stimulus after SetCursorPos: SendInput with MOVE|ABSOLUTE|VIRTUALDESK, which is
  Apollo's actual mouse call, in case one path is allowed and the other isn't;
• it restores your cursor position at the end;
• and it ends with a verdict: PROBE VALID if the seat cursor really moved, PROBE INVALID if it
  didn't, in which case the console reading means nothing and we don't use it.

# seat-cursor-probe.ps1 - run INSIDE the seat session, via a scheduled task.
# Hardened: proves the stimulus actually happened before any conclusion is drawn from it.
$log = 'C:\ProgramData\MultiSeat\seat-cursor.log'

if (-not ('Probe' -as [type])) {
Add-Type -TypeDefinition @'
using System;
using System.Text;
using System.Runtime.InteropServices;

public struct PT { public int X; public int Y; }

[StructLayout(LayoutKind.Sequential)]
public struct MOUSEINPUT {
  public int dx; public int dy; public uint mouseData;
  public uint dwFlags; public uint time; public IntPtr dwExtraInfo;
}
[StructLayout(LayoutKind.Sequential)]
public struct INPUT { public uint type; public MOUSEINPUT mi; }

public static class Probe {
  [DllImport("user32.dll", SetLastError=true)] public static extern bool GetCursorPos(out PT p);
  [DllImport("user32.dll", SetLastError=true)] public static extern bool SetCursorPos(int x, int y);
  [DllImport("user32.dll", SetLastError=true)] public static extern uint SendInput(uint n, INPUT[] p, int cb);
  [DllImport("user32.dll", SetLastError=true)] public static extern int GetSystemMetrics(int i);
  [DllImport("user32.dll", SetLastError=true)] public static extern IntPtr GetProcessWindowStation();
  [DllImport("user32.dll", SetLastError=true)] public static extern IntPtr GetThreadDesktop(uint tid);
  [DllImport("user32.dll", SetLastError=true)] public static extern IntPtr OpenInputDesktop(uint f, bool inh, uint acc);
  [DllImport("user32.dll", SetLastError=true)] public static extern bool SetThreadDesktop(IntPtr h);
  [DllImport("user32.dll", SetLastError=true)] public static extern bool CloseDesktop(IntPtr h);
  [DllImport("kernel32.dll")] public static extern uint GetCurrentThreadId();
  [DllImport("user32.dll", SetLastError=true, CharSet=CharSet.Unicode)]
  public static extern bool GetUserObjectInformationW(IntPtr h, int idx, StringBuilder p, int len, out int need);

  public static int Err() { return Marshal.GetLastWin32Error(); }

  public static string NameOf(IntPtr h) {
    if (h == IntPtr.Zero) { return "<null>"; }
    StringBuilder sb = new StringBuilder(256); int need;
    if (GetUserObjectInformationW(h, 2, sb, sb.Capacity, out need)) { return sb.ToString(); }
    return "<err " + Marshal.GetLastWin32Error() + ">";
  }

  public static IntPtr InputDesktop() { return OpenInputDesktop(0, false, 0x0001 | 0x0100); }

  // Apollo's own call: SendInput MOVE|ABSOLUTE|VIRTUALDESK with 0-65535 coords.
  public static uint MoveAbsRaw(int nx, int ny) {
    INPUT[] inp = new INPUT[1];
    inp[0].type = 0;
    inp[0].mi.dx = nx;
    inp[0].mi.dy = ny;
    inp[0].mi.dwFlags = 0x0001 | 0x8000 | 0x4000;
    return SendInput(1, inp, Marshal.SizeOf(typeof(INPUT)));
  }
}
'@
}

function Log($m) { Add-Content $log "$((Get-Date).ToString('HH:mm:ss.fff'))  $m" -Encoding ASCII }

Log "---- start ----"
Log "whoami      : $(whoami)"
Log "sessionId   : $((Get-Process -Id $PID).SessionId)"
Log "elevated    : $(([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))"

# --- Where is this process actually running? This is what decides whether input APIs work at all.
$winsta  = [Probe]::NameOf([Probe]::GetProcessWindowStation())
$deskCur = [Probe]::NameOf([Probe]::GetThreadDesktop([Probe]::GetCurrentThreadId()))
$hInput  = [Probe]::InputDesktop()
if ($hInput -eq [IntPtr]::Zero) {
    $deskIn = "<OpenInputDesktop failed, err $([Probe]::Err())>"
} else {
    $deskIn = [Probe]::NameOf($hInput)
}
Log "windowsta   : $winsta"
Log "my desktop  : $deskCur"
Log "input desk  : $deskIn"
Log "on input?   : $($deskCur -eq $deskIn)"

$vx = [Probe]::GetSystemMetrics(76); $vy = [Probe]::GetSystemMetrics(77)
$vw = [Probe]::GetSystemMetrics(78); $vh = [Probe]::GetSystemMetrics(79)
Log "virtualdesk : origin=$vx,$vy size=${vw}x${vh}"

# --- If we are not on the input desktop, do what Apollo's syncThreadDesktop() does and attach to it.
if ($hInput -ne [IntPtr]::Zero -and $deskCur -ne $deskIn) {
    $ok = [Probe]::SetThreadDesktop($hInput)
    Log "SetThreadDesktop -> $ok err=$([Probe]::Err())  (now on: $([Probe]::NameOf([Probe]::GetThreadDesktop([Probe]::GetCurrentThreadId()))))"
}

$p = New-Object PT
[void][Probe]::GetCursorPos([ref]$p)
$restore = @($p.X, $p.Y)
$moved = 0
$points = @(@(200,150), @(1500,150), @(900,800), @(200,900), @(1500,900))

foreach ($pt in $points) {
    $x = $pt[0]; $y = $pt[1]

    [void][Probe]::GetCursorPos([ref]$p)
    $before = "$($p.X),$($p.Y)"

    # stimulus 1: SetCursorPos
    $ok1  = [Probe]::SetCursorPos($x, $y)
    if ($ok1) { $err1 = '-' } else { $err1 = [Probe]::Err() }
    Start-Sleep -Milliseconds 250
    [void][Probe]::GetCursorPos([ref]$p)
    $after1 = "$($p.X),$($p.Y)"

    # stimulus 2: Apollo's SendInput, absolute over the virtual desktop
    $nx = [int]((($x - $vx) * 65535.0) / [Math]::Max(1, $vw - 1))
    $ny = [int]((($y - $vy) * 65535.0) / [Math]::Max(1, $vh - 1))
    $sent = [Probe]::MoveAbsRaw($nx, $ny)
    if ($sent -gt 0) { $err2 = '-' } else { $err2 = [Probe]::Err() }
    Start-Sleep -Milliseconds 250
    [void][Probe]::GetCursorPos([ref]$p)
    $after2 = "$($p.X),$($p.Y)"

    if ($after2 -ne $before) { $moved++ }

    Log "target=$x,$y before=$before | SetCursorPos ok=$ok1 err=$err1 pos=$after1 | SendInput sent=$sent err=$err2 pos=$after2"
    Start-Sleep -Milliseconds 1500
}

[void][Probe]::SetCursorPos($restore[0], $restore[1])
if ($hInput -ne [IntPtr]::Zero) { [void][Probe]::CloseDesktop($hInput) }

# --- The gate. Without this the console reading means nothing.
if ($moved -gt 0) {
    Log "VERDICT     : moved $moved/$($points.Count) -> PROBE VALID, the console watcher output is meaningful"
} else {
    Log "VERDICT     : moved 0/$($points.Count) -> PROBE INVALID. The seat cursor never moved, so"
    Log "VERDICT     : a still console cursor proves NOTHING. Do not draw a conclusion from this run."
}
Log "---- end ----"

console-watch.ps1 — same watcher, except it now proves it can see a cursor move before claiming
it didn't see one. It nudges the console cursor 4 px, checks its own sampling loop noticed, puts it
back, and prints selftest PASS or FAIL.

# console-watch.ps1 - run in the CONSOLE session, interactively, while the seat probe fires.
# Self-testing: it proves it can detect a cursor move before it reports that there weren't any.
param([int]$Seconds = 60)

if (-not ('Cur' -as [type])) {
Add-Type -TypeDefinition @'
using System;
using System.Runtime.InteropServices;
public struct PT { public int X; public int Y; }
public static class Cur {
  [DllImport("user32.dll", SetLastError=true)] public static extern bool GetCursorPos(out PT p);
  [DllImport("user32.dll", SetLastError=true)] public static extern bool SetCursorPos(int x, int y);
  public static int Err() { return Marshal.GetLastWin32Error(); }
}
'@
}

$p = New-Object PT
[void][Cur]::GetCursorPos([ref]$p)
$origin = @($p.X, $p.Y)
Write-Host ("sessionId : {0}" -f (Get-Process -Id $PID).SessionId)
Write-Host ("start     : {0},{1}" -f $origin[0], $origin[1])

# --- Control: nudge the console cursor 4 px and confirm this loop sees it.
$ok = [Cur]::SetCursorPos($origin[0] + 4, $origin[1] + 4)
Start-Sleep -Milliseconds 200
[void][Cur]::GetCursorPos([ref]$p)
$sawIt = ($p.X -ne $origin[0] -or $p.Y -ne $origin[1])
[void][Cur]::SetCursorPos($origin[0], $origin[1])
if ($sawIt) {
    Write-Host "selftest  : PASS - this watcher does detect console cursor movement"
} else {
    Write-Host ("selftest  : FAIL - SetCursorPos ok={0} err={1}, cursor did not move." -f $ok, [Cur]::Err())
    Write-Host "selftest  : A '0 changes' result below would be MEANINGLESS. Fix this first."
}

Write-Host ("watching  : {0}s, sampling every 75 ms - start the seat probe NOW" -f $Seconds)
[void][Cur]::GetCursorPos([ref]$p)
$last = @($p.X, $p.Y)
$samples = 0; $changes = 0
$deadline = (Get-Date).AddSeconds($Seconds)

while ((Get-Date) -lt $deadline) {
    [void][Cur]::GetCursorPos([ref]$p)
    $samples++
    if ($p.X -ne $last[0] -or $p.Y -ne $last[1]) {
        $changes++
        if ($changes -le 20) {
            Write-Host ("{0}  MOVED {1},{2} -> {3},{4}" -f (Get-Date).ToString('HH:mm:ss.fff'), $last[0], $last[1], $p.X, $p.Y)
        }
        $last = @($p.X, $p.Y)
    }
    Start-Sleep -Milliseconds 75
}

Write-Host ("result    : {0} samples, {1} changes, selftest={2}" -f $samples, $changes, $(if ($sawIt) { 'PASS' } else { 'FAIL' }))

Running it

Same as last time: provision a seat, no Moonlight client connected, register the seat script as a
scheduled task under the seat account with -LogonType Interactive, start the console watcher, then
start the task.

$act  = New-ScheduledTaskAction -Execute 'powershell.exe' `
        -Argument '-NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden -File "C:\ProgramData\MultiSeat\seat-cursor-probe.ps1"'
$prin = New-ScheduledTaskPrincipal -UserId 'YOURHOST\SeatAccount' -LogonType Interactive -RunLevel Limited
Register-ScheduledTask -TaskName 'CursorProbe' -Action $act -Principal $prin

Two extra things to grab this time, both from an elevated console prompt while the seat is up:

qwinsta
Get-Process mstsc | Select-Object Id, SessionId, StartTime

qwinsta tells us whether your seat session is Active or Disc at the moment the probe runs, which
may be the whole explanation for set=False.

What each outcome means

• Probe VALID + console moves — the RDP layer is mirroring the seat cursor onto your console.
  Apollo and Moonlight are irrelevant, and it's a MultiSeat design problem for me to fix.
• Probe VALID + console still — it genuinely only happens while streaming, and I go and look at
  what changes on connect.
• Probe INVALID again, with set=False and a reason — then the interesting question becomes why
  your seat session won't accept input at all, and the desktop/session-state lines in the log should
  tell us.

Baseline from my host, run with these exact scripts before sending them

Seat provisioned, no Moonlight client connected, seat session 14, console session 1:

seat log (session 14)
  whoami      : HOST\SeatAccount
  elevated    : False
  windowsta   : WinSta0
  my desktop  : Default
  input desk  : Default
  on input?   : True
  target=200,150  ... SetCursorPos ok=True err=- pos=200,150 | SendInput sent=1 err=- pos=200,150
  ... all five points, both calls, every one landed
  VERDICT     : moved 5/5 -> PROBE VALID

console watcher (session 1)
  selftest  : PASS - this watcher does detect console cursor movement
  result    : 320 samples, 0 changes, selftest=PASS

So on this host the seat cursor demonstrably moved five times, by both mechanisms, from a
non-elevated process that was already on the input desktop — and the console cursor never
moved. That is the negative your run was meant to be compared against, and now both ends of it are
self-checked.

qwinsta here while the probe ran, for comparison with yours:

>console    <console user>   1   Active
 rdp-tcp#0  SeatAccount     14  Active

The seat session is Active. If yours shows Disc, or the probe logs on input? : False, that
alone would explain set=False — and it would also mean the keepalive isn't doing its job on your
host, which is worth chasing on its own.

Sorry for the wasted run. Six rounds in, the one thing I don't want to do is hand you a seventh test
that can't fail.

[Lepipassier]

Here are the full logs and outputs from the updated run:

Console Watcher Output:

sessionId : 1
start : 1145,572
selftest : PASS - this watcher does detect console cursor movement
watching : 20s - seat probe started...
16:10:31.567 MOVED 1149,576 -> 1145,572
result : 255 samples, 1 changes, selftest=PASS
(Note: The 1 change recorded was the selftest restoring the cursor position at start).

qwinsta & mstsc Output:

SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc

console Mathieu 1 Active
rdp-tcp#0 LockAll 2 Active
rdp-tcp 65536 Listen

Id SessionId StartTime

---

22448 1 21/08/2026 16:08:17
C:\ProgramData\MultiSeat\seat-cursor.log:

16:10:32.735 ---- start ----
16:10:32.797 whoami : lepipassier\lockall
16:10:32.804 sessionId : 2
16:10:32.809 elevated : False
16:10:32.820 windowsta : WinSta0
16:10:32.821 my desktop : Default
16:10:32.821 input desk : Default
16:10:32.823 on input? : True
16:10:32.825 virtualdesk : origin=0,0 size=1920x1080
16:10:33.368 target=200,150 before=960,540 | SetCursorPos ok=False err=203 pos=960,540 | SendInput sent=1 err=- pos=960,540
16:10:35.400 target=1500,150 before=960,540 | SetCursorPos ok=False err=0 pos=960,540 | SendInput sent=1 err=- pos=960,540
16:10:37.438 target=900,800 before=960,540 | SetCursorPos ok=False err=0 pos=960,540 | SendInput sent=1 err=- pos=960,540
16:10:39.478 target=200,900 before=960,540 | SetCursorPos ok=False err=0 pos=960,540 | SendInput sent=1 err=- pos=960,540
16:10:41.484 target=1500,900 before=960,540 | SetCursorPos ok=False err=0 pos=960,540 | SendInput sent=1 err=- pos=960,540
16:10:42.996 VERDICT : moved 0/5 -> PROBE INVALID. The seat cursor never moved, so
16:10:42.997 VERDICT : a still console cursor proves NOTHING. Do not draw a conclusion from this run.
16:10:42.997 ---- end ----
Key Findings:
The seat session is Active (rdp-tcp#0 in qwinsta), and mstsc is running on session 1.

The process is on WinSta0\Default and matches input desk.

SetCursorPos fails with err=203.

SendInput reports success (sent=1 err=-), but the cursor coordinates do not actually update (pos=960,540 stays locked at screen center) while no active streaming capture pipeline is attached to the RDP session.