Hello HFR
 
Depuis quelques mois, je rencontre un truc un peu louche sur une VM de mon home lab.
C'est un serveur web, qui tourne sous Windows Server 2019 (1809 en version 17763.3346)
Il héberge quelques sites que je gère et j'y accède en RDP pour faire les installations / maintenances nécessaires.
Conjointement à ces sites installés, il y a quelques tâches planifiées qui gèrent 2~3 trucs (sauvegarde / suppression de logs, appels ponctuels à des API, détection adresse IP etc...).
C'est une machine qui utilise des comptes locaux uniquement (je n'ai pas de contrôleur de domaine).
 
Le truc bizarre, c'est que depuis quelques mois, j'ai un comportement louche au niveau des processus qui tournent.
Au boot de la machine, une fois tout démarré et stabilisé, y a une centaine de processus qui tournent.
Rapidement, au bout de quelques jours, ce nombre explose :

 
Et quand on regarde le détail, il y a une foutrechiée de dllhost.exe qui occupent sensiblement la même quantité de mémoire, et qui tournent sans s'arrêter :

 
Ce qui m'intrigue, c'est que ces process sont lancés apparemment par l'utilisateur Administrateur, qui est (entre autres, évidemment) utilisé par les susmentionnées tâches panifiées (certaines requièrent les droits d'admin pour s'exécuter).
En configurant les tâches plan pour démarrer "uniquement si l'utilisateur est connecté", je n'ai pas le souci (quand je laisse la session ouverte, obviously).
C'est uniquement quand je demande à exécuter les tâches même si l'utilisateur n'est pas connecté (et que j'entre donc les credentials Administrateur) que ça se produit.
 
Si je n'interviens pas au bout de quelques jours, la RAM arrive rapidement à saturation et le serveur finit par planter par manque de ressources (RAM).
 
Question : est-ce que quelqu'un a déjà entendu parler d'un truc comme ça ? Comment puis-je connaître la ligne de commande qui a invoké chacun de ces processus (pour voir si ça vient de mes appels à moi) ?
 
Question bonus : c'est quoi la meilleure pratique entre :
- laisser une session utilisateur avec les droits d'amin ouverte, et empêcher la tâche plan de tourner si l'utilisateur n'est pas connecté
ET
- fermer ma session admin quand j'ai terminé et cocher la case pour que les tâches plan s'exécutent même si l'admin n'est pas connecté
 
Sachant que dans le 1er cas, ça m'ennuie car ça implique qu'en cas de reboot (ou de fermeture de session), mes tâches ne s'exécutent pas...
 
Merci à vous

Surtout pas l'option 1: faille énorme de sécurité.
 

C'est bien ce qui me semblait aussi
Bon, OK la session est verrouillée (mais pas fermée) donc il faut de toute façon le mot de passe admin pour entrer, mais oui on est d'accord que l'utilisateur étant toujours connecté (session lockée mais ouverte), ça ouvre la porte à pas mal de choses ...
 
Donc la seule vraie (et logique) solution, c'est de fermer la session une fois les actions terminées, et d'autoriser les tâches plan a s'exécuter sans que l'utilisateur ne soit connecté... et donc j'ai l'impression que c'est ça qui me multiplie mes dllhost.exe

Ah ! Du nouveau

Je viens de créer un nouvel utilisateur "taskLauncher" sur la machine, qui sera dédié au lancement des tâches planifiées.
Ca change pas grand chose au process, mais ça me permettra d'identifier si c'est bien les tâches plan en question qui me polluent mes processus....

Bingo !

Du coup, j'en suis sûr maintenant, c'est bien cette tâche planifiée (j'ai utilisé cet utilisateur pour une seule tâche pour le moment) qui pose problème !

La tâche en question appelle à exécuter un script VBS qui a pour rôle d'aller exécuter une commande GET sur une API d'un de mes sites, pour déclencher une action spécifique.
Cette script est exécuté toutes les 5 minutes :

Vous voyez quelque chose qui clocherait et qui empêcherait le script / le processus hôte de terminer son exécution (en supposant que le site soit accessible, et retourne une HTTP 200 en quelques secondes) ?

Question bonus bonus : ai-je besoin des droits d'administrateur pour lancer ce script PowerShell selon vous ?

Merci pour votre aide !

Bon bah c'était bien ça !
 
J'ai remplacé mon script VBS tout pété par une simple ligne dans un script PowerShell en bonne et due forme :
Invoke-WebRequest -Uri "[URL]"
 
La tâche plan appelle donc powershell.exe -file "[chemin vers mon fichier .ps1]".
Au lancement, ça m'ouvre 2 processus "powershell.exe" et "conhost.exe" pendant quelques secondes, et une fois la requête terminée (peu importe le résultat), les process se terminent et les ressources sont libérées !
 
Problème réglé
 
Ca m'apprendra à utiliser des vieux trucs que j'avais sous le coude depuis deeeees années
 
Merci à vous,
Bon week-end HFR  

J’en profite juste pour dire que ton bandeau de cookies est totalement illégal : les phrases du genre « En continuant d'utiliser […], vous consentez à l'usage de ces cookies et des données qu'ils contiennent » ont été maintes fois reconnues invalides au regard du RGPD (que tu te dois de respecter à la lettre, puisqu’il est d’interprétation stricte et qu’il s’impose à tous, du moment que des visiteurs de l’UE sont susceptibles de visiter ton site) : tu n’as aucun droit de déposer des cookies sur les machines des utilisateurs tant que ces derniers n’y ont pas explicitement et volontairement consenti avec un bouton « J’accepte » ; et ils ont le droit et doivent avoir la possibilité, eux, de refuser le dépôt de ces cookies (avec un bouton « Je refuse » ou « continuer sans accepter ») ; et ce, sans que ça ne les pénalise de quelque manière que ce soit pour continuer à utiliser ton site.
 
Bref, ton cookie « ASP.NET_SessionId », on ne doit le voir apparaître qu’après, et seulement après, avoir cliqué sur « J’accepte » ; et jamais en dehors de ce cas, encore moins dès le simple chargement de la page dans le navigateur (comme c’est le cas actuellement, et on n’a aucun moyen de refuser car il est déjà trop tard et le choix n’est même pas proposé).
 
Tu sais quelle amélioration faire sur ton site ce week-end, donc.

 
Merci pour ces infos, je crosstopic avec le TU dédié à Rehost

Heu… Laisse tomber, en fait : j’ai demandé conseil à Aeris, et il m’a confirmé que pour de simples cookies techniques (comme le tien qui n’est qu’un cookie d’authentification), ces obligations n’étaient pas de mise. Si ça avait été un cookie de pistage, ça aurait été différent. Vu comment il a la plainte CNIL facile, pour qu’il trouve le tien encore plus réglo que la loi ne t’y oblige, c’est que tu as vraiment fait les choses bien, en réalité.
 
Bref, là, c’est moi qui ai eu la lecture un peu trop chatouilleuse. Pardon !

 
Ok bon ça me rassure un peu.
Le but étant quand même de faire les choses bien au final.
Et en effet, pas de pistage chez Rehost, ce ne sont réellement que des variables liées au compte utilisateur qui sont déposées.
 
Ceci dit tu soulèves un point intéressant (on a continué un peu la discussion sur le TU Rehost) : ce cookie n'est pas un cookie mandataire au fonctionnement du site. Vu qu'il s'agit d'informations d'authentification purement, lorsqu'on utilise Rehost en mode "invité" (= 100% anonyme), il ne devrait pas y avoir de dépôt.  
Je vais quand même faire une petite passe dans le code de ce côte-là, j'ai peut être glissé une variable technique dans ce cookie là par mégarde (session ID par exemple).
 
Merci en tout cas pour ton aide et tes explications