|
|
Mon débogueur ne marche pas: que faire ? Auteur: MinKwan Park
Traduction/adaptation:
Frédéric De Lène
Mirouze (amethyste16@hotmail.com) |
|
|
|
|
|
Je remercie Min Kwan Park
d'avoir accepté que je traduise cet article extrait de son blog. Vous trouverez
le texte originel ici:
http://blogs.msdn.com/mkpark/articles/86872.aspx
On trouve également une version
Word dans différents endroits, mais celle-ci est plus ancienne.
Ce document récapitule une
quantité d'informations sur le thème:
Le débogueur ne fonctionne pas,
que faire?
Il a été écrit en collaboration
avec l'équipe responsable du débogueur chez Microsoft, c'est donc un document
précieux.
J'ai essayé de faire une
traduction aussi fidèle que possible, donc en cas de doute, le texte d'origine
seul fera foi. Un des problèmes rencontrés est la
traduction en français des messages d'erreur. J'ai fais de mon mieux pour
reproduire le problème. Lorsque je fournis la version US du message en plus de
la traduction c'est que je n'ai pu accéder à un message en français. C'est un problème que j'avais déjà
soulevé en son temps et je persiste à penser que chaque message d'erreur aurai du être accompagné par un code d'erreur spécifique. Je ne me suis pas contenté de
traduire le texte, j'ai également fait un travail d'adaptation en ajoutant des
copies d'écran et des informations bibliographiques afin de clarifier certaines
procédures.
Je voudrai aussi signaler ce chat
sur le débogage avec VS .NET:
http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_062002b.aspx
Il date toutefois de Juin 2002!
Durant les derniers mois, j'ai eu
affaire à de nombreux utilisateurs à l'intérieur et à l'extérieur de Microsoft
avec des problèmes de débogage. J'ai remarqué que certains problèmes sont
récurrents et aurai pu être résolu simplement si l'utilisateur avait fait le
bon diagnostic.
C'est pourquoi j'ai écrit ce
document afin de fournir des informations utiles pour résoudre les problèmes de
débogueur.
Ce document contient:
Je remercie tout particulièrement
l'équipe responsable du débogueur VC# chez Microsoft qui m'ont aidés à rédiger
ce document.
(Passage non traduit)
Si vous vous intéressez à VS 8.0
Béta 1, vous pouvez consulter le document suivant:
http://blogs.msdn.com/mkpark/articles/200151.aspx
Remarque:
Si vous ne trouvez pas votre
message d'erreur dans cette section, consultez aussi celles consacrées aux
problèmes généraux ou au débogage à distance.
Scénario:
L'erreur se produit lorsque vous
lancez le projet depuis VS.
Il y a 3 cas de figure:

IIS n'est pas configuré pour
L'authentification intégrée Windows. Ouvrez dans l'administration IIS la page
"Méthode d'authentification" puis cochez "Authentification
intégrée Windows".


Vérifiez si l'option "Activer
les connexions HTTP persistantes" est cochée.


On voit parfois aussi le code
d'erreur "0x8013134b".
Il est possible que vous ayez deux
versions différentes de

Depuis la console DOS allez dans
le répertoire:
C:\WINDOWS\Microsoft.NET\Framework\<version
de
Puis lancez la commande:
aspnet_regiis.exe –i
Scénario:
L'erreur se produit lorsque vous lancez le projet depuis
VS.
|
Unable to start debugging on the web server. You do not have
permissions to debug the server. Verify that you are a member of the
‘Debugger Users’ group on the server. Would you like to disable future
attempts to debug ASP.NET pages for this project? |
Vérifiez que l'option "Authentification
Windows intégrée" est activée (voir erreur précédente). Vous avez
probablement uniquement activé "Authentification de base".
Si vous avez activé " Authentification
Windows intégrée", vous devez vérifier que votre compte a un contrôle
complet sur le répertoire IIS.

Vous avez créé le projet Web avec
un nom de machine complet plutôt que localhost (par exemple: nommachine.nomdomaine.quelquechose),
le site Web est alors reconnu comme étant dans la zone de sécurité Internet.
Par conséquent les paramétrage par défaut de IE vont
avoir un impact sur la façon de vous connecter. Vous devez alors signaler votre
site comme site de confiance.
Il est toujours préférable de
créer un projet avec uniquement le nom de la machine.
Si Devenv (7.1) tourne sous
Windows 2003 et est configuré comme serveur distant, vous pouvez alors ajouter
la machine distante dans la liste des sites de confiance. Le paramètre de
sécurité par défaut d’IE est "Connexion automatique uniquement dans la
zone intranet".

Vous pouvez aussi sélectionner
"Demander le nom d'utilisateur et le mot de passe". Pour des
raisons de sécurité n'oubliez pas de remettre les paramètres dans leur
configuration par défaut une fois terminé le débogage.
Si le problème subsiste même après
avoir accordé des droits administrateur, donné tout contrôle sur les
répertoires inetpub et essayé toutes les solutions précédente, alors il
est possible que votre compte soit corrompu.
Vous
devez demander à votre administrateur de recréer votre compte à l'identique.
C'est fastidieux!
Scénario:
L'erreur se produit lorsque vous
lancez le projet depuis VS.

Votre application Web n'a pas de
nom d'application. Utilisez IIS MMC et vérifiez les propriétés de votre
application Web.


Si votre partition est en
NTFS vérifiez qu’ASPNET dispose des droits en lecture et écriture sur wwwroot
ou bien les répertoires de votre application.

Vérifiez que votre site Web est
configuré pour permettre le débogage.
Pour cela inscrivez "debug=true"
dans le fichier web.config du site.
Le verbe DEBUG n'est peut-être pas
associé à l'extension ISAPI.


Si vous utilisez VS 7.1.
Regardez dans IIS MMC si le site
Web par défaut est lié à une adresse IP statique ET NON PAS "Toutes non
attribuées".

Dans ce cas, lancez votre projet
avec "http://<IP address>" plutôt que "http://<server
name>".
Il faudra également vérifier que
l'adresse IP est considérée comme un site de confiance et que la connexion
automatique est activée pour les sites de confiance.

Pour les nouveaux projets vous
devez donner directement l'adresse IP comme nom de projet.
Pour les projets existants, il
suffit d'éditer le fichier .sln:
|
Microsoft Visual Studio Solution File, Format Version 8.00 Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") =
"WebApplication6", "http://localhost/WebApplication6/WebApplication6.csproj",
"{98D3C7DD-64FA-4257-83A5-33E851317C96}"
ProjectSection(ProjectDependencies) = postProject
EndProjectSection EndProject EndProject Global
… EndGlobal |
Ainsi que le fichier .webinfo:
|
VisualStudioUNCWeb> <Web URLPath = "http://localhost/WebApplication6/WebApplication6.csproj"
/> </VisualStudioUNCWeb> |
Et faire les modifications.
Si vous utilisez Windows XP Pro ou
bien Windows 2000 Pro vous n'avez peut-être pas respecté l'ordre d'installation
entre VS et IIS. Si vous installez VS avant IIS, ce message peut apparaître.
Dans ce cas il suffit
d'enregistrer "aspnet_isapi.dll" à l'aide de "aspnet_regiis.exe
–i"
Peut-être avez vous installé
l'outil "IIS Lockdown".
http://www.microsoft.com/technet/security/tools/locktool.mspx
Dans ce cas, recherchez le fichier
"urlscan.ini" et ajoutez DEBUG (attention à la casse) dans la
section [allowverbs].
Si votre serveur est un contrôleur
de domaine et que votre projet est créé avec un nom machine autre qu'un nom de
domaine complet, modifiez l'URL du projet de sorte que le nom du serveur soit
un nom de domaine complet.
Si vous changez la valeur de
“<httpRuntime maxRequestLength="#########" />” dans web.config
vérifiez que la valeur n'est pas trop élevée. L'unité par défaut est le Ko, pas
l'octet en particulier. Cela pourra causer des problèmes avec le débogueur.
Scénario:
Vous avez lancé le débogage avec
F5 et le débogage semble démarrer correctement, IE est lancé comme prévu.
Toutefois il est impossible d'atteindre les points d'arrêt dans le code behind.
Vérifiez que le débogage
ASP est activé dans les propriétés du projet.

Dans le cas d'un projet VB.NET le
formulaire est le suivant:

Vérifiez que
Une fois l'application lancée en
mode débogage, ouvrez le menu Déboguer/Fenêtre/Modules
Voici sur un exemple à quoi les
choses ressemblent:

Vous n'êtes peut être pas membre
du groupe "Utilisateurs du débogueur".
Il existe différentes raisons à ce
problème. La plus classique est que le cache a été activé dans web.config.
Si
vous voyez quelque chose comme:
<add
key="<nom du projet
web”.Web.EnablePageCache"
value="True"
/>
Placez l'attribut à False
et rafraîchissez la page.
|
Unable to start debugging on the web server. The debugger is not
properly installed. Run setup to install or repair the debugger. Would you
like to disable future attempts to debug ASP.NET pages for this project? |
Essayez de déboguer avec un projet
d'application Console.
Si vous observez un message disant
qu'il est impossible de se mettre en débogage, alors le Framework .NET est
probablement mal installé.
Vous devez réenregistrer
mscordbi.dll en exécutant la commande " regsvr32 mscordbi.dll ".
|
Access is denied, Verify that you are an administrator or a member of
the ‘Debugger Users’ group on the machine you
are trying to debug. After being added to the “Debugger Users” group, you
must log off and log back on for the setting to apply. |
Solution 1
Vous n'êtes peut –être pas membre
du groupe "utilisateurs du débogueur" sur votre machine. Vous
devez y ajouter votre compte.
La procédure est la suivante:
Solution 2
Si votre machine a les services
pack XP SP2 ou W2K SP4 vérifiez que le privilège "SEImpersonate"
a été alloué au compte ASPNET.
Vous pouvez être membre du groupe
"Utilisateurs du débogueur", mais ne pas avoir le droit de
déboguer un processus aspnet. Cela arrive parce que vous n'êtes pas le
compte ASPNET ou bien vous n'êtes pas administrateur.
Vérifiez que votre compte est
administrateur ou bien qu’ASP.NET tourne sous le même compte que vous.
Le service de débogage de
Vous trouverez plus d'explications
dans le blog suivant:
http://www.dotnetguru2.org/amethyste/index.php?p=194&more=1&c=1&tb=1&pb=1
Si vous ne pouvez être
administrateur, mais êtes sous Windows 2003 avec IIS 6.0, il existe un
contournement dont les détails sont donnés dans la section 6.2 de ce document:
http://msruniv.corp.bcentral.com/shared%20documents/dotNETDevSvrDEVELOPER2003.doc .
Vous ne pouvez déboguer avec un
fichier inclus dans un ASPX. Ce cas de figure arrive typiquement lorsqu'un
projet a migré de ASP standard vers ASP .NET.
Si
vous avez inclus un fichier avec:
"<!--#include file =
"nom fichier"-->"
Le problème peut se produire.
Essayez plutôt:
"<!--#include
virtual="nom fichier"-->".
Après avoir changé votre mot de
passe, vous devez vous reconnecter à nouveau pour déboguer ASP.NET.
Après avoir installé le service
pack 4 de Windows 2000, si le débogage ne marche pas en pressant F5 et
s'affiche le message "Accès refusé".
Il faut réenregistrer
aspnet_isap.dll avec la commande:
regsvr32
–i aspnet_isap.dll
Dans Visual Studio vous devez
décidez de deux choses avant de pouvoir déboguer.
Le simple fait d'appartenir au
groupe "utilisateurs du débogueur" vous donne automatiquement
le droit de vous connecter à MDM.exe (Machine Debug Manager). Il s'agit
d'un service installé par Visual Studio et certains autres produits tels Office
qui permet de déboguer un processus, qu'il soit local ou distant.
On trouvera plus d'informations ici:
http://www.dotnetguru2.org/amethyste/index.php?p=194&more=1&c=1&tb=1&pb=1
Vous pourrez alors voir les
processus en cours de votre machine et déboguer vos propres processus.
Ensuite savoir si vous pouvez ou
non déboguer des processus lancés par un autre compte dépend de vos privilèges.
Pour déboguer les processus natifs
d'un autre compte il faut disposer de SeDebug.
Pour les processus managés d'un
autre compte il faut être administrateur sur la machine.
Ces restrictions peuvent poser des
problèmes de sécurité. Il existe d'une certaine façon un contournement:
utiliser Cassini. Il s'agit d'une version légère d'un serveur ASP.NET.
Il est donc possible de développer
sous Cassini et plus tard de basculer sous IIS.
Cassini est disponible ici:
http://www.asp.net/Projects/Cassini/Download
|
Au démarrage du débogage
ASP.NET: Error while trying to run project: Unable to start debugging on the
web server. There is no managed code running in the process. In order to
attach to a process with the .NET debugger, managed code must be running in
the process before attaching. Lors du débogage du code managé: Error while trying to run project: Unable to start debugging Unable to start program <path of debuggee> The .NET debugger has not been installed properly. The most probable
cause is that mscordbi.dll is not properly registered. Click Help for more
information on how to repair the .NET debugger. |
Dans ce scénario on est sous
Visual Studio 7.1.
Si vous avez installé VS 7.0 et VS
7.1 ensemble puis désinstallé VS 7.0, vous devez réparer l'installation du CLR
1.1.

Ce problème peut arriver lorsque
vous avez installé deux versions du framework. Dans ce scénario IIS pointe sur
une version et VS sur une autre.
Vous devez alors remapper :
"%windir%\Microsoft.NET\Framework\version\aspnet_regiis.exe" -i
Et enregistrer aspnet_isapi.dll :
regsvr32 %windir%\Microsoft.NET\Framework\version\aspnet_isapi.dll
Les scénarios sont basés sur des
projets Console.
|
Error while trying to run project: Unable to start debugging.
Unable to start program ‘<path of your debuggee>’ The debugger is not properly installed. Run setup to install or repair
the debugger. |
mscordbi.dll n'est pas
correctement enregistré. Il suffit de le réenregistrer manuellement.

Vérifiez que le service MDM.exe a
démarré. Vérifiez que vous êtes membre du groupe des utilisateurs du déboguer
ou bien administrateur.
On peut se mettre en mode
débogage et le déboguer démarre correctement. Toutefois il est impossible
d'atteindre les points d'arrêt.
Il faut vérifier que diasymreader.dll
soit bien enregistré:
Note:
Ce fichier semble installer des
composants pour le débogage à distance, mais je n'ai pu trouver beaucoup de
précisions à son sujet.
Vous vous attachez à un processus
en code natif avant qu'il lance le code managé. Le débogage de ce code managé
ne s'active pas.
Attachez le processus seulement
lorsque le code managé est lancé
Attachez le processus en mode
Interop. Dans ce cas il est inutile de s'attacher au processus une fois que le
code CLR est invoqué.

(Cocher à la fois Native
et Common Language Runtime)
Vous lancez le débogage d'un code
managé, mais le débogueur ne répond pas.
Vérifiez que le service ".NET
framework support" est arrêté et désactivé (juste l'arrêter n'est pas
suffisant).
Si vous ne trouvez pas ce service,
essayez en désactivant le service Administration IIS.
Considérons par exemple le code
suivant:
|
string someStr;
someStr = "Une valeur";
if(someStr ==
null)
{
Console.WriteLine("Que se passe t'il?");
}
try
{
}
catch(Exception e)
{
} |
Si vous déboguez pas à pas
ce code, vous verrez qu'une fois arrivé à l'instruction if, le pointeur se
déplace vers le corps du if (Console.WriteLine…).
Il ne s'agit pas d'un bug, mais
d'un comportement connu du bloc try…catch.(no comment
!!!)
Cela n'empêche pas le code de
fonctionner, c'est juste un problème avec le débogueur.
Note:
Le problème ne se produit pas avec
Vous n'avez pas recompilé votre
application. Le fichier .pdb utilisé par le débogueur correspond à une
ancienne version de l'application.
Le problème arrive typiquement
lorsque l'on retire un projet de la configuration de compilation et oublie de
l'y remettre.
Il n'est en rien spécifique à C#
bien sûr.
Avec les paramètres par défaut, on
ne peut déboguer d'un code client vers un service web en pas à pas détaillé. Le
débogage de la méthode du web service agit comme le mode "Pas à pas
principal".
Le processus ASP.NET
(aspnet_wp.exe ou w3wp.exe sous IIS 6.0) tourne sous le compte ASPNET ou bien
"network service". Aucun de ces comptes ne dispose des
privilèges nécessaires pour accéder à MDM via DCOM.
On doit donc ajouter ces deux
comptes dans le groupe "Utilisateurs du débogueur".
Une fois que l'impersonnalisation
a été activée pour le service Web dans le fichier web.config, il est
impossible de déboguer en mode "Pas à pas détaillé" dans le code du
service Web.
Pour résoudre le problème il faut:
Service1 obj = new Service1();
obj.Credentials = System.Net.CredentialCache.DefaultCredentials;
Si votre service Web utilise le
modèle de thread STA (Single Thread Apartment) et s'il attend un appel
asynchrone tel celui-ci:
Service1
obj = new Service1();
System.IAsyncResult
ar = obj.BeginHelloWorld(new
System.AsyncCallback(Class1.Handle),obj);
while(ar.IsCompleted != true)
{
System.Threading.Thread.Sleep(1000);
}