Stand: Oktober 2025
In den letzten Wochen häufen sich Fälle, bei denen Windows Server 2025 nach einem regulären Neustart plötzlich lokale Anwendungen nicht mehr starten kann.
Typische Symptome:
- Dienste laufen laut GUI, aber Programme melden „keine Verbindung zum Server“
- localhost lässt sich pingen, doch Anwendungen verhalten sich, als wäre das Netzwerk tot
- Monitoring-Agenten wie NinjaRMM oder Docker Desktop melden Fehler wie
QLocalSocket::connectToServer: Invalid name
Was nach einem simplen „Verbindungsproblem“ aussieht, hat in Wahrheit tiefere Ursachen im lokalen Kommunikationssystem (IPC) von Windows.
In diesem Beitrag erklären wir, was hinter dem Fehler steckt, wie man ihn behebt und wie man ihn in Zukunft vermeidet.
Was passiert hier eigentlich?
Lokale Kommunikation ≠ Netzwerk
Auch wenn viele Programme den Begriff „localhost“ verwenden, bedeutet das nicht automatisch TCP/IP.
Oft kommunizieren Windows-Dienste rein lokal im Betriebssystem, z. B. über:
|
Mechanismus |
Zweck |
Beispiel |
|---|---|---|
|
Named Pipes (\\.\pipe\...) |
Klassischer Kanal für lokale Prozesskommunikation |
SQL Server, Veeam, Druckspooler |
|
Loopback (127.0.0.1 / ::1) |
Lokaler TCP-Stack |
IIS, Web-APIs, Monitoring-Agenten |
|
AF_UNIX (Unix Domain Sockets) |
moderner Socket-Typ, schnell und sicher |
NinjaRMM, Docker, Qt-basierte Apps |
Diese Kommunikationswege nennt man Inter-Process Communication (IPC).
Sie laufen vollständig innerhalb von Windows und werden von einer zentralen Komponente verwaltet – dem Winsock-Subsystem.
Der technische Hintergrund: Winsock & AF_UNIX
Winsock
Winsock (Windows Sockets) ist die API-Schicht, die Anwendungen mit den Netzwerkprotokollen verbindet.
In der Registry speichert Windows eine Art Protokollkatalog, in dem steht:
- welche DLLs für TCP/IP, IPv6, Bluetooth oder AF_UNIX zuständig sind,
- und in welcher Reihenfolge sie geladen werden.
Wenn dieser Katalog beschädigt ist oder beim Start nicht korrekt initialisiert wird,
kann Windows keine neuen lokalen Verbindungen (Sockets) anlegen –
selbst wenn Ping, DNS und das eigentliche Netzwerk fehlerfrei funktionieren.
AF_UNIX auf Windows
Seit Windows 10 1809 und Windows Server 2019 unterstützt Microsoft nativ den Linux-typischen Socket-Typ AF_UNIX.
Viele moderne Anwendungen (z. B. NinjaRMM, Docker, PostgreSQL, Node.js, Qt-Apps) nutzen ihn,
um lokale Verbindungen schneller und sicherer zu gestalten.
Problem:
Bei bestimmten Builds von Windows Server 2025 wird der AF_UNIX-Namespace (\BaseNamedObjects) zu früh oder fehlerhaft initialisiert,
wenn Dienste direkt beim Boot starten.
Das führt dazu, dass Programme beim Zugriff auf localhost oder \\.\pipe\<Name> scheitern, obwohl der Dienst eigentlich läuft.
Typische Symptome im Log
Beispiel aus einem betroffenen System (NinjaRMM-Agent):
Not connected. Trying to connect
waitForConnect FAIL! QLocalSocket::UnconnectedState QLocalSocket::ServerNotFoundError
Das bedeutet:
Die Anwendung versucht, eine lokale Verbindung zu öffnen,
findet aber keinen gültigen Kommunikationskanal („Invalid name“).
Das ist kein DNS- oder Firewallproblem – sondern ein Defekt in der lokalen Socket-Schicht.
Die Lösung: Winsock-Reset
1. Winsock neu initialisieren
netsh winsock reset
Das setzt den Winsock-Katalog zurück und registriert alle Protokolle (TCP/IP, IPv6, AF_UNIX, Named Pipes) neu.
2. Optional: IP-Stack nicht mit zurücksetzen
netsh int ip reset
Davon ist abzuraten, wenn der Server statische IP-Adressen verwendet!
Dieser Befehl setzt sämtliche IP-Parameter zurück (auch Gateway, DNS, VLAN-Bindings).
Danach hat der Server keine IP mehr – wie bei vielen Betroffenen beobachtet.
3. Neustart des Server/Client
4. Prüfen des Firewall Profil (bei AD Betrieb)
Nach dem Neustart sicherstellen, dass das Netzwerkprofil nicht „Public“,
sondern „DomainAuthenticated“ lautet:
Get-NetConnectionProfile
Alternativ auf Domain Authenticated ändern:
Set-NetConnectionProfile -NetworkCategory DomainAuthenticated
Ein bekannter Bug in Server 2025 bewirkt, dass das Profil nach Boot fälschlich auf „Public“ springt,
was lokale Loopback-Kommunikation blockieren kann.
Warum das funktioniert
netsh winsock reset löscht die fehlerhaften Registry-Einträge unter:
HKLM\SYSTEM\CurrentControlSet\Services\WinSock
HKLM\SYSTEM\CurrentControlSet\Services\WinSock2
und ersetzt sie durch Standardwerte aus mswsock.dll.
Beim nächsten Start wird das Socket-Subsystem korrekt neu initialisiert –
der lokale Namespace steht wieder zur Verfügung,
und Dienste wie NinjaRMM oder Docker funktionieren wieder.
Wie finde ich heraus, welche Dienste Winsock/AF_UNIXverwenden?
Wenn nach einem Neustart Dienste scheinbar laufen, Anwendungen aber QLocalSocket::ServerNotFoundError oder „keine Verbindung zum Server“ melden, solltest du zielgerichtet prüfen, welche Dienste lokale IPC (Named Pipes / AF_UNIX) verwenden. So findest du die relevanten Kandidaten:
Schnellcheck: Prozesse mit geladenen Winsock-/AF_UNIX-Modulen
Führe das folgende PowerShell-Kommando als Administrator aus — es zeigt Prozesse, die ws2_32.dll, mswsock.dll oder afunix.dll geladen haben (gute Indikatoren für lokale Socket-/IPC-Nutzung):
# Liste typischer Windows-Systemprozesse, die ignoriert werden sollen
$ignoreList = @(
"svchost", "system", "idle", "smss", "csrss", "wininit", "winlogon",
"services", "lsass", "fontdrvhost", "dwm", "spoolsv", "conhost",
"explorer", "RuntimeBroker", "SearchIndexer", "audiodg", "taskhostw",
"ShellExperienceHost", "StartMenuExperienceHost", "SearchApp", "WUDFHost"
)
# Prüfen, welche Prozesse Winsock-/AF_UNIX-Module geladen haben
$results = Get-Process | Where-Object { $ignoreList -notcontains $_.ProcessName } | ForEach-Object {
$p = $_
try {
$mods = $p.Modules | Where-Object { $_.ModuleName -match 'mswsock|afunix|ws2_32' }
if ($mods) {
[PSCustomObject]@{
Process = $p.ProcessName
PID = $p.Id
Modules = ($mods.ModuleName -join ', ')
Path = $p.Path
}
}
} catch { } # Ignoriere Zugriffsfehler (z. B. Systemprozesse)
}
# Ausgabe formatiert
$results | Sort-Object Process | Format-Table -AutoSize
# Optional: Ergebnisse als CSV speichern
# $timestamp = (Get-Date).ToString("yyyy-MM-dd_HH-mm")
# $results | Export-Csv -Path #"C:\Temp\afunix_winsock_processes_$timestamp.csv" -NoTypeInformation
Möglicher Workaround: betroffene Dienste auf „verzögerten Start“ setzen
Ein risikoarmer Workaround ist, betroffene Dienste nicht sofort beim Boot, sondern verzögert starten zu lassen. Dadurch hat Windows mehr Zeit, Winsock, LSA, Named-Pipe-Namespace sauber zu initialisieren. Dies hat bei uns in der Praxis allerdings nicht immer funktioniert.
Ausnahme aus der Praxis: Warum der Server Manager trotzdem funktionierte
Bei der Fehlersuche in einem betroffenen System zeigte sich ein interessantes Verhalten:
Während mehrere Anwendungen und Dienste nach einem Neustart keine Verbindung zu „localhost“ herstellen konnten,
ließ sich der Windows Server Manager weiterhin öffnen – allerdings erst nach längerer Ladezeit.
Hintergrund
Dieses Verhalten liegt daran, dass der Server Manager im Gegensatz zu vielen anderen Programmen mehrere Kommunikationspfade nutzt.
Normalerweise kommuniziert er lokal über:
- LRPC (Local RPC) und
- Named Pipes
Diese Mechanismen sind sehr schnell, funktionieren aber nur, wenn der lokale IPC-Stack (Winsock, AF_UNIX, Named Pipes) vollständig initialisiert ist.
Wenn dieser beim Start fehlerhaft ist – wie es bei dem Winsock-/AF_UNIX-Problem vorkommt –
wartet der Server Manager zunächst vergeblich auf eine Antwort und wechselt nach einem internen Timeout automatisch auf eine Fallback-Verbindung über TCP/IP.
Konkret bedeutet das:
Er verbindet sich über WinRM (Windows Remote Management) mit localhost:5985,
also quasi „remote mit sich selbst“.
Damit kann er weiterhin kommunizieren, auch wenn der lokale Socket-Namespace noch nicht verfügbar ist.
Fazit
Seit Windows Server 2019 unterstützt Microsoft neben klassischen Named Pipes auch AF_UNIX-Sockets als Teil des Winsock-Stacks.
Diese Funktion wurde in Windows Server 2025 weiter stabilisiert und wird inzwischen von immer mehr Anwendungen standardmäßig genutzt.
Dennoch können in der aktuellen Build 26100.x unter bestimmten Umständen Initialisierungsverzögerungen nach Neustarts auftreten, wodurch lokale Socket-Verbindungen temporär fehlschlagen.
Ein einfacher Winsock-Reset behebt die Ursache in den meisten Fällen zuverlässig und stellt die lokale Kommunikation sofort wieder her.
Als langfristiger Workaround empfiehlt es sich, die betroffenen Dienste verzögert starten zu lassen, damit der Winsock-Stack und die lokalen IPC-Komponenten (AF_UNIX, Named Pipes) vollständig initialisiert sind, bevor die Anwendungen ihre Verbindung aufbauen.
Über Aegis Core
Aegis Core ist ein IT-Security- und MSP-Dienstleister, spezialisiert auf Windows-Server-Umgebungen, Netzwerksicherheit und moderne IT-Automatisierung. Wir dokumentieren hier regelmäßig reale Probleme aus dem Praxisalltag und ihre Lösungen.