ASP.NET

Problembehandlung bei Anwendungen mithilfe von IIS-Protokollen

Eduardo Sanabria

Haben Sie jemals versucht, Anwendungsprobleme zu beheben oder eine Anwendung zu debuggen, ohne den Code schon einmal gesehen zu haben? Hatten Sie schon einmal mit einer fehlerhaften Anwendung zu tun, für die weder der Browser noch die Anwendung einen nützlichen Fehlercode bereitstellen konnte?

Ich bin beiden Szenarien oft begegnet, und es ist eine gute Idee, auf solche Eventualitäten vorbereitet zu sein. Ich werde in diesem Artikel hilfreiche Techniken vorstellen, mit denen Sie eine Problembehandlung bei Anwendungen oder Systemen unter IIS unabhängig von der Codeplattform durchführen können. Diese Techniken haben mir geholfen, Probleme mit Anwendungen und Websites in einer Vielzahl von Situationen zu beheben, vor allem auf anderen Geräten als PCs – ein Szenario, das immer mehr zur Norm wird. In einem jüngsten Fall konnte ich mithilfe dieser Techniken herausfinden, warum Videos auf Apple-Geräten nicht abgespielt werden, obwohl sie auf Windows-basierten Geräten perfekt dargestellt wurden.

Einige Überlegungen

Es gibt viele geeignete Techniken zum Debuggen von ASP.NET und anderen Webanwendungen, die unter IIS ausgeführt werden. Wenn der Browser selbst einen bestimmten Fehler oder eine Gruppe von Fehlern generiert, ist das oft ausreichend, um die Probleme zu beheben.

Was aber, wenn diese Informationen nicht genügen? In diesem Fall ist es von Vorteil, einige zusätzliche Techniken zu kennen. Die einfachste davon ist auch eine der schnellsten und bekanntesten – die Ausführung der Anwendung direkt auf dem Server. Die Server sind zwar manchmal nicht für diese Option konfiguriert, aber wenn Sie diese Möglichkeit nutzen können, stellt der Server im Allgemeinen nützlichere Debuginformationen bereit als ein externer Computer. Dieses Verhalten ist von Microsoft offenbar für Sicherheitszwecke integriert worden. Um noch mehr Daten in einem Browser des Servers anzuzeigen, deaktivieren Sie in Internet Explorer die Option „Kurze HTTP-Fehlermeldungen anzeigen“, die Sie unter „Internetoptionen“ | „Erweitert“ finden.

Manchmal benötigen Sie jedoch noch weitere Informationen, und in diesem Fall ist die Protokollierung von Bedeutung. Microsoft hat seine Server mit mächtigen Protokollierungsfähigkeiten ausgestattet, die jede Problembehandlung erheblich vereinfachen können – vorausgesetzt, dass Sie wissen, was Sie suchen müssen und wo diese Informationen zu finden sind.

Aktivieren der IIS-Protokollierung

Als Erstes aktivieren Sie die Windows-Protokollierung auf dem Server. Hierzu gibt es verschiedene Möglichkeiten. Die tatsächlichen Schritte können (manchmal sehr stark) variieren, je nachdem, welche Version von Windows Server ausgeführt wird.

Die genaue Beschreibung dieser Schritte oder ihrer Vor- und Nachteile würde den Rahmen dieses Artikels sprengen. Ich möchte hier nur darauf hinweisen, dass die Verwendung der Protokollierung zum Debuggen von Anwendungen nur dann sinnvoll ist, wenn sie aktiviert wird, bevor die jeweiligen Fehler auftreten. Viele weitere nützliche Informationen finden Sie in den beiden folgenden MSDN-Artikeln über Windows Server 2003 und 2012: „SO WIRD'S GEMACHT: Konfigurieren der Website-Protokollierung in der Windows Server 2003-Produktfamilie“ (bit.ly/cbS3xZ) und „Konfigurieren der Protokollierung in IIS“ (bit.ly/18vvSgT). Sollten diese Artikel nicht Ihren Anforderungen entsprechen – es wurden viele andere Onlineartikel über die Aktivierung der IIS-Protokollierung für andere Versionen von Windows Server veröffentlicht.

Ermitteln der richtigen ID-Nummer

Nachdem die Protokollierung aktiviert ist, müssen Sie in IIS die ID-Nummer der Website herausfinden, deren Fehler Sie beheben möchten. Dies ist entscheidend, da auf einem Server in der Regel mehr als eine Website gehostet wird, und der Versuch, den Protokollordner manuell zu finden, kann entmutigend enden. (Ich habe es auf einem Server mit 45 Websites versucht, und es war fast unmöglich.)

Öffnen Sie IIS-Manager, um alle gehosteten Websites anzuzeigen. In diesem Beispiel versuche ich herauszufinden, warum WebSite2 plötzlich nicht mehr oder nur zeitweise funktioniert.

Wie Sie in Abbildung 1 sehen können, ist „3“ die ID für WebSite2. Der nächste Schritt ist, den entsprechenden Protokollordner zu öffnen, der üblicherweise (aber nicht immer) im Ordner „Inetpub“ enthalten ist. Windows erstellt diesen Ordner in der Regel im Stammverzeichnis (C:) des Servers, aber in meinem Fall befindet sich der Inetpub-Ordner auf Laufwerk (D:). Die allgemein empfohlene Vorgehensweise ist, Code und Betriebssystem auf getrennten Laufwerken zu speichern, damit bei einem Ausfall ein einfacher Austausch möglich ist.

Abbildung 1: Ermitteln der ID-Nummer der Website

Windows weist allen Protokollierungsordnern den Namen „W3SVC#“ zu, wobei „#“ für die ID der angegebenen Website steht. Da die ID der zu bearbeitenden Website in diesem Fall 3 ist, sind die Protokolldateien in einem Ordner namens W3SVC3 enthalten, wie in Abbildung 2 dargestellt.

Abbildung 2: Öffnen des Protokolldateiordners

Durchsuchen der Dateien

Wenn Sie den richtigen Ordner öffnen, wird möglicherweise eine Vielzahl von Dateien angezeigt. IIS speichert normalerweise viele verschiedene Dateien, je nach Konfiguration des Serververlaufs oder des Zeitraums seit Aktivierung der Protokollierung. Fast immer steht die Datei, die Sie benötigen, am Ende der Liste, aber wenn Sie den genauen Zeitpunkt kennen, an dem der Fehler aufgetreten ist, können Sie die Datei auch anhand von Datum und Uhrzeit im Dateinamen ermitteln. Nachdem Sie die Datei ermittelt haben, öffnen Sie sie mit einem Text-Editor wie beispielsweise „Notepad.exe“.

Sie werden wahrscheinlich viele Daten in der Datei vorfinden. Auf den ersten Blick mögen die Informationen kryptisch und nutzlos erscheinen, aber mit ein wenig Mühe finden Sie viele Juwelen, die in diesen Daten versteckt sind. Ich werde einige der nützlichsten Datenelemente vorstellen, die bei der Protokollierung aufgezeichnet wurden.

IIS und Windows protokollieren jede HTTP-Anforderung in einer eigenen Zeile. Ein typische Zeile ist:

2013-08-28 00:01:12 128.128.128.20 GET /default.asp - 443 - 200.200.200.17 Mozilla/4.0+(compatible; +MSIE+8.0; +Windows+NT+6.1; +WOW64;+Trident/4.0;+SLCC2;+.NET+CLR+2.0.50727; +.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+InfoPath.3;+MS-RTC+LM+8; +.NET4.0C;+.NET4.0E; +.NET+CLR+1.1.4322) 200 0 0 15

Dies ist eine Zeile aus einem tatsächlichen IIS-Protokoll. Die Daten liegen in einem der „Standard“-Formate vor. Da diese Option jedoch vielfältig konfiguriert werden kann, ist nicht garantiert, dass Ihre Dateien genau wie in meinem Beispiel aussehen. Statt alle Daten zu behandeln, werde ich mich hier auf die Elemente konzentrieren, die zum Debuggen einer Anwendung am wichtigsten sind.

Das erste wichtige Element im Beispiel ist das Datum der Anforderung. Denken Sie immer daran, dass es sich dabei um das Serverdatum handelt. Da viele Webanwendungen weltweit über viele Server in verschiedenen Zeitzonen bereitgestellt werden, kann dieses Datum irreführend sein. Überzeugen Sie sich davon, dass es tatsächlich genau die Zeit angibt, zu der die Fehler aufgetreten sind. Viele Server verwenden die GMT-Zeit, aber Sie sollten das Format überprüfen.

Als Nächstes ist die IP-Adresse angegeben, auf die zugegriffen wurde. Es folgen der HTTP-Vorgangstyp (GET) und die jeweils angeforderte oder abgerufene Datei. In der folgenden Beispielzeile wird vom Code die Datei „default.asp“ aufgerufen:

128.128.128.20 GET /default.asp

Diese Informationen sind wertvoll, da bereits in diesem Ablaufstadium Fehler auftreten können. Beispielsweise könnten Sie erwarten, dass zu diesem Zeitpunkt eine andere Datei ausgeführt werden soll.

Der nächste Zeilenabschnitt enthält die IP-Adresse, von der die Anforderung stammt, sowie den Empfangsport:

443 - 200.200.200.17

Diese Informationen sind ebenfalls wichtig, da es manchmal notwendig ist, zu überprüfen, ob die Anforderung, für die Sie die Fehlerbeseitigung durchführen, tatsächlich aus einer bekannten Quelle stammt.

Wie Sie sehen, wird der tatsächlich verwendete Port auch angegeben. Diese scheinbar unwichtige Information ist wesentlich für die Suche nach Problemen. Beispielsweise könnte die Firewall nicht ordnungsgemäß konfiguriert sein. Auf diese Daten folgen viele Informationen, die sich meistens auf Versionen beziehen:

+MSIE+8.0; +Windows+NT+6.1;+WOW64;+Trident/4.0;+SLCC2; +.NET+CLR+2.0.50727; +.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729; +InfoPath.3;+MS-RTC+LM+8; +.NET4.0C

Zum Beispiel können Sie erkennen, ob der Browser 32 oder 64 Bit ausführt, welche CLR-Versionen verwendet werden (für diejenigen, die tief in das .NET-Universum eintauchen möchten), und welche .NET-Version auf dem Server installiert ist (in diesem Fall .NET 4 C).

Den Dingen auf den Grund gehen 

Bisher habe ich die relativ offensichtlichen Teile des Protokolldateieintrags vorgestellt. Am wichtigsten ist, dass Sie feststellen können, welcher Browser auf die HTTP-Anforderung antwortet. Manchmal genügt dies, da verschiedene Browser unterschiedliche Ergebnisse bewirken. Hier sind einige Teilzeichenfolgen, die zeigen, wie Firefox und Chrome in der Datei aussehen könnten:

;+rv:17.0)+Gecko/20100101+Firefox/17.0 404 0 2 109
+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/­28.0.1500.95+Safari/537.36 200 0 0 125

Es ist möglicherweise schwer zu erkennen, welche von mehreren HTTP-Anforderungen zu debuggen ist, weil sie alle ähnlich aussehen. An diesem Punkt kann ein Browserwechsel nützlich sein. Das Hinzufügen eines Eintrags für einen anderen (und unerwarteten) Browser wie Safari oder Opera kann es erleichtern, den fehlerhaften Eintrag zu finden und zu korrigieren.

Betrachten Sie schließlich die letzten vier Elemente der Zeile:

200 0 0 15

Die letzte Zahl (15) ist die Antwortzeit (in Millisekunden) für die HTTP-Anforderung. Dies ist eine sehr nützliche Information. Wenn Sie wissen, wie lange eine Anfrage verarbeitet wird, können Sie entscheiden, ob ein bestimmter Codeabschnitt, Webdienst oder Prozess innerhalb der gewünschten oder „normalen“ Zeitspanne ausgeführt wird.

Möglicherweise sind Sie überrascht, dass relativ einfache Schritte in einem Prozess unerwartet viel Bearbeitungszeit benötigen. In einem jüngsten Fall konnte sich eine Anwendung manchmal einloggen und manchmal nicht, ohne dass ein abfangbarer Browserfehler (bzw. überhaupt ein Fehler) aufgetreten ist. Es funktionierte einfach nicht. Nach Überprüfung der Antwortzeiten im Protokoll entdeckten die Entwickler die folgende Eigenschaft in der Datei „web.config“:

<add name="CacheProfile1" duration="30" />

Der Wert dieses Parameters, scheinbar harmlos auf 30 Sekunden festgelegt, war einfach zu groß. Nachdem er reduziert wurde, hat die Anwendung wie erwartet funktioniert.

Im Folgenden werde ich mich auf einen der wichtigsten Parameter der betrachteten Zeile (die hier zur Verdeutlichung noch einmal wiederholt wird) konzentrieren. Das erste Element (200) ist die aktuelle HTTP-Antwort von IIS.

200 0 0 15

 

Der HTTP-Antwortcode 200 bezeichnet eine erfolgreiche Ausführung. Oft werden Sie aber einen bekannten Fehlercode vorfinden, beispielsweise 404 für „Nicht gefunden“ oder 500 für „Interner Serverfehler“, womit Sie über genügend Informationen für die Problembehandlung verfügen. Die Liste der offiziellen HTTP-Statuscodes finden Sie unter bit.ly/17sGpwE.

Ich werde mich jetzt auf eine realen Fall beziehen, der mich dazu veranlasst hat, diesen Artikel zu veröffentlichen. Ich hatte mit einer Website zu tun, die auf PCs perfekt ausgeführt wurde, während auf iPad-Geräten das Videostreaming nicht funktionierte. Um alles noch schlimmer zu machen, gab es kein Fehlercode – das Video verweigerte einfach die Ausführung.

In solchen Fällen sind die Protokolle für eine Problembehandlung von unschätzbarem Wert. Beim Überprüfen der Protokolle konnte ich mich davon überzeugen, dass die HTTP-Anforderung von einem Safari-Browser kam (die Anforderung war dadurch eingegrenzt), und ich habe festgestellt, dass der Server einen 404-Fehler gemeldet hat. Diese Fehlermeldung war verwirrend und der Fehler selbst schien nicht plausibel zu sein, da die PC-Version der Website perfekt funktionierte.

Obwohl aus den Protokollen hervorging, dass das Objekt nicht gefunden wurde, wusste ich sehr gut, dass die Dateien vorhanden waren. Dies veranlasste mich, die Unterschiede zwischen iOS und Windows bei der Behandlung und Speicherung von Dateien zu untersuchen. Als ich den Quellcode untersuchte, mit dem das Video geladen wurde, entdeckte ich, dass der Pfad zu den Videodateien im Quellecode festgeschrieben war, in iOS-iPad-Geräten aber nicht vorhanden war. Das war der Grund für die 404-Meldung.

In diesem Fall ist von Bedeutung, dass alle Symptome auf andere Ursachen hinwiesen. Beispielsweise wird zur Lösung eines solchen Problems in der Regel geprüft, ob IIS nicht unterstützte Medientypen (Multipurpose Internet Mail Extensions, MIMEs) enthält. Hätte jedoch ein fehlender MIME-Typ das Problem verursacht, wäre der HTTP-Fehlercode 415 (Nicht unterstützter Medientyp) oder eine ähnliche Fehlermeldung vorhanden gewesen, aber die Protokolle haben einen solchen Eintrag nicht enthalten. Zur Lösung des Problems erwies sich das Debuggen mithilfe der IIS-Protokolle als entscheidend. Weil ich den eigentlichen Fehlercode ermitteln und untersuchen konnte und nicht der scheinbar offensichtlichen Ursache nachgegangen bin, konnte ich eine erhebliche Menge Zeit sparen. Erneut hatte das Verständnis der Protokolldateien die Lage gerettet.

Zusammenfassung

Protokolldateien können ein leistungsfähiges Hilfsmittel beim Debuggen von Anwendungen und der Behandlung von Anwendungsproblemen sein, auch in unklaren Situationen. Voraussetzung ist, dass Sie wissen, wonach Sie suchen müssen und was die Protokolldaten bedeuten. Die Untersuchung der Daten in den Protokollen ist eine der einfachsten, aber elegantesten und umfassendsten Methoden zum Lösen von Problemen.

Sie benötigen ein wenig Übung und sicherlich etwas Disziplin, aber sobald Sie mit den entsprechenden Techniken vertraut sind, werden Sie in der Lage sein, die meisten Anwendungs- und IIS-Probleme zu untersuchen und zu lösen. Ich habe diese Techniken erfolgreich eingesetzt, und Sie können das ebenfalls.

Eduardo Sanabria ist Service Technology Consultant IV bei HP Enterprise Services in El Paso, Texas. In seiner Funktion als Subject Matter Expert (SME) für .NET sorgt er für Qualitätsergebnisse in seinem aktuellen Projekt. Sanabria stellt Hewlett-Packard Co. seine mehr als 25-jährige Erfahrung in der Anwendungsentwicklung (von der Planung bis zur Auslieferung) zur Verfügung. Seine Spezialgebiete sind .NET, Datenbankanwendungen, Datenverarbeitung und Webentwicklung. Sie erreichen Sanabria unter EdSanabria@Yahoo.com.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Roger Hawkins (Hewlett-Packard)
Roger Hawkins ist Chief Technology Officer für alle Amerikaner der Firma Hewlett-Packard sowie Distinguished Technologist und Fellow der Firma. “