Ich habe eine völlig leere ".aspx"-Datei, die sich auf einem IIS6-Webserver befindet. Auf dem Server ist .net 3.5 installiert.
Bei der Ausführung dieser Datei wird der Fehler "Illegale Zeichen im Pfad" erzeugt. Ein vollständiger Stack-Trace dieses Fehlers lautet hier erhältlich .
Das Problem kann vorübergehend durch IISReset behoben werden. Sobald jedoch eine Website auf diesem Server anfängt, dieses Problem zu zeigen, wird jeder Zugriff auf jede .aspx-Seite auf dieser Website das gleiche Problem verursachen (einschließlich meiner völlig leeren Beispieldatei).
Was könnte die Ursache dafür sein, und wie kann ich das Problem beheben?
Editar : Ich habe ein Kopfgeld ausgesetzt, in der Hoffnung, mehr Hilfe zu bekommen, bevor wir einen Supportfall bei Microsoft eröffnen. Ich habe gesehen, dass die Wissensbasisartikel y Blogbeitrag auf die Adam Hughes hingewiesen hat, aber diese Informationen allein bieten keine vollständige Lösung. Der Blog ist für Menschen geschrieben, die über Kenntnisse und Fähigkeiten verfügen, die mir fehlen, die ich mir aber offenbar aneignen muss. Ich brauche Hilfe, um einige der Zusammenhänge und Überlegungen zu verstehen, die hier vor sich gehen.
Ich suche gezielt nach Hilfe bei diesen Fragen, die mich zu einem funktionierenden System führen sollen:
-
Die Abhilfe im Knowledge-Base-Artikel sieht vor, dass ich in Schritt sechs ein ausführbares CGI-Programm auswähle. Was soll ich hier auswählen? Soll der im Blog beschriebene Debugging-Prozess dazu führen, dass ich herausfinde, welches Programm ich dafür auswählen muss?
-
In dem Blogbeitrag wird eine Möglichkeit zur Fehlersuche beschrieben, aber es wird vorausgesetzt, dass ich Kenntnisse habe, die ich (noch) nicht habe. Ich habe zwar gefolgert, dass ich Folgendes brauchen werde ADPlus Ich habe dieses Tool noch nie benutzt und musste auch sonst noch nie einen Speicherauszug untersuchen. Ich bin mir nicht sicher, was ich tun soll, wenn der Autor dies sagt:
Da die Zeit drängt und nicht viel zu tun ist nicht viel zu verlieren, entschied ich mich für den Live-Debug Ansatz. Auf diese Weise konnte ich dank des Problem zu diesem Zeitpunkt leicht reproduzierbar war reproduzierbar war, bekam ich bald den benötigten Speicherauszug.
Wie verwende ich ADPlus (oder ein anderes Tool), um den Speicherauszug zu erstellen, und wie stelle ich sicher, dass der Speicherauszug die Informationen enthält, die ich zur Fehlersuche benötige? Erreicht "adplus -crash -iis", was ich will?
-
Das Problem tritt auf einem Produktionsserver auf. Ich kann diesen Server zwar neu starten, wenn ich wirklich muss, aber ich möchte Störungen möglichst vermeiden. Ist es eine sichere und vernünftige Idee, einen Speicherauszug auf einem Live-Server zu erstellen? Werden die anderen Funktionen des Servers dadurch beeinträchtigt, und wenn ja, worauf muss ich achten?
-
Klingt es so, als wäre ich auf dem richtigen Weg? Welche anderen Möglichkeiten sollte ich in Betracht ziehen, um dieses Problem zu lösen?
Edit : Vinay, hier sind die von Ihnen angeforderten Informationen zu ISAPI-Filtern und Wildcard-Zuordnungen:
(Quelle: <a href="http://chris.photobooks.com/Other/forumPosts/ISAPI_Filters.png" rel="nofollow noreferrer">fotobücher.de </a>)
(Quelle: <a href="http://chris.photobooks.com/Other/forumPosts/Wildcards.png" rel="nofollow noreferrer">fotobücher.de </a>)
Der vollständige Pfad für die mit .aspx-Dateien verbundene Datei lautet C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
.
Wir haben einen Spiegel dieses Servers in unserem lokalen Netzwerk. Ich konnte damit alle Instanzen der web.config durchsuchen und habe nichts Ungewöhnliches gefunden. Tatsächlich sieht es so aus, als würden wir diesen Abschnitt der web.config nie verwenden, da alle Einträge mit diesem identisch waren:
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="..." />
<add verb="*" path="*_AppService.axd" validate="false" type="..."/>
<add verb="GET,HEAD" path="ScriptResource.axd" validate="false" type="..." />
</httpHandlers>
Wenn ich mir das ansehe, sollte ich misstrauisch sein gegenüber ISAPI_Rewrite3 die wir derzeit verwenden, um "freundliche" URLs auf einigen ASP Classic-Sites zu unterstützen. Ist dies auch Ihre Diagnose? Liege ich richtig in der Annahme, dass die "Behebung" dieses Problems das Ersetzen von ISAPI_Rewrite3 bedeuten wird?
Edit : Ich habe den ASP.NET-Eintrag aus der ISAPI-Filterliste entfernt. Der vollständige Pfad hierfür war C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_filter.dll
. Es gibt keine offensichtlichen negativen Auswirkungen der Entfernung dieser Funktion. MSDN Staaten dass er zur Aufrechterhaltung eines kochfreien Sitzungsstatus verwendet wird, der für diesen Server ohnehin nicht wichtig ist.
Seit dem Entfernen des ASP.NET-Filters ist das Problem seit einigen Stunden nicht mehr aufgetreten. Leider habe ich keine andere Möglichkeit, das Problem zu reproduzieren, als darauf zu warten, dass es wieder auftritt. Ich werde es bis morgen Abend ruhen lassen. Wenn das Problem erneut auftritt, werde ich auch den ISAPI_Rewrite3-Filter entfernen und es erneut versuchen (zum Glück wird die Funktionalität dieses Filters von unseren Kunden nicht häufig genutzt). In jedem Fall werde ich wiederkommen und über meine Ergebnisse berichten.
Ich habe den Abschnitt <httpModules> wie gewünscht überprüft. Alle derartigen Einträge in allen web.config-Dateien auf diesem Server sind mit diesem Beispiel identisch:
<httpModules>
<add name="ScriptModule"
type="System.Web.Handlers.ScriptModule,
System.Web.Extensions,
Version=3.5.0.0,
Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
</httpModules>
Vielen Dank für Ihre Unterstützung!
0 Stimmen
Entfernen Sie die "völlig leere" aspx-Datei.
3 Stimmen
Der gleiche Fehler tritt bei allen .net-Dateien auf, aber ich wollte ausschließen, dass ein fehlerhafter Code das Problem ist. Die "völlig leere" aspx-Datei ist die geringste Menge an Code erforderlich, um das Problem zu reproduzieren: d.h., überhaupt keine. Ich schätze, das Problem WÜRDE verschwinden, wenn ich alle .aspx-Dateien entfernen würde, aber das ist mir ein bisschen zu zen.
0 Stimmen
Ich habe meine Antwort mit weiteren Vorschlägen aktualisiert.
0 Stimmen
Hoffen wir das Beste. Hatten Sie die Möglichkeit, die Serverzugriffsprotokolle kurz nach dem letzten IISReset bis zum ersten Auftreten des Fehlers einzusehen?