begin process at 2012 05 28 20:58:16
  Trouver un code source :
 
dans
 
Accueil > Forum > 

C++ & C++ .NET

 > 

Windows

 > 

System

 > 

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


Derniers messages déposésPoser une question dans le forum ou lancer une discussion

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

lundi 27 juin 2011 à 13:12:13 | Encore une bug: programmes qui restent dans le gestionnaire !!!

ArthurAuguste

Membre Club
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;
}
mardi 28 juin 2011 à 01:48:29 | Re : Encore une bug: programmes qui restent dans le gestionnaire !!!

patatalo

Membre Club Administrateur CodeS-SourceS
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.

@++
mardi 28 juin 2011 à 12:06:42 | Re : Encore une bug: programmes qui restent dans le gestionnaire !!!

ArthurAuguste

Membre Club
Suaf que je suis en discussion avec HP qui a reconnu qu'il y avait bien une bug
A+
mardi 28 juin 2011 à 12:36:50 | Re : Encore une bug: programmes qui restent dans le gestionnaire !!!

patatalo

Membre Club Administrateur CodeS-SourceS
oui, sauf que c'est un bug qui fait que le thread reste actif...
vendredi 1 juillet 2011 à 10:07:05 | Re : Encore une bug: programmes qui restent dans le gestionnaire !!!

LA_Tupac

Membre Club
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 ...
vendredi 1 juillet 2011 à 18:44:48 | Re : Encore une bug: programmes qui restent dans le gestionnaire !!!

ArthurAuguste

Membre Club
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.


Cette discussion est classée dans : exe, gestionnaire, winmainkey, winclassmain, hpgs2wnf


Répondre à ce message

Sujets en rapport avec ce message

[mfc c++] evenement entre une dll et un exe [ par wogkiller ] Bonjour,j'ai un programme qui charge dynamiquement des dll, et qui communiquent avec elles en appelant des méthodes dans le sens exe->dll, et qui norm Problème avec GetOpenFileName [ par ArthurAuguste ] Bonjour, J'ai un problème avec GetOpenFileName si et seulement si le fichier que j'ouvre fait plus de 93Ko !!!! Si j'ai fait une erreur de programma bug des programmes qui restent dans le gestionnaire élucidée [ par ArthurAuguste ] 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' sdk et windev [ par frederic67120 ] Bonjour à tous, je viens de récuperer les SDKs (fichiers .dll .h .lib .exe) et je souhaiterais utiliser les fonctions de la dll avec windev16. C'est compiler une source c ou c++ [ par darksool93 ] Bonjour j'ai téléchargé crypcat que j'ai essayé de compiler pour obtenir l'exe avec microsoft 2010 express mais ça me donne pleins d'erreurs. y-a-t-il Inclure fichiers dans .exe [ par didoux95 ] Bonjour à tous, J'ai dans un fichier .rc une liste de fichiers auquels je souhaiterais accéder plus tard. Aprés la compilation les dits fichiers ne s Probleme de creation d'un .exe [WINDEV] [ par Gregoire02 ] Bonjour, J'ai crée un programme mais il m'est impossible de crée un éxecutable. Je travaille sous Windev XIV. La zone avec l'engrenage est grisée ain avoir une application ".exe" à partir d'un projet C++ [ par zaimous ] Bonjour j'ai développer le célèbre jeu africain en c++ ( et ça fonctionne bien ) et maintenant je veux avoir un fichier exécutable qui permet de lance Exe linux en exe windows (programme c++) [ par tiouil ] Bonjour à tous, Je me tourne de nouveau vers vouscar ayant developpé pas mal de jeux en c++ sur linux, j'aimerais les exporter vers en exe windows. A


Nos sponsors


Sondage...

CalendriCode

Mai 2012
LMMJVSD
 123456
78910111213
14151617181920
21222324252627
28293031   

Consulter la suite du CalendriCode

A découvrir



 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 2,652 sec (3)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales