Windows x64: native workerd test terminates when declaring an unused deny-all Network service, without sockets #8070

Summary

On the Windows environment below, a minimal native workerd test passes JavaScript and crypto assertions without an explicit Network service. Adding an unused Network service with a deny-all policy causes termination before the test marker appears.

This report describes an observed component boundary, not a confirmed workerd defect or established root cause. A Windows/host interaction remains possible.

Environment

• Windows 11, reported OS version 10.0.26300.0, x64.
• workerd npm package: 1.20260515.1.
• @cloudflare/workerd-windows-64: 1.20260515.1.
• Native version: workerd 2026-05-15.
• Installed alongside Miniflare 4.20260515.0, Wrangler 4.92.0, Node 24.19.0. The reproduction below invokes the native executable directly and does not execute Node or Miniflare.
• SSE4.2 and PCLMULQDQ reported supported.
• Directly imported CRT files MSVCP140.dll, MSVCP140_ATOMIC_WAIT.dll, VCRUNTIME140.dll, and VCRUNTIME140_1.dll are present, each version 14.51.36247.0. This is file metadata, not a trace of the modules actually loaded.

Native executable SHA-256:

74550de7abef9a2b86fa43491d57c7ecf6809e45b3f123222b2256b57a0839dc

Matching workerd.capnp SHA-256:

3aa1075fe206788d8f7e7dc4361b8bc3e396427607b681c12b84a8fb1330040a

Minimal reproduction

Use the pinned executable and matching schema. Put the following three files in a directory named repro under a project containing the matching node_modules.

repro/probe.mjs

// Native runtime initialization only: no listeners, bindings, network or data.
export default {
  async test() {
    if (1 + 1 !== 2) throw new Error('Native JavaScript smoke failed');
    const h = await crypto.subtle.digest('SHA-256', new Uint8Array([1, 2, 3]));
    if (h.byteLength !== 32) throw new Error('Native crypto smoke failed');
    console.log('OFFLINE_NATIVE_RUNTIME_SMOKE_PASSED');
  },
};

repro/without-network.capnp — passing control

using Workerd = import "/workerd/workerd.capnp";
const config :Workerd.Config = (
  services = [
    (name = "offline-native-smoke", worker = (
      modules = [(name = "smoke.mjs", esModule = embed "probe.mjs")],
      compatibilityDate = "2026-05-01"
    ))
  ],
  sockets = []
);

repro/with-network.capnp — failing case

using Workerd = import "/workerd/workerd.capnp";
const config :Workerd.Config = (
  services = [
    (name = "offline-native-smoke", worker = (
      modules = [(name = "smoke.mjs", esModule = embed "probe.mjs")],
      compatibilityDate = "2026-05-01"
    )),
    (name = "internet", network = (
      allow = [],
      deny = ["public", "private"]
    ))
  ],
  sockets = []
);

Commands

From the project directory, in PowerShell:

& .\node_modules\@cloudflare\workerd-windows-64\bin\workerd.exe test -I .\node_modules .\repro\without-network.capnp

& .\node_modules\@cloudflare\workerd-windows-64\bin\workerd.exe test -I .\node_modules .\repro\with-network.capnp

The worker bytes above are identical to the retained executed reproduction. Only schema import and embedded-file paths were adapted for this portable layout; those path adaptations were not executed again while preparing the report.

Expected behavior

Both configurations complete the assertions, print:

OFFLINE_NATIVE_RUNTIME_SMOKE_PASSED

and exit successfully. Declaring an unused, deny-all Network service should not abort initialization.

Observed behavior

Sanitized diagnostic line:

*** std::terminate() called with no exception

The isolation comparison used identical executable and input hashes. The execution request was admitted and completed; changing that executor isolation mode did not resolve the failure. This does not establish that every possible host restriction was absent.

An additional previously tested policy, allow = ["public"] with deny = ["public", "private"], also failed. No policy was relaxed.

Scope and limitations

• The configurations declare no sockets/listeners.
• The worker makes no network requests.
• There are no database bindings, SQL statements, credentials, or application data.
• A separate synthetic Miniflare D1 smoke failed during runtime startup before SQL execution; the native reproduction above removes Miniflare and database behavior from the case.
• No symbolized native stack or loaded-module trace has been collected. Raw address-only stacks are omitted.
• No matching fixed version or exact cause has been established.
• The failure has not been compared on another supported operating system. Success elsewhere would help isolate platform behavior but would not validate this Windows host.

Is this sufficient to identify a known Windows Network-service initialization issue in this build? If not, which narrowly scoped native diagnostic and matching symbols would be most useful to distinguish a runtime defect from a host/dependency interaction?