none
IIS erzeugt kein stdout.log und fehlgeschlagene Requests werden nicht protokolliert RRS feed

  • Frage

  • Hallo,

    eines vorneweg: Ich bin absoluter Anfänger, was IIS angeht. Ich habe einen .NET Core Webservice, den ich von .NET Core 2.0 auf .NET Core 3.1 portiert habe. Die Portierung war scheinbar auch erfolgreich, zumindest lässt sich die Startseite problemlos aufrufen. Wenn ich aber einen Webrequest an die REST API des Webservices schicke, bekomme ich einen Error 400 - Bad Request. Diesen Fehler würde ich gerne genauer untersuchen und habe daher in der web.config das stdout-Logging aktiviert. Das funktioniert auch auf einem vorkonfigurierten Server (Konfiguration durch Installation der SCCM Distribution- bzw. Management-Point Rolle, Server 2012 R2). Wenn ich den Webservice auf einem blanken Server mit Server 2019 einrichte, wird mir kein stdout-Log angelegt und auch die FailedRequests werden nicht protokolliert.

    Welche Einstellungen muss ich ändern, damit ich die entsprechenden Logs bekomme?

    Vielen Dank

    Update-Troubleshooter

    Freitag, 3. April 2020 05:39

Alle Antworten

  • Ggf. kommt dein Service noch gar nicht bis zum Log.
    Hierfür solltest du in Windows-Ereignissen mal nachsehen.
    Installierst du eine Debugversion werden sogar Funktionen und Zeilen-Nr. korrekt ausgegeben.
    Freitag, 3. April 2020 11:34
  • Guter Tipp, im Eventlog habe ich das hier gefunden:

    Could not start stdout file redirection to '.\logs\stdout' with application base 'C:\inetpub\ConfigMgrClientHealth\'. ios_base::failbit set: iostream stream error.

    Der User, in dessen Kontext der Application Pool läuft, hat aber Schreibrechte...

    Freitag, 3. April 2020 12:52
  • Es wird ein relativer Pfad ".\logs\stdout" angegeben.
    Wo das Arbeitsverzeichnis (Current Directory) des Prozesses ist kann ich natürlich nicht sagen:
    http://www.cplusplus.com/reference/ios/ios/fail/
    Freitag, 3. April 2020 13:05
  • Hab jetzt mal versucht, den Pfad fest in die web.config einzutragen. Bringt aber leider auch nix. Bzw. die Meldung von vorhin ist jetzt weg, dafür bekomme ich das hier:

    The Application Host Helper Service encountered an error trying to delete the history directory 'C:\inetpub\history\CFGHISTORY_0000000006'.  The directory will be skipped and ignored.  Note that the directory may still get deleted in the future if the service restarts.  The data field contains the error number.

    Freitag, 3. April 2020 13:20
  • Möglicher weise ebenso ein Berechtigungsproblem:
    https://docs.microsoft.com/en-us/iis/configuration/system.applicationhost/confighistory

    Bedenke, dass der IIS-Job ggf. über die Pool-Id (deines App-Pools) läuft und somit entsprechende Berechtigungen benötigt.

    Wobei ich mir sowas schenke und meine egenen Logs erstelle. Da weiß ich was ich tue;-).

    Freitag, 3. April 2020 13:47
  • Die Pool-ID hat entsprechende Rechte zum Schreiben. Trotzdem bekomme ich diesen Fehler und es werden nach wie vor keine Logs erzeugt.
    Freitag, 3. April 2020 13:56
  • Welche Logs erwartest du eigentlich?
    Solange dein Prozess nichts auf STDOUT ausgibt, wird da wohl auch nichts passieren;-), da alle Standard-Funktionsaufrufe i.d.R. nichts ausgeben und höchstens mal ein "Throw Exception" durchführen.
    STDOUT ist normalerweise ein "Console.Writeline()".

    https://docs.microsoft.com/de-de/dotnet/api/system.console.writeline?view=netframework-4.8

    Die andere Variante ist Trace:
    https://www.dotnetperls.com/trace

    Per Trace.WriteLine() kann schon mal die eine oder andere Ausgabe erfolgen. Du kannst natürlich auch selber Trace.WriteLine() aufrufen:
    https://docs.microsoft.com/de-de/dotnet/api/system.diagnostics.trace.writeline?view=netframework-4.8

    Zu deinem Fehler:
    https://kb.eventtracker.com/evtpass/evtPages/EventId_9009_Microsoft-Windows-IIS-APPHOSTSVC_66295.asp

    Möglicherweise hat dieser Service keine Berechtigung.

    Freitag, 3. April 2020 14:31