Repository navigation
BaseContainer v1.0.1: ~28 s before first output with UI enabled; disabling UI is fast but Node exits 0xC0000142 #1629
Description
Summary
We are evaluating the published MXC 1.0.1 runtime with ProcessContainer/BaseContainer on Windows 11 25H2 (build 26200, UBR 9711). Trivial commands consistently take about 28 seconds with ui.disable:false. Setting only ui.disable:true makes cmd and a small native executable much faster, but Node fails to initialize. We have not located the underlying wait or confirmed its cause.
Possibly related: #1465 (USER32-importing workloads failing with 0xC0000142 under BaseContainer from session 0). Our caller runs under the logged-on interactive user (session ID not recorded); there Node does initialize with ui.disable:false, but only after ~28 s.
Configuration and observations
- BaseContainer only,
fallback.allowDaclMutation:false; no AppContainer fallback. - Egress, ingress and host loopback denied; no proxy or network grants.
- Telemetry disabled; no audit, Learning Mode, captureDenials, elevation or host preparation changes.
- Explicit synthetic profile/temp/cache paths;
inheritDefaultEnv:false; 80-second process timeout. ui.clipboard:"none",ui.injection:false;processContainer.uiusesisolation:"container",desktopSystemControl:false,systemSettings:"none",ime:false.- Node 26.12.1. Profiles/caches were reused for warm repetitions. Runs were serial; no other test suite was running concurrently.
Times exclude harness preparation and include native executor launch through close:
| Workload | ui.disable:false | ui.disable:true |
|---|---|---|
| cmd /d /c echo marker, n=3 each | median 28.258 s, range 28.247–28.271 | median 0.192 s, range 0.191–1.191; exit 0, marker |
| Small native program, n=1 each | 28.243 s | 2.223 s; exit 0, marker |
| node -e printing a marker, n=1 each | 28.811 s; exit 0, marker | 0.277 s; 0xC0000142, no marker |
A true→false→true sequence reproduced the cmd difference. The fast Node failure is not a performance improvement. Earlier phase measurements found process creation recorded by Windows in roughly 0.1–1.1 s; the first JavaScript marker arrived about 28.2 s later, with process.uptime() around 22–24 ms. We did not trace the first machine instruction, and do not infer the precise blocked API from these timestamps.
Setting MXC_DIAG_CONSOLE to 0 rather than leaving it absent, removing COMSPEC or PATHEXT, reducing the explicit environment, and adding empty egress allow/deny lists while retaining deny-by-default did not remove the delay. No security setting was relaxed.
Source inspection / questions
In the v1.0.1 PSEC builder, the current UI restrictions resolve to the same mask as disable:true, while disallow_win32k_system_calls differs. The BaseContainer runner creates the child suspended, assigns its job, then resumes it. We did not find an explicit 28-second wait in that success path.
- Is this a known initialization issue for BaseContainer/PSEC with Win32k available on this Windows build?
- Is there a supported way to provide the UI initialization a console program needs while preserving the current restrictions on external UI objects, clipboard, input, global atoms and desktop control?
- Which supported diagnostics would distinguish a Windows loader/UI initialization wait from PSEC/process creation, without enabling permissive audit or changing host security?
We are not requesting weaker restrictions. This report has no production credentials or personal paths; paths and markers can be supplied as a small synthetic reproduction if useful. No provider qualification is claimed.
Activity