Encore une bug: programmes qui restent dans le gestionnaire !!!

Signaler
Messages postés
107
Date d'inscription
lundi 7 février 2011
Statut
Membre
Dernière intervention
17 février 2018
-
Messages postés
107
Date d'inscription
lundi 7 février 2011
Statut
Membre
Dernière intervention
17 février 2018
-
Bonjour,
J'aurais pu intituler ça: SHBrowseForFolder appelle hpgs2wnf.exe !!!!!
Depuis quelques temps j'observais (Windows XP version familiale) un autre phénomène bizarre.
1.- j'avais des programmes qui après avoir cliqué sur EXIT ou sur la croix ne s'arrêtaient plus (la fenêtre disparaissait normalement mais l'appli restait à ne rien faire dans le gestionnaire)
2.- En y regardant de plus près je m'aperçois qu'en fait le phénomène se produit chaque fois que, avant de terminer l'appli, j'ai cliqué sur un bouton PARCOURIR pour chercher un répertoire (appel à SHBrowseForFolder)
3.- Dans un deuxième temps je m'aperçois que lorsque mon appli se termine (sortie de l'appli sur le dernier return) ça n'est pas mon appli qui disparaît du gestionnaire mais un processus qui n'a rien à voir: hpgs2wnf.exe !!!
4.- J'investigue de plus près et je m'aperçois que si avant de sortir de mon appli, je tue manuellement le processus hpgs2wnf.exe dans le gestionnaire, alors mon appli se termine normalement (quand je clique sur la croix, elle disparaît du gestionnaire)
5.- Je regarde encore d'un peu plus près comment se comporte ce processus hpgs2wnf.exe que je ne connais pas, mais qui, a priori, vient de chez HP et je constate:
- que ce processus est actif dans le gestionnaire dès le lancement de l'ordi
- que si je le tue dans le gestionnaire, il réapparaît chaque fois que dans mes applis je passe sur la fonction SHBrowseForFolder (fonction Parcourir)
- que si je ne le re-tue pas après être passé sur SHBrowseForFolder, mon appli reste dans le gestionnaire lorsque je la termine (clic sur la croix) bien que sa fenêtre disparaisse normalement.
- et que évidemment si je le tue, avant de cliquer sur la croix de mon appli, mon appli se termine normalement et sort du gestionnaire.
- Et tout ceci de manière systématique
Avant de désinstaller hpgs2wnf.exe de mon ordi je ne sais pas trop encore comment, j'aurais voulu savoir si quelqu'un a déjà observé ce type de phénomène et aurait une explication rationnelle.
hpgs2wnf.exe se trouve sous c:\Program Files\Helwet-Packard\HP Share-to-Web\
et évidemment j'ai des imprimantes HP ainsi qu'un scanner HP.
Toujours pour les sceptiques, voici ci-dessous un programme de test réduit à sa plus simple expression qui permet de s'en rendre compte (à condition évidemment d'avoir sur son micro le fameux hpgs2wnf.exe à l'adresse que je viens d'indiquer)
Le test est facile à faire après avoir compilé le programme, vérifier si hpgs2wnf.exe se trouve déjà dans le gestionnaire, si oui le tuer.
Lancer le programme de test, cliquer sur le bouton : "choisir un répertoire", des messages vont s'afficher et vous allez vous apercevoir que hpgs2wnf.exe réapparaît dans le gestionnaire entre les messages 1 et 2, c'est à dire sur la fonction: SHBrowseForFolder.
Aller jusqu'au bout (clic sur le message 3), ensuite deux solutions:
- soit vous cliquez tout de suite sur la croix pour fermer le programme de test et vous allez vous apercevoir que la fenêtre disparaît mais que le programme de test reste dans le gestionnaire, par contre c'est hpgs2wnf.exe qui disparaît du gestionnaire.
- soit vous tuez tout de suite hpgs2wnf.exe du gestionnaire et dans ce cas le programme de test se terminera normalement en cliquant sur la croix (il disparaît du gestionnaire).
Programme de test:
#include <windows.h>
#include <shlobj.h>
LRESULT CALLBACK processmainmess( HWND, UINT, WPARAM, LPARAM);
HINSTANCE n0instance;
MSG message;
BROWSEINFO browse;
LPITEMIDLIST preponse;
CHAR repertory[MAX_PATH];
LPTSTR pchoix="Choisir le répertoire de sortie";
int APIENTRY WinMain( HINSTANCE W_n0inst, HINSTANCE W_n0precinst, LPTSTR W_CmdLine, int W_cdeaffich) // entier signé (32 bits)
{
n0instance = W_n0inst;

WNDCLASS winclassmain;
winclassmain.hInstance = n0instance;
winclassmain.lpszMenuName = NULL;
winclassmain.lpszClassName = "Essai";
winclassmain.hIcon = NULL;
winclassmain.hCursor = LoadCursor(NULL,IDC_ARROW);
winclassmain.hbrBackground =(HBRUSH)(COLOR_WINDOW+1);
winclassmain.style = CS_VREDRAW | CS_HREDRAW;
winclassmain.lpfnWndProc = (WNDPROC)processmainmess;
winclassmain.cbWndExtra = 0;
winclassmain.cbClsExtra = 0;
if ( !RegisterClass( &winclassmain ) )
return( FALSE );
//
HWND Hdlgmain = CreateWindow("Essai", "test", WS_CAPTION | WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 250, 100, NULL, NULL, n0instance, NULL);
if ( !Hdlgmain ) return( FALSE );
ShowWindow( Hdlgmain, W_cdeaffich ); // lancement manuel
UpdateWindow( Hdlgmain ); //
while(GetMessage( &message, NULL, 0, 0))
{
TranslateMessage( &message );
DispatchMessage( &message );
}
return message.wParam;
}
LRESULT CALLBACK processmainmess( HWND winmainkey, UINT IDMsg, WPARAM wParam, LPARAM lParam )
{
switch(IDMsg)
{
case WM_CREATE :
CreateWindow("BUTTON", "Choisir un répertoire", WS_CHILD | WS_VISIBLE | WS_BORDER, 0, 0, 220, 35, winmainkey, (HMENU)1000, n0instance, NULL);
break;
case WM_COMMAND:
switch(LOWORD(wParam))
{
case 1000: // clic sur le bouton choisir un fichier
browse.hwndOwner=winmainkey;
browse.ulFlags=BIF_NEWDIALOGSTYLE;
//browse.pszDisplayName=lastrepertory;
browse.lpszTitle=pchoix;
browse.lpfn=NULL;
browse.iImage=NULL;
//
MessageBox(winmainkey, "1", "je passe", MB_OK); // ************************************************ piège message 1
preponse=SHBrowseForFolder(&browse);
if(preponse==0) break;
//
MessageBox(winmainkey, "2", "je passe", MB_OK); // ************************************************ piège message 2
if(!SHGetPathFromIDList(preponse, repertory)) break; // récupère le chemin du répertoire choisi
MessageBox(winmainkey, "3", "je passe", MB_OK); // ************************************************ piège message 3
//
break;
}
break;
case WM_CLOSE :
MessageBox(winmainkey, "close", "Assistant", MB_OK);
DestroyWindow( winmainkey );
break;
case WM_DESTROY :
MessageBox(winmainkey, "destroy", "Assistant", MB_OK);
PostQuitMessage(0);
break;
case WM_QUERYENDSESSION :
MessageBox(winmainkey, "query", "Assistant", MB_OK);
DestroyWindow( winmainkey );
break;
default :
return DefWindowProc( winmainkey, IDMsg, wParam, lParam );
};
return 0;
}

5 réponses

Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
1
salut,

Si une appli reste dans le gestionnaire des taches, c'est que le thread est encore actif même si aucune interface n'est affichée.

@++
Messages postés
107
Date d'inscription
lundi 7 février 2011
Statut
Membre
Dernière intervention
17 février 2018

Suaf que je suis en discussion avec HP qui a reconnu qu'il y avait bien une bug
A+
Messages postés
1466
Date d'inscription
vendredi 2 janvier 2004
Statut
Modérateur
Dernière intervention
14 février 2014
1
oui, sauf que c'est un bug qui fait que le thread reste actif...
Messages postés
305
Date d'inscription
jeudi 29 avril 2004
Statut
Membre
Dernière intervention
18 janvier 2012

J'ai pas vu de CreateThread dans le code. Et si le thread est correctement lié au process il devrait être kill à la fermeture du process.
Il est aussi possible qu'une fuite mémoire génère ce genre de souchis.... il faut débuger dans tout les cas ...
Messages postés
107
Date d'inscription
lundi 7 février 2011
Statut
Membre
Dernière intervention
17 février 2018

Je signale que j'ai totalement élucidé le problème et que j'ai posté un message spécifique pour ça depuis déjà plusieurs jours. Toutefois le message qui explique disparaît de temps à autre de la liste des messages, aussi je remets ci-dessous le contenu de mes explications:
titre du message qui disparaît et réapparaît de temps en temps: bug des programmes qui restent dans le gestionnaire élucidée
Contenu du message:
Comme je l'ai dit dans un précédent message le problème venait du processus hpqs2wnf.exe de chez HP qui est appelé dès qu'on utilise la fonction de l'API windows: SHBrowseForFolder.
Le phénomène qui se produit comme je l'ai déjà indiqué c'est que lorsqu'on ferme l'appli qui utilise SHBrowseForFolder (c'est à dire la fonction Parcourir pour trouver un répertoire), sa fenêtre se ferme, mais l'appli reste bloquée dans le gestionnaire, par contre c'est hpqs2wnf.exe qui disparaît du gestionnaire.
Après avoir poussé un peu plus loin mes recherches hpqs2wnf.exe a été implanté à l'origine lors de l'installation d'un scanner HP Scanjet 2400, il se trouve donc sur le CD d'installation (fichier: Scanjet2400Series.msi) c'est un programme qui date de avril 2002.
Pour avoir le problème il faut donc avoir un scanner scanjet 2400 avec sa version d'installation d'origine.
HP n'était pas conscient de ce phénomène pour le moins particulier, mais a bien dû se rendre à l'évidence. Le scanjet 2400 n'étant plus soutenu par HP, il ne faut pas compter sur une correction spécifique, mais avant d'arrêter le suivi de ce scanner HP a inséré toutes les mises à jour dans une version globale qui gère à la fois le 2400 et le scanjet G2410.
Cette version (HP Scanjet G2410 and 2400) peut être téléchargée sur le site de HP, elle n'utilise plus le processus hpqs2wnf.exe, mais maintenant le processus hpqSRmon.exe (août 2008) qui ne pose plus de problème.
Je viens de tester, les appli qui utilisent SHBrowseForFolder se terminent normalement.