Fehlerursachen (Suche mit Debug&Trace)


Fehlerursachen (Suche mit Debug/Trace)

Warum? Mit dem folgendem Abschnitt kann ein weniger geübter Entwickler durch einen Administrator selbst zur Ursache geführt werden, ohne das sich der Administrator auch nur ein Stück Code ansehen muss.

Bei den folgendem handelt es sich nicht um das eigentliche Debuggen wo man sich direkt an den Prozess hängen kann, sondern eher um die
Interpretations vom Fehlern der .net Runtime. Zum richtigem Debuggen wären Admin Rechte notwendig oder aber der Kunde müsste mit seinem
Visual Studio unter dem gleichen User Arbeiten, wie der Worker Process. Beides ist nicht möglich. Kundenpräsenzen sind auch keine
Entwicklungsumgebungen, was wohl immer wieder vergessen wird. 

Eine kleine Exception Definition: 

Das Wort Exception wird im folgendem Abschnitt oft fallen, daher hier kurz erläutert. Eine Exception ist wörtlich übersetzt eine Ausnahme und soll ausdrücken, das ein nicht vorgesehener Zustand vorliegt. Exception werden vom Codeautor „geworfen“ und könnten durch ein entsprechendes ExceptionHandling in Form von try/catch Blöcken um den verdächtigen Code herum „aufgefangen“ werden. Die meisten Exceptions, mit welchen unsere Kunden in Berührung kommen werden, werden von der FCL, dem .net Framework ausgelöst. Zum größten Teil zu finden im Namespace System.Exception. Beispielanwendung: Wenn man den Wert einer Variable in einem bestimmten Integer (zahlen) Bereich von 5 – 10 halten möchte, kann beim übersteigen eines bestimmten Wert der Variable, ob verändert durch eigenen oder fremden Code, z.B. eine solche Ausnahme ausgelöst werden damit der Konsument des Codes den Fehler entsprechend „behandeln“
kann. 

ASP.net Fehlerursachen finden mit Bordmitteln:

Der Text auf der rechten Seite ist der Standardmäßig von ASP.net ausgegebene Fehler. Hierbei handelt es sich meist um ein Fehler im
eigenem Code. Dies kann ein einfacher Syntaxfehler im Code des Kunden oder z.B. auch eine Security Exception sein, welche z.B. ausgelöst wird,
wenn der Code des Kunden auf Resourcen zugreifen möchte, die per Thrustlevel verboten sind oder z.B. der ASP.net User für die Aktion im
Filesystem keine Rechte hat. Da gibs unzählige Möglichkeiten. Um eine genauere Fehlerausgabe zu erhalten, muß nur der von der .net
Runtime ausgegebene Hinweiß befolgt werden der besagt, das daß Attribut „mode“ des Elements „customErrors“ auf den Wert „off“ gesetzt werden
muss.

Server Error in '/CorrectSubApplication' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for
this application prevent the details of the application error from being viewed remotely (for
security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines,
please create a  tag within a "web.config" configuration file located in the root
directory of the current web application. This  tag should then have its "mode"
attribute set to "Off".






Notes: The current error page you are seeing can be replaced by a custom error page by
modifying the "defaultRedirect" attribute of the application's  configuration tag to
point to a custom error page URL.

Debug Beispiel Security

Server Error in '/aspnetTraining ' Application.
Security Exception
Description: The application attempted to perform an operation not allowed by the security policy. To grant this application the required permission please contact your system administrator
or change the application's trust level in the configuration file.
Exception Details: System.Security.SecurityException: Request for the permission of type System.Security.Permissions.EnvironmentPermission, mscorlib, Version=1.0.5000.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception
stack trace below.
Stack Trace:
[SecurityException: Request for the permission of type System.Security.Permissions.EnvironmentPermission, mscorlib, Version=1.0.5000.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089 failed.]
System.Security.CodeAccessSecurityEngine.CheckHelper(PermissionSet grantedSet, PermissionSet deniedSet, CodeAccessPermission demand, PermissionToken permToken) +666
System.Security.CodeAccessSecurityEngine.Check(PermissionToken permToken, CodeAccessPermission demand, StackCrawlMark& stackMark, Int32 checkFrames, Int32
unrestrictedOverride) +0
System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission cap, StackCrawlMark& stackMark) +88
System.Security.CodeAccessPermission.Demand() +62
System.Environment.get_WorkingSet() +45
MiscTools.ASPNETBenchmark.getInfos() in default.aspx.cs:100
MiscTools.ASPNETBenchmark.Button_SysInfos_Click(Object sender, EventArgs e) in default.aspx.cs:105
System.Web.UI.WebControls.Button.OnClick(EventArgs e) +108
System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +57
System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +18
System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +33
System.Web.UI.Page.ProcessRequestMain() +2106
System.Web.UI.Page.ProcessRequest() +218
System.Web.UI.Page.ProcessRequest(HttpContext context) +18
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute() +179
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +87
Version Information: Microsoft .NET Framework Version:1.1.4322.916; ASP.NET Version:1.1.4322.573 

Nach Umstellung der customErrors in der web.config der Beispiel Applikation asnetbench werden nun ausführliche Fehler angezeigt. Eine der wichtigesten Information ist die Art der Exception. Hier sieht man z.B., das eine Security Exception ausgelöst wurde, weil die Applikation versucht hat, Umgebungsvariablen auszulesen, was aufgrund unserer Thrustlevel Einstellung verweigert wurde. Wenn der Autor nun genau wissen möchte, wo der Fehler auftrat, kann er auf den StackTrace verwiesen werden. Dieser zeigt die letzten Funktionaufrufe an und somit kann genau rekonstruiert werden, in welcher Funktion/Methode der Fehler auftrat. Als Richtlinie kann man sagen, das die erste Zeile des Trace, welche nicht mit „System.*“ anfängt, für die Exception verantwortlich ist da es sich dabei um Kundencode handelt. In unserem Beispiel wäre es also die Funktion getInfos() der Klasse ASPNETBenchmark des Namespaces MiscTools oder komplett: MiscTools.ASPNETBenchmark.getInfos() in default.aspx.cs:100 Mit diesen Informationen müsste jeder Programmierer den Fehler selbstständig beheben können.

Debug Beispiel Dateioperationen

Ein weiterer, oft gemachte Fehler ist diemangelnde Rechtevergabe für Dateioperationen.Die auch unter UNIX braucht der aktuelle HostRechte zum ändern im Dateisystem.Als Beispiel nehmen wir ein kleines Skript,welches einen einfachen Besucherzählerdarstellt. Die Besucheranzahl wird in einemTextfile gespeichert. Wenn nun jemand die Seitecounter.aspx aufruft, wird zuerst der letzteZählerstand aus der counter.txt gelesen und mit 1addiert. Anschließend wird der neue Wert zurückin die cs_counter.txt geschrieben und der Wertwird dem Besucher ausgegeben.Ohne Änderungen würde beim Aufruf dercounter.aspx eine UnauthorizedAccessExceptionausgelöst werden. Auch hier hilft die von ASP.netausgegebene Fehlermeldung weiter.Im SharedHosting kann der Kunde natürlich nichtper Explorer auf dem Server, um die Rechte zuändern. Hierfür müsste er über Webfiles demNetwork User die Schreib Rechte für dieentsprechende Datei gewähren, auf die mitASP.net schreibend zugegriffen werden soll. Inunserem Fall cs_counter.txt.Ausnahme wäre hier z.B. die Verwendung derImpersonifizierung (siehe auch Fehlermeldung).Dabei haben die aufgerufenen Skripte diegleichen Rechte, wie der aktuell autentifizierteUser. Das funktioniert im Sharedhosting aber nurmit dem u User, welcher dann statt des NetworkUsers über webfiles entsprechende Rechtezugewiesen bekommen muss.Bei Serverkunden ist dies etwas anders. Um dortherauszufinden, welchem User nun die Rechtezugestanden werden müssen, muss zuerst derzugewiesene AppPool lokalisiert werden. Dieserläuft unter einer bestimmten Identität. ImNormalfall ist dies der Network Service oder aufauf deutsch: Netzwerkdienst. Wenn dort einanderer User aufgeführt ist, muss diesem danndas entsprechende Rechte im Filessystemgegeben werden.

Serverfehler in der Anwendung '/schulungen/aspnet'.
Der Zugriff auf den Pfad E:\websites\LocalUser\god\htdocs\schulungen\aspnet\cs_counter.txt wurde verweigert.
Beschreibung: Beim Ausführen der aktuellen Webanforderung ist ein unverarbeiteter Fehler aufgetreten. Überprüfen Sie die
Stapelüberwachung, um weitere Informationen über diesen Fehler anzuzeigen und festzustellen, wo der Fehler im Code verursacht wurde.
Ausnahmedetails: System.UnauthorizedAccessException: Der Zugriff auf den Pfad
E:\websites\LocalUser\god\htdocs\schulungen\aspnet\cs_counter.txt wurde verweigert.
ASP.NET darf auf die angeforderte Ressource nicht zugreifen. Gewähren Sie der ASP.NET-Prozessidentität Zugriffsrechte für die
Ressource. ASP.NET hat eine Standardprozessidentität (gewöhnlich '{MACHINE}\ASPNET' unter IIS 5 bzw. Network Service unter IIS 6),
die verwendet wird, wenn die Anwendung keinen Identitätswechsel ausführen kann. Wenn die Anwendung über <identity
impersonate="true"/> einen Identitätswechsel ausführen kann, wird als Identität gewöhnlich der anonyme Benutzer (normalerweise
IUSR_MACHINENAME) bzw. der authentifizierte Anfragebenutzer verwendet.
Um ASP.NET Schreibrechte für eine Datei zu gewähren, klicken Sie im Explorer mit der rechten Maustaste auf die Datei, wählen
"Eigenschaften" und anschließend die Registerkarte "Sicherheit". Klicken Sie auf "Hinzufügen", um den entsprechenden Benutzer bzw.
eine Gruppe hinzuzufügen. Markieren Sie das ASP.NET-Konto und aktivieren Sie jeweils das Kontrollkästchen für den gewünschten
Zugriff.
Quellfehler:
Beim Ausführen der aktuellen Webanforderung wurde einen unbehandelte Ausnahme generiert. Informationen über den Ursprung und die
Position der Ausnahme können mit der Ausnahmestapelüberwachung angezeigt werden.
Stapelüberwachung:
[UnauthorizedAccessException: Der Zugriff auf den Pfad E:\websites\LocalUser\god\htdocs\schulungen\aspnet\cs_counter.txt wurde
verweigert.]
System.IO.__Error.WinIOError(Int32 errorCode, String str) +393
System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean useAsync, String
msgPath, Boolean bFromProxy) +888
System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize) +44
System.IO.StreamWriter.CreateFile(String path, Boolean append) +55
System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encoding, Int32 bufferSize) +49
System.IO.StreamWriter..ctor(String path, Boolean append) +66
System.IO.File.CreateText(String path) +32
aspnetTraining.counter.Page_Load(Object sender, EventArgs e) in c:\inetpub\wwwroot\hellogod\counter.aspx.cs:31
System.Web.UI.Control.OnLoad(EventArgs e) +67
System.Web.UI.Control.LoadRecursive() +35
System.Web.UI.Page.ProcessRequestMain() +731
Versionsinformationen: Microsoft .NET Framework Version:1.1.4322.573; ASP.NET-Version:1.1.4322.573 

Aber auch hier wird der Nutzen vom StackTrace verdeutlicht. Dies besagt, das der Kunde im Seitenereigniss Page_Load den Fehler Verursachenden Code ausgeführt hat. Die letzte Punkt (System.IO.__Error.WinIOError(Int32 errorCode, String str) +393) ist dann schon Selbsterklärend für den Programmierer.

Trace

undefined

Die Informationen der Traceausgabe sind sehr umfangreich und stellen den aktuellen Applikations und Sitzungsstatus dar. Das Wissen darüber ist sehr hilfreich, wenn weniger geübte Entwickler sich monieren dass Ihre Applikationen komische Dinge tun ohne eine Exception auszulösen, also
einfache Logikfehler. Dann kann ein Hint auf die Traceausgabe die Lösung bringen. In diesem stehen alle Werte, die von User an den Server und zurück gesendet wurden, die Stati der einzelnen Steuerelemente inkl. Speicherverbrauch usw… Aktiviert wird die Anzeige entweder in der web.config über das <trace> Element oder direkt in der Page Direktive der aktuellen Seite durch einfaches hinzufügen von trace=“true“. Beim nächsten Aufruf wird anschließend unter der aktuellen Seite alle Client/Server Informationen angezeigt die sich in folgende Kategorien aufteilen:

Anforderungsdetails 
Enthält die aktuelle SessionID (Für jeden User wird eine solche eindeutige ID angelegt), den Zeitpunkt, Codierung und Typ der Anforderung inkl. Zurückgegebener HTTP Statuscode. 

Überwachungsinformationen
Eine Liste mit den durchlaufenden Seitenereignissen und die dazu benötigte Zeit.

Steuerelementstruktur
Zeigt eine Hierachische Liste aller auf der Seite befindlichen ASP.net Steuerelemente wie z.B. eine Textbox, ein Button usw… und gibt deren Typ, Speicherverbrauch und Größe des von diesem Element übergebenen ViewState, also dem vom Browser per Formular HiddenVariable übergebene
Status des Elements. Hier lässt sich z.B. bei Performanceproblemen schnell das Steuerelement herrausfinden, welches den größten Viewstate erzeugt.

Sitzungsstatus
Name, Typ und Wert aller Sessionvariablen.

Anwendungsstatus
Name, Typ und Wert aller Applicationvariablen.

Cookieauflistung
Alle, von der aktuellen Applikation auf dem Client gesetzten Cookies.

Headerauflistung (Server)
Alle vom Server zurückgegebenen Headerinformationen.

Servervariablen
Wie auch ein Apache hat auch der IIS Servervariablen. Diese setzen sich zusammen aus Informationen über den anfragenden Client und Information über die Serverumgebung, sind ebenfalls weitestgehend identisch mit den Apache Servervariablen.


  • 21.02.2018 15:05:29