Fehler: Das Debuggen kann auf dem Webserver nicht gestartet werden
Beim Versuch, eine Anwendung zu debuggen, die auf einem Webserver ausgeführt wird, kann eventuell die folgende Fehlermeldung angezeigt werden:
Unable to start debugging on the Web server
Wenn die Fehlermeldung länger als diese ist, wird sie in einem Unterthema behandelt.
Beim Auftreten dieses Fehlers müssen verschiedene Faktoren geprüft werden: Fangen Sie bei Zu überprüfende Aspekte an, und gehen Sie dann die übrigen Punkte basierend auf Ihrer Hardware- und Softwarekonfiguration durch.
Zu überprüfende Aspekte
Webanwendungen auf Remoteservern
In Visual SourceSafe gespeicherte Webanwendungen mit FrontPage-Servererweiterungen
Manuelles Anhängen
Die Debuganforderung konnte vom Server aufgrund ungültiger Syntax nicht verarbeitet werden
Zu überprüfende Aspekte
Versuchen Sie, die folgenden Aspekte zu überprüfen:
Gehen Sie die Prozeduren zum Einrichten von ASP.NET oder ATL-Server nochmals durch. Weitere Informationen finden Sie unter Vorbereitungen zum Debuggen von ASP.NET.
Haben Sie die notwendigen Zugriffsrechte zum Debuggen? Weitere Informationen finden Sie unter ASP.NET-Debugging: Systemanforderungen im Abschnitt Sicherheitsanforderungen.
Haben Sie eine Version von Windows installiert, die das automatische Anhängen des Visual Studio-Debuggers an Webanwendungen unterstützt? Wenn dies nicht der Fall ist, müssen Sie die Anwendung ohne Debuggen starten und das Anhängen manuell durchführen. (Weitere Informationen finden Sie unter Manuelles Anhängen und ASP.NET-Debugging: Systemanforderungen.)
Verfügt die Webanwendung über eine WEB.CONFIG-Datei?
Aktiviert die Datei Web.config den Debugmodus, wenn für das debug-Attribut true festgelegt wird? Weitere Informationen finden Sie unter Gewusst wie: Debuggen für ASP.NET-Anwendungen aktivieren.
Enthält die Datei Web.config Syntaxfehler? Nach Syntaxfehlern suchen Sie, indem Sie die Webanwendung ohne Debuggen ausführen. (Klicken Sie im Menü Debuggen auf Starten ohne Debuggen.) Wenn Web.config Syntaxfehler enthält, werden zu diesen Fehlern ausführliche Informationen angezeigt.
Haben Sie das Projekt erstellt, indem Sie eine bestimmte IP-Adresse (z. B. 100.20.300.400) angegeben haben? Zum Debuggen eines Webservers ist eine NTLM-Authentifizierung erforderlich. Standardmäßig wird davon ausgegangen, dass IP-Adressen dem Internet zuzuordnen sind, während die NTLM-Authentifizierung nicht über das Internet vorgenommen wird. So korrigieren Sie dieses Problem:
Geben Sie bei der Erstellung des Projekts den Namen des Computers im entsprechenden Intranet an.
– oder –
Fügen Sie der Liste vertrauenswürdiger Sites des Computers die IP-Adresse (http://100.20.300.400) hinzu. (Klicken Sie im Internet Explorer im Menü Extras auf die Option Internetoptionen, und wählen Sie dann die Registerkarte Sicherheit.)
Sind die notwendigen Erweiterungen auf dem Servercomputer registriert? Falls nicht, registrieren Sie ASP.NET erneut, wie unten in der Prozedur beschrieben.
Wurde IIS auf dem lokalen Computer (der Computer, auf dem Visual Studio ausgeführt wird) installiert, nachdem Visual Studio installiert worden ist? IIS muss vor Visual Studio installiert werden. Wenn IIS danach installiert wurde, müssen Sie ASP.NET eventuell neu registrieren.
So registrieren Sie ASP.NET neu
Führen Sie in einem Eingabeaufforderungsfenster den folgenden Befehl aus: systemroot\Microsoft.NET\Framework\ versionNumber \aspnet_regiis -i
Hinweis Unter Windows Server 2003 können Sie ASP.NET in der Systemsteuerung über die Option Software installieren.
Legen Sie den Visual Studio-Datenträger ein, führen Sie das Setupprogramm aus, und wählen Sie Reparieren/Neu installieren aus. In diesem Schritt wird die Freigabe wwwroot$ erstellt, und die entsprechenden Berechtigungen werden hinzugefügt.
Ist der Name der Website der lokalen Loopbackadresse zugeordnet, während die integrierte Authentifizierung aktiviert ist? Eine Lösung finden Sie in diesem Knowledge Base-Artikel (möglicherweise in englischer Sprache).
Wurde die URL für die Startseite des Projekts ordnungsgemäß angegeben? Wurden die Dateinamenerweiterung und das Projektverzeichnis ordnungsgemäß angegeben?
Überprüfen Sie die IIS-Einstellungen der Webanwendung. Weitere Informationen finden Sie unter Gewusst wie: Überprüfen von IIS-Eigenschafteneinstellungen.
Wenn zwei Versionen von .NET Framework auf dem Webserver installiert sind, überprüfen Sie, ob in den IIS-Einstellungen die richtige Version festgelegt ist. Weitere Informationen finden Sie unter Gewusst wie: Überprüfen von IIS-Eigenschafteneinstellungen.
Webanwendungen auf Remoteservern
Falls sich die Anwendung auf einem Remoteserver befindet, stellen Sie zuerst sicher, dass Sie alle Punkte aus Zu überprüfende Aspekte durchgegangen sind. Überprüfen Sie als Nächstes folgende Punkte:
Sind auf dem Computer, der IIS-Server ausführt, die Visual Studio-Remotekomponenten installiert? Weitere Informationen finden Sie unter Vorbereitungen zum Debuggen von ASP.NET.
Haben Sie die notwendigen Zugriffsrechte zum Debuggen? Weitere Informationen finden Sie unter ASP.NET-Debugging: Systemanforderungen im Abschnitt Sicherheitsanforderungen.
Verwenden Sie bei dem Versuch, eine Webanwendung auf einem Remotecomputer zu debuggen, Terminal Server? Das Remotedebuggen systemeigener Webanwendungen unter Verwendung von Terminal Server wird unter Windows XP unterstützt. Unter Windows 2000 oder Windows NT wird es hingegen nicht unterstützt.
In Visual SourceSafe gespeicherte Webanwendungen mit FrontPage-Servererweiterungen
Wenn die Webanwendung in Visual SourceSafe gespeichert wurde und als Webzugriffsmethode FrontPage-Servererweiterungen verwendet wird, sind folgende Fragen zu klären:
- Befindet sich Visual SourceSafe auf demselben Computer wie der FrontPage-Server/Webserver? Ist dies der Fall, so können Sie mit der Integrierten Windows-Authentifizierung debuggen. Im Thema Gewusst wie: Überprüfen von IIS-Eigenschafteneinstellungen in der Prozedur So überprüfen Sie die IIS-Einstellungen der Webanwendung finden Sie Hinweise, um die Einstellung der integrierten Authentifizierung zu überprüfen.
Die Debuganforderung konnte vom Server aufgrund ungültiger Syntax nicht verarbeitet werden
Manchmal kann der Server aufgrund von ungültiger Syntax eine Debuganforderung nicht verarbeiten. Ungültige Anforderungssyntax kann durch Fehler in der Datei machine.config verursacht werden. Dieser Fehler tritt auf, wenn maxRequestLength in der Datei machine.config auf einen übertrieben hohen Wert (z. B. 40.960.000) festgelegt ist.
Manuelles Anhängen
Wenn Sie bei der Fehlerbehebung die Schrittfolge eingehalten haben und dennoch beim Starten des Debuggens eine Fehlermeldung erhalten, sollten Sie versuchen, die Anwendung durch manuelles Anhängen zu debuggen.
So hängen Sie den Debugger manuell an
Starten Sie die Anwendung ohne Debugfunktion. (Klicken Sie im Menü Debuggen auf Starten ohne Debuggen.
Finden Sie den Namen des entsprechenden IIS-Prozesses oder des Arbeitsprozesses heraus. ATL-Serveranwendungen heißen standardmäßig inetinfo.exe. Unter Gewusst wie: Herausfinden des ASP.NET-Prozessnamens finden Sie Hinweise, um den Namen des ASP.NET-Arbeitsprozesses herauszufinden.
Verwenden Sie eine der folgenden Prozeduren, um zu bestimmen, unter welchem Prozess eine ASP.NET-Anwendung bzw. eine ATL-Serveranwendung ausgeführt wird.
Hängen Sie den Debugger an den Prozess an, der im vorherigen Schritt ermittelt wurde. Weitere Informationen finden Sie unter Gewusst wie: Anfügen an einen laufenden Prozess.
So prüfen Sie, unter welchem Prozess eine ASP.NET-Anwendung ausgeführt wird
Öffnen Sie die Datei machine.config für die Anwendung in Visual Studio oder einem anderen Text-Editor .
Suchen Sie im system.web-Knoten den ProcessModel-Knoten, und überprüfen Sie sein enable-Attribut:
Wenn für enable der Wert TRUE festgelegt wurde, wird die Anwendung unter aspnet_wp.exe oder w3wp.exe ausgeführt. (Das ist auch die Standardeinstellung.)
Wenn für enable der Wert FALSE festgelegt ist, wird die Anwendung unter inetinfo.exe ausgeführt.
So prüfen Sie, unter welchem Prozess eine ATL-Serveranwendung ausgeführt wird
Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Projektnamen, und wählen Sie dann im Kontextmenü Eigenschaften aus.
Öffnen Sie im Dialogfeld <Projekt>-Eigenschaftenseiten den Ordner Webbereitstellung, und wählen Sie Allgemein aus.
Prüfen Sie die Einstellung für Anwendungsschutz.
Wenn für diese Option die Einstellung Niedrig (IIS-Prozess) festgelegt ist, wird die Anwendung unter inetinfo.exe ausgeführt.
Wenn für diese Option die Einstellung Mittel (im Pool) festgelegt ist, wird die Anwendung unter einem dllhost.exe-Prozess (zusammen mit anderen ATL-Serveranwendungen im Pool) ausgeführt.
Wenn für diese Option die Einstellung Hoch (isoliert) festgelegt ist, wird die Anwendung unter einem dllhost.exe-Prozess (getrennt von anderen ATL-Serveranwendungen) ausgeführt.
Klicken Sie auf OK, um das Dialogfeld <Projekt>-Eigenschaftenseiten zu schließen.
Siehe auch
Aufgaben
Fehler: Der Webserver konnte die angeforderte Ressource nicht finden
Referenz
Debuggen von Webanwendungen: Fehler und Problembehandlung