Interactive Action (Webhook) crashes Player — NullReferenceException in GetActions() before action-type dispatch — CMS 4.4.4 / Windows Player 4 R407.2

maa2026 · June 28, 2026, 11:26pm

Interactive Action (Webhook) crashes Player — `NullReferenceException` in `GetActions()` before action-type dispatch — CMS 4.4.4 / Windows Player 4 R407.2

Environment

CMS: 4.4.4
Windows Player: 4 R407.2
Display: single Windows mini-PC, EmbeddedServer bound to [::1]:9696 (IPv6 localhost only, verified via netstat)

Summary

Any Interactive Action triggered via Webhook causes the Player to accept the connection, then close it without writing an HTTP response. No layout change occurs. The same NullReferenceException appears regardless of action type, which indicates the failure happens before the action type is evaluated.

Steps to reproduce (minimal case, no external hardware)

Create a Layout WEIN_SPLASH (Code Identifier SPLASH), single text widget.
Create a second Layout WEIN_SLOT1 (Code Identifier WSLOT1), single text widget.
On WEIN_SPLASH, add one Interactive Action: type Navigate to Layout, trigger type Webhook, trigger code SLOT1, target via Layout Code WSLOT1.
Schedule WEIN_SPLASH to the display; confirm it is playing.
From the player machine itself, fire the webhook directly with curl — no scripts, no NFC hardware involved:
```
curl.exe -X POST "http://[::1]:9696/trigger?trigger=SLOT1" -v
```

Observed result

netstat confirms the EmbeddedServer is listening:

TCP    [::1]:9696    [::]:0    LISTENING    <pid>

curl output: connection established, Request completely sent off, then:
```
curl: (52) Empty reply from server
```
The player writes no HTTP response and performs no layout change.
Reproduced identically with action type Navigate to Widget as well as Navigate to Layout — i.e. the action type does not matter.
Reduced to a single layout, single widget, single action — crash still occurs, so it is unrelated to layout complexity or action count.
The same behaviour occurs whether triggered by Webhook or by a Touch/Click action (same code path).
Display status screen shows a watchdog loop alternating between “Too many active processes” and “No active processes” around the trigger.

Crash detail

The underlying exception is a NullReferenceException in MainWindow.GetActions(), called from HandleActionTrigger().

TODO before posting: paste the verbatim stack trace here as a code block if available — an exact trace is far more convincing to maintainers than a description.

<verbatim stack trace here>

Hypothesis

(Marked explicitly as a hypothesis — no access to the player source.)

Because the failure is identical across action types and occurs before any type-specific handling, it appears GetActions() collects all active actions before dispatch, and a null result (e.g. from _schedule.GetActions()) is iterated without a null check. A likely contributing factor: external triggers arriving while a schedule reload or layout transition is still settling.

If correct, two defensive measures would likely resolve it:

(a) a null check before iterating (return an empty collection rather than throwing), and
(b) a guard preventing HandleActionTrigger() from running while the schedule is mid-refresh.

This would not require touching the action-type dispatch logic.

Additional note

A community thread from 2024 appears to report the identical stack trace, suggesting this has been present for a considerable time. (Link omitted here; can provide on request.)

Impact

This blocks all Interactive Action workflows on this player, regardless of action type. Happy to test a patched build, provide full Audit-level player logs, or supply the minimal repro layout export.