What causes "INetworkConnection.GetNetwork: %s" in slackhq/nebula?

Ensure Network List Service (netprofm) is running and stable before tunnel startup

INetworkConnection.GetNetwork: %s

Error message

INetworkConnection.GetNetwork: %s

What it means

This error wraps a failed HRESULT from INetworkConnection::GetNetwork, which retrieves the INetwork object for a connection during Windows network category detection. A failing HRESULT indicates the COM call into Network List Manager failed (service state, stale pointer, or COM apartment issues).

Source

Thrown at overlay/network_category_windows.go:199

func (c *iNetworkConnection) GetAdapterId() (windows.GUID, error) {
	var g windows.GUID
	r1, _, _ := syscall.SyscallN(c.Vtbl.GetAdapterId,
		uintptr(unsafe.Pointer(c)), uintptr(unsafe.Pointer(&g)),
	)
	if hr := hresult(r1); hr.failed() {
		return windows.GUID{}, fmt.Errorf("INetworkConnection.GetAdapterId: %s", hr)
	}
	return g, nil
}

func (c *iNetworkConnection) GetNetwork() (*iNetwork, error) {
	var net *iNetwork
	r1, _, _ := syscall.SyscallN(c.Vtbl.GetNetwork,
		uintptr(unsafe.Pointer(c)), uintptr(unsafe.Pointer(&net)),
	)
	if hr := hresult(r1); hr.failed() {
		return nil, fmt.Errorf("INetworkConnection.GetNetwork: %s", hr)
	}
	return net, nil
}

type iNetworkVtbl struct {
	iDispatchVtbl
	GetName                    uintptr
	SetName                    uintptr
	GetDescription             uintptr
	SetDescription             uintptr
	GetNetworkId               uintptr
	GetDomainType              uintptr
	GetNetworkConnections      uintptr
	GetTimeCreatedAndConnected uintptr
	IsConnectedToInternet      uintptr
	IsConnected                uintptr
	GetConnectivity            uintptr
	GetCategory                uintptr

View on GitHub (pinned to dd8f660c0a)

Solutions

Ensure Network List Service (netprofm) is running and stable before tunnel startup
Re-enumerate connections and retry with a fresh iNetworkConnection pointer
Keep COM usage on the initializing thread/apartment to avoid RPC_E_WRONG_THREAD style failures
Read the hresult in the message to pinpoint the COM failure and skip category detection non-fatally if classification is optional

Example fix

// before
net, err := conn.GetNetwork()
if err != nil { return err }
// after
net, err := conn.GetNetwork()
if err != nil {
    l.WithError(err).Warn("unable to get INetwork for connection; skipping category detection")
    return nil
}

Defensive patterns

Strategy: retry

Validate before calling

// verify the service is up before the COM chain
if err := nlmAvailable(); err != nil {
    return fmt.Errorf("skip classification: %w", err)
}

Type guard

func isGetNetworkError(err error) bool {
    return err != nil && strings.HasPrefix(err.Error(), "INetworkConnection.GetNetwork:")
}

Try / catch

net, err := conn.GetNetwork()
if err != nil {
    if isGetNetworkError(err) {
        // retry once with a fresh connection pointer
        if c2, rerr := refreshConnection(); rerr == nil {
            net, err = c2.GetNetwork()
        }
    }
    if err != nil { return nil } // best-effort
}

Prevention

Confirm netprofm stability before starting classification
Refresh COM pointers whenever the network profile changes
Use one thread for the whole GetNetworkConnections→Next→GetNetwork→GetCategory chain
Log hresults for post-mortem diagnosis

When it happens

Trigger: Calling GetNetwork() on an iNetworkConnection during tun setup's network classification when the NLM COM vtbl call returns a failing HRESULT.

Common situations: Network List Service restarting mid-scan; stale connection pointers after rapid adapter changes (common with VPN adapters coming up/down); COM threading violations; stripped or locked-down Windows environments.

Related errors

AI-assisted analysis of slackhq/nebula@dd8f660c0a (2026-09-03). Data as JSON: /api/errors/868aebff75d6e4bb. Report an issue: GitHub.