Entwickler-Ecke

Programmierwerkzeuge - Portblockade bei XAMPP nach Windows-Update


ub60 - Fr 16.02.18 21:08
Titel: Portblockade bei XAMPP nach Windows-Update
Hallo miteinander,

ich habe gestern auf Arbeit einen länger nicht mehr benutzten Rechner mit Windows-Updates versorgt, und es waren 26 Updates aufgelaufen. Nach Update 12 (soweit alles i.O.) verlangte das Update (ich glaube, es war bei Office-Updates) einige dotNET-3.5-Funktionen. Nach einiger Recherche im Internet habe ich dann folgende Einstellungen gefunden (siehe Bild), die man ändern sollte.

xampp1

Nach diesen Änderungen funktionierten alle weiteren Updates.
Soweit, sogut. Als ich allerdings heute XAMPP startete, lief dort der Apache-Server nicht mehr an und ein bereits vom System benutzter Port wurde gemeldet.

Nun bin ich mir nicht sicher, was eigentlich passiert ist. Habe ich mit meinen 2 Häkchen selbst irgend einen Server auf Port 80 (?) aktiviert oder hat mit Microsoft bei der Installation so was wie den IIS untergeschoben?

Für Hinweise wäre ich sehr dankbar, kann es jedoch leider erst an Montag ausprobieren.

ub60


Christian S. - Fr 16.02.18 23:47

Hallo,

im XAMPP Control Panel kann man recht bequem netstat ausführen und sich übersichtlich die Ergebnisse anzeigen lassen. Kannst Du da sehen, wer auf Port 80 sitzt? Bei mir drängelt sich Skype da zum Beispiel ganz gerne mal rein, vielleicht wurde das mit Office installiert?

Grüße
Christian

P.S.: Manchmal ist es auch Port 443, der belegt ist.


ub60 - Sa 17.02.18 15:58

Danke für die Antwort, leider kann ich wegen der Ports erst am Montag wieder nachsehen. Bei Port 80 stand auf alle Fälle sehr aussagekräftig "System" da.
Mich interessiert vor allen Dingen auch, ob das Setzen der 2 Häkchen in dem oben gezeigten Menü das Problem verursacht haben könnte. Ein einfaches Entfernen der Häkchen hat auf alle Fälle nichts gebracht.


ub60 - Mo 19.02.18 23:47

Kleiner Zwischenbericht:


Ich habe jetzt einfach den Port 80 des Apache auf Port 81 gelegt, so dass der Server wieder läuft. Lieber wäre mir allerdings, herauszufinden, welches Programm meinen Port 80 blockiert und wie ich ihn wieder frei bekomme. Eventuell hat ja noch jemand eine Idee...

ub60


Narses - Di 20.02.18 00:43

Moin!

Ich habe mir mal den Screenshot angesehen und einfach mal nach den Wörtern des ersten eingerückten Punktes gesucht, da landet man bei der WCF-Doku von MS. Da steht zwar, dass man das wohl mit IIS macht oder machen kann, es soll aber wohl auch einen embedded service endpoint geben - als wohl einen http-Server. :nixweiss:

Ich würde einfach mal einen telnet-Connect auf den Port machen und mal ein bischen was tippen, mal sehen, was zurück kommt. :lupe: :idea:

Was auch mal interessant wäre ist, welches Binary mit dem listening port verknüpft ist (netstat -b). :suspect:

cu
Narses


jaenicke - Mi 21.02.18 07:38

Ich rufe da immer netstat -abno > c:\temp\a.txt auf, das geht blitzschnell und es ist wirklich alles drin. Durch die Umleitung landet das dann in der angegebenen Datei und ich kann bequem nach dem Port suchen.


Ralf Jansen - Mi 21.02.18 22:57

Vermutlich wird bei dir der http.sys Dienst verwendet. Der taucht dann bei netstat auch als System auf was einem nur begrenzt weiterhilft.

Ein "netsh http show servicestate" könnte ein paar weitere Details liefern wer alles diesen Dienst nutzt. Zumindest solltest du dort die pid(s) der Prozesse finden wobei dann hoffentlich einer der Schuldige ist.


ub60 - Do 22.02.18 00:31

Danke für die guten Tipps. Hier erst mal wieder ein kleiner Zwischenbericht:


putty80

Die NETSH-Geschichte überschaue ich jetzt noch nicht ganz, das werde ich morgen mal probieren. Auch bin ich mir noch nicht so ganz klar, welcher Dienst denn nun den Server "anbietet". Einen IIS-Dienst, den ich vermutet hätte, gibt es auf alle Fälle nicht.

ub60


ub60 - Do 22.02.18 23:34

Und noch einmal ein Update:

Ich habe die beiden dotNET-Dienste (siehe erstes Posting) wieder ausgeschaltet, aber der Port 80 blieb weiterhin blockiert.
Obwohl ich noch nicht so ganz genau weiß, was der netsh-Befehl so eigentlich tut, hat er mich ein ganzes Stück weitergebracht. Neben vielen anderen Sachen fand ich in der Ausgabe:


Quelltext
1:
2:
3:
4:
5:
6:
7:
  Protokollierungsinformationen:
    Protokollverzeichnis: C:\inetpub\logs\LogFiles\W3SVC1
    Protokollformat: 0
  Authentifizierungskonfiguration:
    Aktivierte Authentifikationsschemas:
  Anzahl von registrierten URLs: 1
  Registrierte URLs: HTTP://*:80/

Dieser Ordner ("C:\inetpub") war mir bisher gar nicht aufgefallen und spricht natürlich zweifelsfrei für den IIS. Nach etwas Googeln habe ich gefunden, dass man den Dienst über den "WWW-Publishingdienst" ausschalten kann.
Nun meine Folge-Fragen:

Die zweite Frage kann ich natürlich morgen ausprobieren, aber auf dem Rechner sind viiiiiieeeele Programme installiert und einiges findet man eventuell erst beim Anklicken bestimmter Programmteile.

ub60


Ralf Jansen - Fr 23.02.18 21:24

Zitat:
Hängen nach dem Update eventuell Programme vom IIS ab, die nach Abschalten des Dienstes nicht mehr funktionieren?


Was liegt den im inetpub Ordner? Wenn da was liegt lässt es möglicherweise Schlüsse zu wer das braucht.
Ansonsten solltest du mal in die Config schauen.

Die liegt in system32\inetsrv\config\applicationhost.config. Wenn es gar kein richtiger IIS (z.B. IIS Express) ist dann kann die auch woanders liegen wie z.B der Dokumente Ordner des aktuellen Users.
Da drin gibt es einen <sites> Knoten wo sich eigentlich alle Applikationen verewigen die was per http(s) veröffentlichen wollen.


ub60 - Sa 24.02.18 13:21

user profile iconRalf Jansen hat folgendes geschrieben Zum zitierten Posting springen:
Die liegt in system32\inetsrv\config\applicationhost.config.
Da drin gibt es einen <sites> Knoten wo sich eigentlich alle Applikationen verewigen die was per http(s) veröffentlichen wollen.

Ich habe die Datei in einem Unterordner von "C:\inetpub" gefunden. Der Sites-Knoten sagt mir nicht so wirklich viel:


Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
<sites>
    <site name="Default Web Site" id="1">
        <application path="/">
            <virtualDirectory path="/" physicalPath="%SystemDrive%\inetpub\wwwroot" />
        </application>
    </site>
    <siteDefaults>
        <logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" />
        <traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" />
    </siteDefaults>
    <applicationDefaults applicationPool="DefaultAppPool" />
    <virtualDirectoryDefaults allowSubDirConfig="true" />
</sites>

Im "wwwroot"-Ordner liegt nur eine HTML-Datei mit einem vielsagenden Bild:

welcome

Diese Datei verlinkt auf "http://go.microsoft.com/fwlink/?linkid=66138&clcid=0x409".
Kann es sein, dass mir MS hier nur eine Produkt-Werbung untergeschoben hat? Das wäre ja ein starkes Stück!

ub60


Th69 - Sa 24.02.18 14:58

Auf dem Bild in deinem ersten Beitrag sind ja die Internetinformationsdienste (IIS) [https://msdn.microsoft.com/de-de/library/ms181052(v=vs.80).aspx] (teilweise) aktiviert. Schau mal in dessen Unterpunkte.
Vllt. werden diese ja bei Aktivieren der "WCF HTTP Aktivation" ja automatisch mit aktiviert?!

Finde ich aber eigenartig, daß ein Windows (bzw. Office) Update diese benötigt.


ub60 - Mo 26.02.18 17:46

user profile iconTh69 hat folgendes geschrieben Zum zitierten Posting springen:
Auf dem Bild in deinem ersten Beitrag sind ja die Internetinformationsdienste (IIS) [https://msdn.microsoft.com/de-de/library/ms181052(v=vs.80).aspx] (teilweise) aktiviert. Schau mal in dessen Unterpunkte.
Vllt. werden diese ja bei Aktivieren der "WCF HTTP Aktivation" ja automatisch mit aktiviert?!

Du hattest recht. Beim Aktivieren der "WCF HTTP Aktivation" werden (ohne Nachfrage) bei den "IIS" die beiden Punkte ".Net-Erweiterbarkeit" und "Anforderungsfilterung" mit aktiviert. Sobald ich diese beiden deaktiviere (sie sind voneinander abhängig), wird auch der Port 80 wieder frei!

IIS2

user profile iconTh69 hat folgendes geschrieben Zum zitierten Posting springen:
Finde ich aber eigenartig, daß ein Windows (bzw. Office) Update diese benötigt.

Eigentlich war mir das auch sehr suspekt, aber es scheint ja so zu sein ...

Wenn ich nun noch wüsste, was über den Port 80 abläuft, wäre mir etwas wohler, aber die Unterordner von "C:\inetpub" sind im Wesentlichen leer.

ub60