slackhq/nebula · error

IEnumNetworkConnections.Next: %s

Error message

IEnumNetworkConnections.Next: %s

What it means

This error wraps a failed HRESULT from IEnumNetworkConnections::Next, which advances the COM enumerator of network connections. It occurs while iterating NLM connections during network category detection on Windows; a failing HRESULT indicates the enumerator became invalid or the COM infrastructure rejected the call. fetched==0 with a successful HRESULT is the normal end-of-enumeration case and returns nil, not this error.

Source

Thrown at overlay/network_category_windows.go:157

	Clone   uintptr
}

type iEnumNetworkConnections struct{ Vtbl *iEnumNetworkConnectionsVtbl }

func (e *iEnumNetworkConnections) Release() {
	syscall.SyscallN(e.Vtbl.Release, uintptr(unsafe.Pointer(e)))
}

// Next returns the next connection, or (nil, nil) at the end of the enumeration.
func (e *iEnumNetworkConnections) Next() (*iNetworkConnection, error) {
	var conn *iNetworkConnection
	var fetched uint32
	r1, _, _ := syscall.SyscallN(e.Vtbl.Next,
		uintptr(unsafe.Pointer(e)), 1,
		uintptr(unsafe.Pointer(&conn)), uintptr(unsafe.Pointer(&fetched)),
	)
	if hr := hresult(r1); hr.failed() {
		return nil, fmt.Errorf("IEnumNetworkConnections.Next: %s", hr)
	}
	if fetched == 0 {
		return nil, nil
	}
	return conn, nil
}

type iNetworkConnectionVtbl struct {
	iDispatchVtbl
	GetNetwork            uintptr
	IsConnectedToInternet uintptr
	IsConnected           uintptr
	GetConnectivity       uintptr
	GetConnectionId       uintptr
	GetAdapterId          uintptr
	GetDomainType         uintptr
}

View on GitHub (pinned to dd8f660c0a)

Solutions

  1. Perform enumeration on the same OS thread where COM was initialized and the enumerator was created (lock OS thread / pass the enumerator carefully across threads)
  2. Retry the scan after the network stack settles (e.g. netprofm restarting)
  3. Check the formatted hresult to identify the COM failure code and address it specifically
  4. Treat the failure as a warning and skip network-category classification rather than failing tunnel startup

Example fix

// before
conn, err := e.Next()
if err != nil { return err }
// after
conn, err := e.Next()
if err != nil {
    l.WithError(err).Warn("network connection enumeration failed; skipping category detection")
    return nil
}
Defensive patterns

Strategy: try-catch

Validate before calling

// ensure enumeration happens on the COM-initialized thread
runtime.LockOSThread()
defer runtime.UnlockOSThread()
if err := coInit(); err != nil { return err }
defer coUninit()

Type guard

func isEnumNextError(err error) bool {
    return err != nil && strings.HasPrefix(err.Error(), "IEnumNetworkConnections.Next:")
}

Try / catch

conn, err := enum.Next()
if err != nil {
    if isEnumNextError(err) {
        log.Warnf("enumerator failed mid-scan, aborting category detection: %v", err)
        return nil
    }
    return err
}

Prevention

When it happens

Trigger: Calling Next() on an iEnumNetworkConnections obtained from INetworkListManager.GetNetworkConnections when the underlying enumerator is stale/freed or the COM runtime returns a failure HRESULT mid-iteration.

Common situations: Enumerating after the NLM service went away mid-scan; COM threading violations (enumerator created on a different apartment/thread); system shutting down or network stack being restarted during tunnel setup.

Related errors

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