Erreur : impossible de démarrer le débogage sur le serveur web
Quand vous essayez de déboguer une application ASP.NET exécutée sur un serveur web, vous pouvez obtenir ce message d’erreur : Unable to start debugging on the Web server
.
Souvent, cette erreur est générée parce qu’une erreur ou un changement de configuration s’est produit et nécessite la mise à jour de vos pools d’applications, la réinitialisation d’IIS ou les deux. Vous pouvez réinitialiser IIS en ouvrant une invite de commandes avec élévation de privilèges et en tapant iisreset
.
Quel est le message d’erreur détaillé ?
Le message Unable to start debugging on the Web server
est générique. Généralement, un message plus spécifique est ajouté dans la chaîne d’erreur et peut vous aider à identifier la cause du problème ou à rechercher un correctif plus exact. Voici quelques-uns des messages d’erreur les plus courants qui sont ajoutés au message d’erreur principal :
- IIS ne liste pas de site web correspondant à l’URL de lancement
- Le serveur web n’est pas configuré correctement
- Connexion impossible au serveur web
- Le serveur web n’a pas répondu en temps opportun
- L’opération a expiré
- Microsoft Visual Studio Remote Debugging Monitor (msvsmon.exe) ne semble pas s’exécuter sur l’ordinateur distant
- Le serveur distant a renvoyé une erreur
- Impossible de démarrer le débogage ASP.NET
- Le débogueur ne peut pas se connecter à l’ordinateur distant
- Consultez l'aide pour plus d'informations sur les erreurs de configuration usuelles. L’exécution de la page web en dehors du débogueur peut fournir des informations complémentaires.
- Opération non prise en charge. Erreur inconnue : errornumber
IIS ne liste pas de site web correspondant à l’URL de lancement
Redémarrez Visual Studio comme Administrateur et réessayez le débogage. (Certains scénarios de débogage ASP.NET nécessitent des privilèges élevés.)
Vous pouvez configurer Visual Studio pour qu’il s’exécute toujours comme Administrateur : cliquez avec le bouton droit sur l’icône de raccourci Visual Studio, choisissez Propriétés > Avancées, puis choisissez de toujours exécuter comme Administrateur.
Le serveur web n’est pas configuré correctement
Connexion impossible au serveur web
Est-ce que vous exécutez Visual Studio et le serveur web sur la même machine et déboguez en utilisant F5 (au lieu d’Attacher au processus) ? Ouvrez les propriétés de votre projet et vérifiez que le projet est configuré pour se connecter au serveur web et à l’URL de lancement appropriés. (Ouvrez Propriétés > Web > Serveurs ou Propriétés > Déboguer selon le type de votre projet. Pour un projet Web Forms, ouvrez Pages de propriétés > Options de démarrage > Serveur.)
Sinon, redémarrez votre pool d’applications, puis réinitialisez IIS. Pour plus d’informations, consultez Vérifier votre configuration IIS.
Le serveur web n’a pas répondu en temps opportun
- Réinitialisez IIS et réessayez le débogage. Plusieurs instances de débogueur peuvent être attachées au processus IIS, dans ce cas une réinitialisation les arrête. Pour plus d’informations, consultez Vérifier votre configuration IIS.
L’opération a expiré
- Réinitialisez IIS et réessayez le débogage. Plusieurs instances de débogueur peuvent être attachées au processus IIS, dans ce cas une réinitialisation les arrête. Pour plus d’informations, consultez Vérifier votre configuration IIS.
Microsoft Visual Studio Remote Debugging Monitor (msvsmon.exe) ne semble pas s’exécuter sur l’ordinateur distant
- Si vous déboguez sur une machine distante, vérifiez que vous avez installé et que vous exécutez le débogueur distant. Si le message mentionne un pare-feu, vérifiez que les ports appropriés dans le pare-feu sont ouverts, en particulier si vous utilisez un pare-feu tiers.
- Si vous utilisez un fichier HOSTS, vérifiez qu’il est configuré correctement. Par exemple, si vous déboguez en utilisant F5 (au lieu d’Attacher au processus), le fichier HOSTS doit indiquer la même URL de projet que dans les propriétés de votre projet, Propriétés > Web > Serveurs ou Propriétés > Déboguer, en fonction du type de votre projet.
Le serveur distant a retourné une erreur
Consultez votre fichier journal IIS pour obtenir des sous-codes d’erreur et des informations supplémentaires, et ce billet de blog sur IIS 7.
Par ailleurs, voici quelques-uns des codes d’erreur courants et des suggestions.
- (403) Interdit. Il existe de nombreuses causes possibles pour cette erreur. Consultez votre fichier journal et les paramètres de sécurité IIS du site web. Vérifiez que le fichier
web.config
du serveur comprenddebug=true
dans l’élément de compilation. Vérifiez que votre dossier Application web a les autorisations appropriées et que la configuration de votre pool d’applications est correcte (un mot de passe a peut-être changé). Consultez Vérifier votre configuration IIS. Si ces paramètres sont déjà corrects et que vous déboguez localement, vérifiez également que vous vous connectez au type de serveur et à l’URL appropriés (dans Propriétés > Web > Serveurs ou Propriétés > Déboguer, selon le type de votre projet). - (503) Serveur non disponible. Le pool d’applications peut s’être arrêté en raison d’une erreur ou d’un changement de configuration. Redémarrez le pool d’applications.
- (404) Introuvable. Vérifiez que le pool d’applications est configuré pour la version correcte d’ASP.NET.
Impossible de démarrer le débogage ASP.NET
- Redémarrez le pool d’applications et réinitialisez IIS. Pour plus d’informations, consultez Vérifier votre configuration IIS.
- Si vous effectuez des réécritures d’URL, testez un fichier
web.config
de base sans réécriture d’URL. Consultez la Remarque sur le module de réécriture d’URL dans Vérifier votre configuration IIS.
Le débogueur ne peut pas se connecter à l’ordinateur distant
Si vous déboguez localement, ouvrez les propriétés de votre projet dans Visual Studio, et vérifiez que le projet est configuré pour se connecter au serveur web et à l’URL appropriés. (Ouvrez Propriétés > Web > Serveurs ou Propriétés > Déboguer, en fonction du type de votre projet.)
Cette erreur peut se produire quand vous déboguez localement avec une version 32 bits de Visual Studio, qui utilise la version 64 bits du débogueur distant pour déboguer des applications 64 bits. Visual Studio 2019 et versions antérieures sont des applications 32 bits. Examinez votre pool d’applications sur IIS pour vérifier que l’option Activer les applications 32 bits est définie sur true
, redémarrez IIS, puis réessayez.
Par ailleurs, si vous utilisez un fichier HOSTS, vérifiez qu’il est configuré correctement. Par exemple, le fichier HOSTS doit indiquer la même URL de projet que dans les propriétés de votre projet, Propriétés > Web > Serveurs ou Propriétés > Déboguer, en fonction du type de votre projet.
Consultez l'aide pour plus d'informations sur les erreurs de configuration usuelles. L’exécution de la page web en dehors du débogueur peut fournir des informations complémentaires.
Est-ce que vous exécutez Visual Studio et le serveur web sur la même machine ? Ouvrez les propriétés de votre projet et vérifiez que le projet est configuré pour se connecter au serveur web et à l’URL de lancement appropriés. (Ouvrez Propriétés > Web > Serveurs ou Propriétés > Déboguer, en fonction du type de votre projet.)
Si cela ne fonctionne pas ou que vous déboguez à distance, suivez les étapes décrites dans Vérifier votre configuration IIS.
Opération non prise en charge. Erreur inconnue : errornumber
Si vous effectuez des réécritures d’URL, testez un fichier web.config
de base sans réécriture d’URL. Consultez la Remarque sur le module de réécriture d’URL dans Vérifier votre configuration IIS.
Vérifier votre configuration IIS
Après avoir suivi les étapes détaillées ici pour résoudre le problème et avant de réessayer le débogage, vous devez peut-être également réinitialiser IIS. Vous pouvez le faire en ouvrant une invite de commandes avec élévation de privilèges et en tapant iisreset
.
Arrêtez et redémarrez vos pools d’applications IIS, puis réessayez.
Le pool d’applications s’est peut-être arrêté à la suite d’une erreur. Sinon, vous avez peut-être fait un autre changement de configuration qui nécessite l’arrêt et le redémarrage de votre pool d’applications.
Notes
Si le pool d’applications continue de s’arrêter, vous devez peut-être désinstaller le module de réécriture d’URL à partir du Panneau de configuration, puis réinstaller le module. Ce problème peut se produire après une mise à niveau importante du système.
Vérifiez la configuration de votre pool d’applications, corrigez-la si nécessaire, puis réessayez.
Le pool d’applications peut être configuré pour une version d’ASP.NET qui ne correspond pas à votre projet Visual Studio. Mettez à jour la version ASP.NET dans le pool d’applications et redémarrez-le. Pour plus d’informations, consultez IIS 8.0 avec ASP.NET 3.5 et ASP.NET 4.5.
Par ailleurs, si les informations d’identification du mot de passe ont changé, vous devez peut-être les mettre à jour dans votre pool d’applications ou votre site web. Dans le pool d’applications, mettez à jour les informations d’identification dans Paramètres avancés > Modèle de processus > Identité. Pour le site web, mettez à jour les informations d’identification dans Paramètres de base > Se connecter en tant que.... Redémarrez votre pool d’applications.
Vérifiez que votre dossier Application web a les autorisations appropriées.
Veillez à accorder à IIS_IUSRS, IUSR ou l’utilisateur spécifique associé au pool d’applications des droits de lecture et d’exécution sur le dossier Application web. Corrigez le problème et redémarrez votre pool d’applications.
Vérifiez que la version correcte d’ASP.NET est installée sur IIS.
Des versions différentes d’ASP.NET sur IIS et dans votre projet Visual Studio peuvent entraîner ce problème. Vous devrez peut-être définir la version de l’infrastructure dans web.config. Pour installer ASP.NET Core sur IIS, consultez Installer ASP.NET Core sur Windows Server ou, pour ASP.NET, Installer ASP.NET sur Windows Server. Par ailleurs, consultez IIS 8.0 avec ASP.NET 3.5 et ASP.NET 4.5 ou, pour ASP.NET Core, Héberger sur Windows avec IIS.
Résoudre les erreurs d’authentification si vous utilisez uniquement l’adresse IP
Par défaut, les adresses IP sont supposées faire partie d'Internet et l'authentification NTLM ne s'effectue pas via Internet. Si votre site web est configuré dans IIS pour exiger l’authentification, cette authentification échoue. Pour résoudre ce problème, vous pouvez spécifier le nom de l’ordinateur distant au lieu de l’adresse IP.
Autres causes
Si la configuration IIS n’est pas à l’origine du problème, essayez ces étapes :
Redémarrez Visual Studio avec des privilèges d’administrateur et réessayez.
Certains scénarios de débogage ASP.NET nécessitent des privilèges élevés pour Visual Studio.
Si plusieurs instances de Visual Studio sont en cours d’exécution, rouvrez votre projet dans une instance de Visual Studio (avec des privilèges d’administrateur), puis réessayez.
Si vous utilisez un fichier HOSTS avec des adresses locales, essayez d’utiliser l’adresse de bouclage au lieu de l’adresse IP de la machine.
Si vous n’utilisez pas d’adresses locales, vérifiez que votre fichier HOSTS indique la même URL de projet que dans les propriétés de votre projet, Propriétés > Web > Serveurs ou Propriétés > Déboguer, en fonction du type de projet.
Étapes supplémentaires de résolution des problèmes
Afficher la page
localhost
dans le navigateur sur le serveur.Si IIS n’est pas installé correctement, vous devez obtenir des erreurs quand vous tapez
http://localhost
dans un navigateur.Pour plus d’informations sur le déploiement sur IIS, consultez IIS 8.0 avec ASP.NET 3.5 et ASP.NET 4.5 et, pour ASP.NET Core, Héberger sur Windows avec IIS.
Créez une application ASP.NET basique sur le serveur (ou utilisez un fichier
web.config
de base).Si vous ne pouvez pas faire fonctionner votre application avec le débogueur, essayez de créer une application ASP.NET de base localement sur le serveur, puis essayez de déboguer l’application de base. (Vous pouvez utiliser le modèle MVC ASP.NET par défaut.) Si vous pouvez déboguer une application de base, cela peut vous aider à identifier les différences entre les deux configurations. Recherchez les différences de paramètres dans le fichier
web.config
, comme les règles de réécriture d’URL.