Pas 100% on-topic, même si le problème est en liaison avec un
développement en cours ...
Lorsque je clique une image depuis l'explorateur, "Aperçu des images et
des télécopies" (prg par défaut pour les extensions graphiques) chargent
le CPU à +60% et mets 5 à 10 sec. pour ouvrir l'image (même un petit jpg
de 100ko)
Lorsque depuis Internet Explorer (6.0.3790) j'enregistre une image d'une
page via le menu contextuel, explorer monte également la charge CPU à
60-70% et mets 5 à 10 sec. pour enregistrer l'image.
Avez-vous expérimenté ce type de problème et trouvé un remède ?
(la machine a plein de RAM, n'est pas ralentie/lente pour toute autre
opération comparable y compris manipulation des mêmes images depuis
d'autres soft ou enregistrement depuis FireFox; OS: WS 2003).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
marco
Sylvain wrote:
Pas 100% on-topic, même si le problème est en liaison avec un développement en cours ...
Lorsque je clique une image depuis l'explorateur, "Aperçu des images et des télécopies" (prg par défaut pour les extensions graphiques) chargent le CPU à +60% et mets 5 à 10 sec. pour ouvrir l'image (même un petit jpg de 100ko)
Lorsque depuis Internet Explorer (6.0.3790) j'enregistre une image d'une page via le menu contextuel, explorer monte également la charge CPU à 60-70% et mets 5 à 10 sec. pour enregistrer l'image.
Tu as regardé avec des softs comme HijackThis s'il y a des DLL de shell extension ou en service ?
Sylvain wrote:
Pas 100% on-topic, même si le problème est en liaison avec un
développement en cours ...
Lorsque je clique une image depuis l'explorateur, "Aperçu des images et
des télécopies" (prg par défaut pour les extensions graphiques) chargent
le CPU à +60% et mets 5 à 10 sec. pour ouvrir l'image (même un petit jpg
de 100ko)
Lorsque depuis Internet Explorer (6.0.3790) j'enregistre une image d'une
page via le menu contextuel, explorer monte également la charge CPU à
60-70% et mets 5 à 10 sec. pour enregistrer l'image.
Tu as regardé avec des softs comme HijackThis s'il y a des DLL de shell
extension ou en service ?
Pas 100% on-topic, même si le problème est en liaison avec un développement en cours ...
Lorsque je clique une image depuis l'explorateur, "Aperçu des images et des télécopies" (prg par défaut pour les extensions graphiques) chargent le CPU à +60% et mets 5 à 10 sec. pour ouvrir l'image (même un petit jpg de 100ko)
Lorsque depuis Internet Explorer (6.0.3790) j'enregistre une image d'une page via le menu contextuel, explorer monte également la charge CPU à 60-70% et mets 5 à 10 sec. pour enregistrer l'image.
Tu as regardé avec des softs comme HijackThis s'il y a des DLL de shell extension ou en service ?
Sylvain
marco wrote on 22/05/2007 08:33:
Tu as regardé avec des softs comme HijackThis s'il y a des DLL de shell extension ou en service ?
oui, le système est globalement "propre" mais certains répertoires (dont le bureau) ont un comportement anormal.
par exemple, le même jpeg de 20ko s'ouvre immédiatement (avec "Aperçu...") depuis un répertoire mais va mettre 10 sec depuis un autre; ou encore certains rép. ayant contenu des images mettent plusieurs sec. à s'ouvrir alors qu'ils sont vides et d'autres contenant plus de 20.000 jpg s'ouvre immédiatement (moins d'1 sec.).
tous les rép. sont parcourus en mode "détails" (4 colonnes de base: nom, taille, type, modif.) et la mémorisation des paramètres d'affichage de chaque dossier est déactivée. je sèche !!
Sylvain.
marco wrote on 22/05/2007 08:33:
Tu as regardé avec des softs comme HijackThis s'il y a des DLL de shell
extension ou en service ?
oui, le système est globalement "propre" mais certains répertoires (dont
le bureau) ont un comportement anormal.
par exemple, le même jpeg de 20ko s'ouvre immédiatement (avec
"Aperçu...") depuis un répertoire mais va mettre 10 sec depuis un autre;
ou encore certains rép. ayant contenu des images mettent plusieurs sec.
à s'ouvrir alors qu'ils sont vides et d'autres contenant plus de 20.000
jpg s'ouvre immédiatement (moins d'1 sec.).
tous les rép. sont parcourus en mode "détails" (4 colonnes de base: nom,
taille, type, modif.) et la mémorisation des paramètres d'affichage de
chaque dossier est déactivée.
je sèche !!
Tu as regardé avec des softs comme HijackThis s'il y a des DLL de shell extension ou en service ?
oui, le système est globalement "propre" mais certains répertoires (dont le bureau) ont un comportement anormal.
par exemple, le même jpeg de 20ko s'ouvre immédiatement (avec "Aperçu...") depuis un répertoire mais va mettre 10 sec depuis un autre; ou encore certains rép. ayant contenu des images mettent plusieurs sec. à s'ouvrir alors qu'ils sont vides et d'autres contenant plus de 20.000 jpg s'ouvre immédiatement (moins d'1 sec.).
tous les rép. sont parcourus en mode "détails" (4 colonnes de base: nom, taille, type, modif.) et la mémorisation des paramètres d'affichage de chaque dossier est déactivée. je sèche !!
Sylvain.
Sylvain
Sylvain wrote on 21/05/2007 23:21:
"Aperçu des images et des télécopies" mets 5 à 10 sec. pour ouvrir l'image
ce temps semble être pris par la fonction 125 (ordinal 125) de BrowseUI.dll (6.0.3790.630).
est-ce que cela évoque des pistes ?
Sylvain.
Sylvain wrote on 21/05/2007 23:21:
"Aperçu des images et des télécopies"
mets 5 à 10 sec. pour ouvrir l'image
ce temps semble être pris par la fonction 125 (ordinal 125) de
BrowseUI.dll (6.0.3790.630).
ce temps semble être pris par la fonction 125 (ordinal 125) de BrowseUI.dll (6.0.3790.630).
est-ce que cela évoque des pistes ?
ord. 125 = SHParseIECommandLine()
Sylvain
Christian ASTOR wrote on 22/05/2007 21:29:
ord. 125 = SHParseIECommandLine()
ok merci de l'info mais une API non documentée de plus.
quel sous-process ce parsing invoque ? le mystère reste. je ne peux pas croire qu'un parsing d'un pathname requiert 10s.
par ailleurs je me suis codé un viewer de remplacement à "Apercu ..." et celui-ci reçoit le pathname sans aucun délai quelque quoi le dossier source et son contenu. je me demande bien à quoi l'original s'amuse bêtement et inutilement à perdre son temps.
Sylvain.
Christian ASTOR wrote on 22/05/2007 21:29:
ord. 125 = SHParseIECommandLine()
ok merci de l'info mais une API non documentée de plus.
quel sous-process ce parsing invoque ? le mystère reste.
je ne peux pas croire qu'un parsing d'un pathname requiert 10s.
par ailleurs je me suis codé un viewer de remplacement à "Apercu ..." et
celui-ci reçoit le pathname sans aucun délai quelque quoi le dossier
source et son contenu. je me demande bien à quoi l'original s'amuse
bêtement et inutilement à perdre son temps.
ok merci de l'info mais une API non documentée de plus.
quel sous-process ce parsing invoque ? le mystère reste. je ne peux pas croire qu'un parsing d'un pathname requiert 10s.
par ailleurs je me suis codé un viewer de remplacement à "Apercu ..." et celui-ci reçoit le pathname sans aucun délai quelque quoi le dossier source et son contenu. je me demande bien à quoi l'original s'amuse bêtement et inutilement à perdre son temps.
Sylvain.
Christian ASTOR
Sylvain wrote:
Christian ASTOR wrote on 22/05/2007 21:29:
ord. 125 = SHParseIECommandLine()
ok merci de l'info mais une API non documentée de plus.
quel sous-process ce parsing invoque ? le mystère reste. je ne peux pas croire qu'un parsing d'un pathname requiert 10s.
Vu que ça ne fait rien d'autre que de parser les switches (KB178058), cela me parait étonnant que ça soit cette API qui coince...
Sylvain wrote:
Christian ASTOR wrote on 22/05/2007 21:29:
ord. 125 = SHParseIECommandLine()
ok merci de l'info mais une API non documentée de plus.
quel sous-process ce parsing invoque ? le mystère reste.
je ne peux pas croire qu'un parsing d'un pathname requiert 10s.
Vu que ça ne fait rien d'autre que de parser les switches (KB178058),
cela me parait étonnant que ça soit cette API qui coince...
