This document records the Windows-native coverage workflow that matches the
known-good win11 environment used for this repository.
It intentionally documents only what is implemented and validated in this repo. It does not claim generic MSVC/CI support that has not been exercised here.
Verified on 2026-03-28:
ctest --test-dir build --output-on-failure -j4:28/28passing onwin11- Windows C coverage on the latest clean
win11coverage build:- the bounded direct coverage executables pass:
test_win_service_guards.exe:198 passed, 0 failedtest_win_service_guards_extra.exe:93 passed, 0 failedtest_win_service_extra.exe:165 passed, 0 failed
- the remaining Windows C interop / stress subset then passes one-by-one under
ctest --timeout 60 - the raw
bash tests/run-coverage-c-windows.sh 90flow completed end to end - measured total coverage result:
93.2% - per-file:
netipc_service_win.c:90.2%netipc_named_pipe.c:95.4%netipc_win_shm.c:97.2%
- current status:
- measured Windows C remains above the Linux-matching per-file and total
90%gates - the aggregate Windows C script is trustworthy again on the validated
win11flow
- measured Windows C remains above the Linux-matching per-file and total
- latest ordinary Windows C service gains came from:
- NULL config default coverage for typed client/server init
- minimum response-buffer growth coverage
- deterministic client-side buffer and SHM-context allocation faults
- deterministic server-side SHM create and cache allocation faults
- typed hybrid malformed SHM reply coverage on the real
nipc_client_call_cgroups_snapshot()path - typed hybrid
LIMIT_EXCEEDED/UNSUPPORTEDresponse-status coverage
- latest ordinary Windows C transport gains came from:
- manual HYBRID mapping setup to reach the client-attach event-name overflow branch honestly
- deterministic HYBRID and BUSYWAIT receive timeout / disconnect tests
- client-side oversized-response
MSG_TOO_LARGEcoverage for WinSHM - second chunked round-trip coverage proving client receive-buffer reuse on the same session
- deterministic fake-server continuation-packet tests now covering the chunked receive error cluster in
netipc_named_pipe.c
- the bounded direct coverage executables pass:
bash tests/run-coverage-c-windows.sh 90:- script still configures and builds correctly
- the script now runs three bounded direct executables before the generic
ctestloop:build-windows-coverage-c/bin/test_win_service_guards.exebuild-windows-coverage-c/bin/test_win_service_guards_extra.exebuild-windows-coverage-c/bin/test_win_service_extra.exe
- script detail:
test_win_service_guards.exeandtest_win_service_guards_extra.exenow run undertimeout 120test_win_service_extra.exenow runs undertimeout 600- the generic Windows C subset no longer relies on
test_win_service_extrainside the unorderedctestloop - every remaining
ctestitem now uses--timeout 60
bash tests/run-coverage-go-windows.sh 90:- script prints valid coverage results on
win11 - total coverage result:
95.4% - selected key files:
service/cgroups/cache_windows.go:100.0%service/cgroups/client_windows.go:100.0%transport/windows/pipe.go:92.1%transport/windows/shm.go:94.2%
- current status:
- reported above the Linux-matching
90%target - Windows Go service/cache tests are now also wired into
ctest - latest public typed cgroups wrapper tests now cover:
Cache.Ready()Cache.Status()Client.Status()NewServerWithWorkers()
- removing the dead private
Handler.snapshotMaxItems()helper also eliminated a faketypes.godenominator from the Windows Go typed-service package - latest WinSHM service tests, direct raw WinSHM L2 tests, batch failure/recovery tests, and the listener shutdown fix materially raised both the Windows client paths and the Windows transport package
- malformed raw WinSHM request tests now also cover the real SHM server-side teardown / reconnect path
- the latest create / attach edge tests materially raised the remaining ordinary Windows Go transport file
- the remaining ordinary Windows Go work is now concentrated in low-level transport branches such as:
peekNamedPipeAvailableWaitReadable()SetPayloadLimits()- short write / zero-byte read / next-pipe-creation failures
- reported above the Linux-matching
- script prints valid coverage results on
bash tests/run-coverage-rust-windows.sh 90:- script works on
win11 - workflow:
cargo-llvm-covrustup component add llvm-tools-preview- Windows-native Rust L2/L3 unit tests
- Windows Rust interop ctests
- current threshold policy:
- total Windows Rust line coverage must stay above
90% - critical Windows runtime files must each stay above
90%line coverage:service\cgroups.rstransport\windows.rstransport\win_shm.rs
- total Windows Rust line coverage must stay above
- current measured result after excluding Rust bin / benchmark noise from the report:
service/cgroups.rs:92.74%line coveragetransport/windows.rs:94.74%line coveragetransport/win_shm.rs:95.76%line coverage- total line coverage:
92.08%
- current status:
- the old ignored Windows retry/shutdown test is gone
test_retry_on_failure_windowsnow runs in the normal Windows Rust suite- the stricter per-file runtime gate now passes on a fresh native
win11run - Phase 1 deterministic Win32 fault injection now covers forced failure and
recovery for:
CreateFileMappingWOpenFileMappingWMapViewOfFileCreateEventWOpenEventW
- the current
transport/win_shm.rsresult is backed by native cleanup- sensitive fault tests, not only by ordinary happy-path / malformed-header coverage
- script works on
Brutal truth:
- Windows coverage measurement is real and useful now.
- Windows coverage parity is much closer, but not finished.
- Windows C is no longer below the Linux-matching
90%gate. - The old Windows C coverage-script instability was real.
- The current validated layout fixes it by keeping the early HYBRID / malformed-request guards in
test_win_service_guards.exeand the late dispatch / cache / drain / worker-limit cases intest_win_service_guards_extra.exe. - That means the current trustworthy Windows C baseline is the full script result above:
93.2%total, with every tracked file above90%. - The Windows Go script reliability issue is fixed.
- The recent Rust Windows coverage work materially raised
service/cgroups.rsandwin_shm.rs. - The recent Windows named-pipe transport tests materially raised
transport/windows.rs. - The current weakest critical Windows Rust runtime file is
service/cgroups.rs, and it is already above the per-file90%gate at92.74%. - The remaining Windows Go work is no longer a public typed-wrapper coverage problem.
- The remaining Windows Go work is now mostly:
- the tiny remaining low-level
pipe.gobranches:- short write
- zero-byte read
SetNamedPipeHandleStatefailure duringConnect()- defensive nil-map checks
Accept()/ next-pipe-creation failure paths
- any still-honest residual
transport/windows/shm.gogap after the create / attach edge tests
- the tiny remaining low-level
- Some malformed named-pipe response cases do not reach Go L2 coverage points because the Windows session layer rejects them first.
- Direct raw WinSHM tests now cover the Windows-only L2 branches that named pipes cannot reach honestly.
- One transient
test_protocol_rustfailure was observed once under parallelctest, but it did not reproduce on immediate isolated or full reruns. This is not a confirmed active blocker.
Script: tests/run-coverage-c-windows.sh
Measured Windows-specific C files:
src/libnetdata/netipc/src/service/netipc_service_win.csrc/libnetdata/netipc/src/transport/windows/netipc_named_pipe.csrc/libnetdata/netipc/src/transport/windows/netipc_win_shm.c
What it does:
- configures a fresh Windows coverage build with
NETIPC_COVERAGE=ON - builds with the native
win11MinGW64 toolchain and Ninja - runs the dedicated Windows C coverage-only guard executables
- runs the Windows coverage-focused C subset
- collects
gcovline coverage for the Windows C sources above - if
test_win_serviceis noisy underctest, direct executable validation on the same clean coverage build is the authoritative fallback for deciding whether the problem is harness noise or a runtime regression
Script: tests/run-coverage-go-windows.sh
Measured packages:
./pkg/netipc/protocol/./pkg/netipc/service/cgroups/./pkg/netipc/transport/windows/
What it does:
- runs the package tests natively on Windows
- merges the generated coverage profiles
- prints per-function and per-file coverage
- fails if no Windows transport coverage was collected
Script: tests/run-coverage-rust-windows.sh
Facts:
- Windows Rust code exists in:
src/crates/netipc/src/transport/windows.rssrc/crates/netipc/src/transport/win_shm.rssrc/crates/netipc/src/service/cgroups.rs- Linux coverage runs do not execute these Windows modules.
- The current validated Windows Rust workflow enforces:
- the same total
90%line threshold as Linux Rust coverage - plus per-file
90%line gates for the three critical Windows Rust runtime files above
- the same total
- It now produces meaningful Windows Rust service coverage on
win11. - It now also produces strong Windows named-pipe transport coverage on
win11. - There is no longer an ignored Windows Rust retry/shutdown caveat in the normal suite.
Use Rust 1.91 or newer from the native Windows Rust toolchain, the native Go toolchain, and MinGW64 GCC. Use the latest stable Rust release for normal validation.
Recommended environment:
windows_cargo_home="$(cygpath -u "$USERPROFILE")/.cargo"
export PATH="$windows_cargo_home/bin:/c/Program Files/Go/bin:/mingw64/bin:$PATH"
export MSYSTEM=MINGW64
export CC=/mingw64/bin/gcc
export CXX=/mingw64/bin/g++Sanity check:
type -a cargo rustc go gcc g++ cmake ninja gcov
rustc --version --verbose
cargo --versionExpected shape:
cargoandrustcfrom the native Windows Rustup installationgofrom/c/Program Files/Go/bingcc/g++/gcovfrom/mingw64/bin
This remains the authoritative Windows coverage / sign-off environment.
Before native runtime validation, compile every Rust target, including the Windows benchmark and fixtures:
cargo check --manifest-path src/crates/netipc/Cargo.toml \
--all-targets --all-features --lockedThe separate MSYS transition lane is:
bash tests/run-windows-msys-validation.shThat script validates the MSYS-built C path with targeted functional tests,
repeats test_win_shm, and runs bounded native-vs-MSYS benchmark
comparisons with explicit throughput floors per scenario. If a relative
throughput policy row fails, the failed label is rerun as a fresh paired
native+MSYS measurement before final failure; prior policy attempts are kept as
policy.attempt-N.csv / joined.attempt-N.csv. It is a compatibility lane, not
a replacement for the native MinGW64 coverage flow below.
bash tests/run-coverage-c-windows.shbash tests/run-coverage-go-windows.sh 90bash tests/run-coverage-rust-windows.sh 90bash tests/run-verifier-windows.shThe Windows code paths cannot be covered from Linux.
Reasons:
- Windows transport code depends on Win32 APIs
- Windows-only Go files are behind
//go:build windows - Rust Windows transport modules are behind
#[cfg(windows)]
Some remaining branches require extra infrastructure such as:
- allocation failure injection
- Win32 API fault injection
- timing/race orchestration
- resource exhaustion and handle-creation failures
Examples:
CreateNamedPipe/ConnectNamedPipefailure pathsCreateFileMapping/MapViewOfFilefailure paths- overlapped or wait-related timeout/error branches
- low-memory allocation failures in the Windows L2 layer
The repository now includes a first-class verifier entrypoint for the core Windows C executables:
tests/run-verifier-windows.sh
It enables:
- Application Verifier layers:
HandlesHeapsLocks
- full PageHeap via
gflags /p /enable ... /full
Default validated targets:
test_named_pipe.exetest_win_shm.exetest_win_service.exetest_win_service_extra.exe
This repository now has validated Windows C, Go, and Rust coverage entrypoints. Rust Windows coverage still needs:
- more deterministic OS-failure and low-resource validation
- verifier and long-runtime evidence beyond line coverage
Facts:
test_win_stressis wired into Windowsctest- the currently validated default scope is the repeated WinSHM lifecycle case
Reason:
- the managed-service shutdown stress cases exposed a separate Windows
investigation area and are intentionally not part of the default
ctestpath until that behavior is understood and stabilized
COVERAGE-EXCLUSIONS.md is the cross-platform explanation of lines that still
need special infrastructure or fault injection.
This document is narrower:
- how to measure Windows coverage here
- what Windows coverage is currently implemented
- what is still missing on Windows specifically