Discussion :

[nico1492]

Bonjour,

J'utilise VS2022 (17.6.5) et un projet en .NET Framework 4.7.2.

J'utilise depuis des années une méthode pour déboguer mon projet de type service windows lié à ma solution dès le démarrage (uniquement en mode debug) en y insérant la commande suivante dans la méthode OnStart du service :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
#if DEBUG
System.Diagnostics.Debugger.Launch();
#endif

Cela me permet d'avoir lorsque je debug d'office la possibilité de lancer le debugger Just-in-time (ou pas...) :



Je réponds oui et d'habitude, après avoir validé le lancement en tant qu'admin, j'ai la fenêtre de sélection de l'instance Visual Studio que je veux choisir, quelque chose de ce style (avec VS 2022 en ce qui me concerne) :



Au lieu de ça, j'ai ce message :


Selon moi l'important du message est "L'utilisateur connecté n'avait pas accès pour déboguer l'application défectueuse", puisque le reste ne fait que retranscrire mon exception simulée par le code.

Or :
- Je suis bien en tant qu'administrateur, donc je ne vois pas quel droit je pourrais avoir de plus (le message faisant penser à des problème de sécurité)
- peu importe le user avec lequel le service est lancé (service local ou user de l'ad), le message apparait

Précision : les capture que vous voyez sont d'un service que j'ai créé de toutes pièces pour tester, j'obtiens les mêmes problèmes que sur ma solution.

J'ai testé :
- désinstall/réinstall VS2022 => idem
- Réinstallation de Windows 11 (en conservant données utilisateur) => idem
- Utilisation d'un nouvel user en dehors de l'ad qui est admin local => idem
- Installation de Windows 11 sur Virtual Box + installation VS2022 deussus pour exécuter mon service de test => miracle, cela fonctionne

J'ai donc la sensation que cela provient du combo données utilisateur/pc local : mais j'avoue que je ne comprends pas ce qu'il se passe.
J'ai fait des recherches sur le message explicitement mais je n'ai rien trouvé de parlant.

J'ai trouvé quelques vieux articles qui parlent de stratégie de sécurité où il faudrait autoriser un user à débugger mais ça ne semble plus d'actu sous les systèmes Windows récents. D'autant que côté user de mon coté, rien ne semble avoir changé et je n'avais jamais eu le problème auparavant

Si une âme charitable aurait quelques tips à me donner, j'en serait très soulagé car je sèche littéralement !

Merci

Edit : je me permet d'ajouter que même en tentant de laisser le service démarrer normalement (je choisi "non" lorsque le JIT me propose de débuger), puis en essayant de rattacher le processus au débogage dans Visual Studio, j'obtiens également une erreur :


Et pourtant VS est lancé en tant qu'admin...

[Gluups]

Bonjour,

Juste pour être sûr ...
Tu as bien fait les manips pour exécuter l'application avec élévation de privilèges ?

Avec Windows XP, un administrateur avait obligatoirement les droits.
Avec Windows 10, il les a seulement si il les demande, ce qui parfois peut éviter des choses fâcheuses.

[nico1492]

Bonjour et merci de répondre

J'étais peut être pas clair mais le JIT se lance bien en tant qu'admin en élévation de privilèges, et quant au service je lance services.msc en tant qu'admin (même si côté services windows je ne suis pas sûr que cela ai un impact) Je pense que ça a son importance côté app classique mais moins sur les services windows

[umfred]

le compte utilisateur qui lance le débogage (1ere instance de VS2022) est le même utilisateur que le compte administrateur que le JIT demande pour l'élévation? (je crois que tu as répondu à l'affirmative à cette question)

Le projet est en local sur le PC ?

Tu as essayé de lancer le projet à déboguer "en tant qu'administrateur" dès le début (donc avec élévation des droits aussi pour la 1ère instance) ?

[Pol63]

lu en diagonale, en debug sur ta machine c'est mieux de lancer un service en console plutot que de lancer en service et de s'attacher quand il plante
(#if debug console.readkey après avoir appelé ce qu'il faut #else service.run)

[nico1492]

lu en diagonale, en debug sur ta machine c'est mieux de lancer un service en console plutot que de lancer en service et de s'attacher quand il plante
(#if debug console.readkey après avoir appelé ce qu'il faut #else service.run)

Je vais essayer de procéder comme ça et je te fais un retour

[nico1492]

lu en diagonale, en debug sur ta machine c'est mieux de lancer un service en console plutot que de lancer en service et de s'attacher quand il plante
(#if debug console.readkey après avoir appelé ce qu'il faut #else service.run)

En reprenant ta suggestion d'intervenir en mode console, j'ai fouillé sous un autre angle les méandre des Internets et j'ai trouvé cet article : https://www.codeproject.com/Tips/261...ervice-Without

C'est un workaround acceptable pour moi et je peux de cette manière démarrer le débugage dès le départ en partant de visual studio sans utiliser JIT en appelant directement la méthode appelée OnStart du service.

Je met le sujet en résolu même si le côté sécurité du JIT reste un mystère sur mon poste...

Merci pour vos réponses !

[nico1492]

le compte utilisateur qui lance le débogage (1ere instance de VS2022) est le même utilisateur que le compte administrateur que le JIT demande pour l'élévation? (je crois que tu as répondu à l'affirmative à cette question)

Oui

Le projet est en local sur le PC ?

Oui aussi

Tu as essayé de lancer le projet à déboguer "en tant qu'administrateur" dès le début (donc avec élévation des droits aussi pour la 1ère instance) ?

Que veux-tu dire, via une sorte de app.manifest sur le service ?