4 Stimmen

Leere .net-Datei erzeugt "Unzulässige Zeichen im Pfad"-Fehler

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:

  1. 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?

  2. 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?

  3. 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?

  4. 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:

ISAPI Filters
(Quelle: <a href="http://chris.photobooks.com/Other/forumPosts/ISAPI_Filters.png" rel="nofollow noreferrer">fotobücher.de </a>)

Wildcard Mappings
(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.

2voto

Adam Hughes Punkte 3604

Voir KB 922780 : Fehlermeldung, wenn ein CGI-Programm, das mit dem .NET Framework 2 geschrieben wurde, Webdienste aufruft: "System.ArgumentException: Illegale Zeichen im Pfad"

und die damit verbundenen Blogbeitrag . Ihr Code scheitert während eines Aufrufs von GetCurrentDirectory genau wie in diesem Blogbeitrag.

2voto

Vinay Sajip Punkte 89444

Ich bin mir nicht sicher, ob Sie jetzt schon zu ADPlus greifen müssen - was er mit ADPlus herausgefunden hat, wissen Sie bereits - nämlich, dass der wahrscheinlichste Übeltäter etwas ist, das das aktuelle Verzeichnis ändert.

Ein wichtiger Punkt scheint zu sein, dass IISReset das Problem für eine gewisse Zeit behebt, das Problem aber nach einem gewissen Zeitpunkt wieder auftritt, sobald etwas auf einer der Seiten des Servers passiert. Ich nehme an, dass Sie mit "Sites" die ASP.NET-Anwendung meinen - bitte bestätigen Sie, ob dies der Fall ist ist nicht den Fall.

Die Tatsache, dass das Problem bei mehreren Sites auftritt, deutet darauf hin, dass es sich um einen ISAPI-Filter oder eine ISAPI-Erweiterung oder eine EXE-Datei handeln könnte, die einer Platzhalterzuordnung in einer oder mehreren bestimmten ASP.NET-Anwendungen zugeordnet ist.

Starten Sie also den IIS-Manager, und aktualisieren Sie Ihre Frage mit Informationen zu ISAPI-Filtern und Wildcard-Zuordnungen. Die ISAPI-Filterinformationen finden Sie auf der Registerkarte "ISAPI-Filter" im Dialogfeld "Eigenschaften" für die Website (unter "Websites" in der Strukturansicht des IIS-Managers). Die Wildcard-Zuordnungen befinden sich im Dialogfeld "Anwendungskonfiguration", das Sie über die Schaltfläche "Konfiguration..." im Dialogfeld "Eigenschaften" für Ihre spezifische ASP.NET-Anwendung aufrufen.

Sehen Sie genau nach, welche Mappings für .aspx-Erweiterungen registriert sind, und melden Sie diese in Ihrem Update.

Das Problem könnte auch darin liegen HttpHandlers in einzelnen ASP.NET-Websites installiert - schauen Sie also in der <httphandler> Abschnitt in Web.config um zu sehen, ob ein Handler definiert ist mit etwas wie

<add verb="*" path="*.aspx" type="..." />

Dies kann in einer anderen Anwendung als der sein, mit der Sie gerade arbeiten. Um herauszufinden, welche das ist, überprüfen Sie die Serverprotokolle nach einem IISReset, um zu sehen, welcher Eintrag als erster einen 5xx-HTTP-Statuscode (der einen internen Serverfehler anzeigt) zurückgibt, und sehen Sie sich die Anfrage an, die dies ausgelöst hat. Die Anwendung, die die Anfrage bearbeitet hat, ist möglicherweise diejenige, auf die man sich konzentrieren sollte.

Alle Dinge, die ich vorgeschlagen habe, sollten auf einem Produktionsserver sicher zu machen sein :-) Ich schlage nicht vor, dass Sie tatsächlich einen IISReset durchführen, sondern nur die Protokolle unmittelbar nach dem letzten IISReset überprüfen.

Aktualisierung: Ich habe die von Ihnen geposteten aktualisierten Informationen gesehen. Es könnte ISAPI_Rewrite3 sein oder auch nicht; ich habe es jedenfalls schon früher ohne Probleme verwendet. Allerdings bin ich überrascht, ASP.NET_2.0.xxx in der ISAPI-Filterliste zu sehen - ich habe es nicht in meiner (ich verwende Windows Server 2003). Ich würde also (wenn es die Zeit erlaubt - vielleicht müssen Sie einen Ausfall einplanen) diese beiden ISAPI-Filter vorübergehend aus der Liste entfernen (so, dass Sie sie leicht wiederherstellen können) und sehen, ob das einen Unterschied macht. Wenn sich das Problem verschlimmert hat, fügen Sie den ASP.NET-Filter wieder hinzu (wie lautet der genaue Pfad dieses Eintrags?) und lassen Sie ISAPI_Rewrite3 weg, dann versuchen Sie es erneut.

Der Grund, warum ich überrascht bin, eine ASP.NET-DLL in der ISAPI-Filterliste zu sehen, liegt darin, dass sie normalerweise mit den Zuordnungen auf Anwendungsbasis konfiguriert wird (wobei die Anwendungen eine Standardkonfiguration erben). Es funktioniert normalerweise als ISAPI Erweiterung nicht ein ISAPI Filter .

Können Sie bitte auch die <httpmodules> Abschnitte auf die gleiche Weise wie bei <httphandlers> ?

Es kann notwendig sein, aspnet_regiis erneut auszuführen, das das ASP.NET-System für den IIS initialisiert; dies ist jedoch ein großer Schritt Das könnte viele Dinge kaputt machen. Wenn möglich, kopieren Sie den gesamten Server auf einen Ersatzcomputer in einem separaten Test- oder Entwicklungsnetzwerk und führen Sie den Vorgang dort durch. Können Sie Ihren lokalen Mirror für diese Art von Tests verwenden?

0voto

Sur Global.asax setzen Sie das Folgende:

private static string EnvironmentDir = null; 
void Application_Start(object sender, EventArgs e)
{
     EnvironmentDir = System.Environment.CurrentDirectory;
}

void Application_BeginRequest(object sender, EventArgs e)
{
      System.Environment.CurrentDirectory = EnvironmentDir;
}

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X