slackhq/nebula · error
INetworkConnection.GetNetwork
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).
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
- INetworkListManager.GetNetworkConnections
- IEnumNetworkConnections.Next
- INetwork.GetCategory
- INetwork.SetCategory
- INetworkConnection.GetAdapterId
AI-assisted analysis of slackhq/nebula@dd8f660c0a (2026-09-03).
Data as JSON: /api/errors/868aebff75d6e4bb.
Report an issue: GitHub.
Appendix: 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 uintptrView on GitHub (pinned to dd8f660c0a)