netebpfext: purge stale WFP state at init and fail loudly when it cannot

[D. Michael Agun (mikeagun)]

Follow-up to #5472, stacked on fix/netebpfext-wfp-delete-failed — that should merge first. Relates to #5486.

#5472 makes driver unload always complete when a WFP filter delete permanently fails. This handles the consequence: the filter that could not be deleted is still installed in WFP.

WFP management objects are not owned by the driver that created them, and this extension's engine sessions are non-dynamic, so closing the engine handle does not remove them. A surviving filter pins the callout, sub-layer and provider it references, their deletion at unload fails too, and the next FwpmProviderAdd fails with STATUS_FWP_ALREADY_EXISTS (0xC0220009). Confirmed on a test machine, with the service still reporting STATE: 4 RUNNING and zero WFP components registered.

The safety invariant

A stale filter's rawContext holds the address of a filter context that the previous driver instance freed. It is inert only because initialization fails at FwpmProviderAdd and never reaches FwpsCalloutRegister. Register a callout under a GUID a stale filter references, and WFP starts invoking classifyFn with a dangling pointer.

So: purge every stale filter, or refuse to start. A partial purge followed by a successful start is strictly worse than the current silent failure, which is why both changes below ship together.

Purge

_net_ebpf_ext_purge_stale_wfp_objects() runs after FwpmEngineOpen and before FwpmTransactionBegin, in its own transaction so that aborting the initialization transaction cannot roll it back. It deletes EBPF_WFP_PROVIDER-tagged objects in reverse dependency order: filters, callout objects, sub-layers, then the provider.

Running before any FwpsCalloutRegister is what makes it safe: with no callout function registered, WFP delivers no delete notification for the filters removed here, so the purge never touches a stale rawContext. Every *_NOT_FOUND result is success, so a clean boot is a handful of no-op calls.

If the sweep cannot be proven complete — any filter left undeleted, or an enumeration that did not drain — initialization fails.

Fail loudly

The result of net_ebpf_extension_initialize_wfp_components() is checked instead of discarded with (void). DriverEntry already calls _net_ebpf_ext_driver_uninitialize_objects() and returns the failing status, so the service start fails with a real error code.

Behaviour change: netebpfext now refuses to load when WFP initialization fails, instead of loading in a silently inert state. Its program-info providers are registered after this point, so on that path the network program types no longer appear in netsh ebpf show programs. That is the intended signal, but it is worth a careful look.

On #521: the TODO is kept and expanded rather than removed. That issue asks the driver to register for BFE service status before adding WFP objects, which is still unimplemented, and failing the start makes the gap more visible: a start attempted while BFE is unavailable now fails outright instead of quietly doing nothing. Reviewers may want to weigh whether #521 should land first.

Tracing teardown also moves out of _net_ebpf_ext_driver_uninitialize_objects() to its two call sites, so it happens after the final log statement rather than before it. The new failure path is the first to routinely reach that code, and it was discarding the exit trace for a failed start.

Testing

No new tests in this PR. The existing netebpfext_unit WFP lifecycle tests ([wfp_cleanup]) provide coverage: they strand undeletable filters across unload, so every subsequent WFP initialization exercises the purge, and the suite fails without it.

Dedicated purge tests — positive, negative (the safety invariant), and enumeration-not-drained — and real-hardware A/B validation are still to come. Draft until both land.

The highest-risk unverified assumption is that the WFP mock does not model enumType, so the driver's FWP_FILTER_ENUM_FULLY_CONTAINED plus GUID_NULL layerKey template is untested against real WFP. If that combination returns nothing on real hardware, the purge would be inert while CI stays green. That is the first thing hardware validation must check.

Dependency

Requires the usersim submodule bump. Depends on microsoft/usersim#325.

The submodule URL is temporarily pointed at a fork so that CI can build this pull request before that change merges. Both the URL and the commit must be moved back to microsoft/usersim, at the merged commit, before this merges.