je reprends un projet de namespace extension, qui s'insére sous "Poste
de Travail" dans l'explorateur, et qui avait été réalisé sous 2000 et
pas moyen d'entrer sous debug étant sous 2003.
j'ai essayé les Shut-Down puis Cancel avec CTRL+ALT+SHIFT habituel, cela
tue bien les process explorer, je lance la session debug qui recréé le
bureau mais je ne rentre pas dans mon code lorsque je navige dans Poste
de Travail (parce que ce faisant je lance un 2nd process?).
j'ai essayé également un
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer
DesktopProcess=(dword)1
mais cela ne change rien.
comment debugge-t-on de nos jours ???
(VC6 sous Win2003).
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
Christian ASTOR
Sylvain wrote:
j'ai essayé les Shut-Down puis Cancel avec CTRL+ALT+SHIFT habituel, cela tue bien les process explorer, je lance la session debug qui recréé le bureau mais je ne rentre pas dans mon code lorsque je navige dans Poste de Travail (parce que ce faisant je lance un 2nd process?).
j'ai essayé également un HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer DesktopProcess=(dword)1 mais cela ne change rien.
Même après log off/on, comme indiqué ds la doc ? http://tinyurl.com/odx35
Sylvain wrote:
j'ai essayé les Shut-Down puis Cancel avec CTRL+ALT+SHIFT habituel, cela
tue bien les process explorer, je lance la session debug qui recréé le
bureau mais je ne rentre pas dans mon code lorsque je navige dans Poste
de Travail (parce que ce faisant je lance un 2nd process?).
j'ai essayé également un
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer
DesktopProcess=(dword)1
mais cela ne change rien.
Même après log off/on, comme indiqué ds la doc ?
http://tinyurl.com/odx35
j'ai essayé les Shut-Down puis Cancel avec CTRL+ALT+SHIFT habituel, cela tue bien les process explorer, je lance la session debug qui recréé le bureau mais je ne rentre pas dans mon code lorsque je navige dans Poste de Travail (parce que ce faisant je lance un 2nd process?).
j'ai essayé également un HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorer DesktopProcess=(dword)1 mais cela ne change rien.
Même après log off/on, comme indiqué ds la doc ? http://tinyurl.com/odx35
Sylvain
Christian ASTOR wrote on 19/11/2006 19:06:
j'ai essayé les Shut-Down puis Cancel avec CTRL+ALT+SHIFT habituel, cela tue bien les process explorer, je lance la session debug qui recréé le bureau mais je ne rentre pas dans mon code lorsque je navige dans Poste de Travail (parce que ce faisant je lance un 2nd process?).
Même après log off/on, comme indiqué ds la doc ? http://tinyurl.com/odx35
oui, après tout ce qu'il faut, enfin IMHO.
ma DLL trace des infos en entrée de chaque fonction via OutputDebugString; ces traces apparaissent bien dans dbgview, de plus le debugger de visual est bien "sous contrôle" ("Run" actif, je peux placer mes breakpoints, etc) simplement il ne s'arrète jamais dans *mon* code.
ayant (depuis hier) ajouté à ces traces, le résultat de GetModuleFileName() avec le HINSTANCE reçu par DllMain, je vois que le process utilisé (vu du système) est %system32%verclsid.exe !! ce process appelant point à point toutes mes fonctions exportées.
question 1) c'est quoi cette plaisanterie ? (hormi KB908531) question 2) pourquoi s'en prend-il à *ma* dll alors que je débugge sans souci le sample du Platform SDK 2003 (SampleswinuiShellSampView) ?
Sylvain.
Christian ASTOR wrote on 19/11/2006 19:06:
j'ai essayé les Shut-Down puis Cancel avec CTRL+ALT+SHIFT habituel,
cela tue bien les process explorer, je lance la session debug qui
recréé le bureau mais je ne rentre pas dans mon code lorsque je navige
dans Poste de Travail (parce que ce faisant je lance un 2nd process?).
Même après log off/on, comme indiqué ds la doc ?
http://tinyurl.com/odx35
oui, après tout ce qu'il faut, enfin IMHO.
ma DLL trace des infos en entrée de chaque fonction via
OutputDebugString; ces traces apparaissent bien dans dbgview, de plus le
debugger de visual est bien "sous contrôle" ("Run" actif, je peux placer
mes breakpoints, etc) simplement il ne s'arrète jamais dans *mon* code.
ayant (depuis hier) ajouté à ces traces, le résultat de
GetModuleFileName() avec le HINSTANCE reçu par DllMain, je vois que le
process utilisé (vu du système) est %system32%verclsid.exe !! ce
process appelant point à point toutes mes fonctions exportées.
question 1)
c'est quoi cette plaisanterie ? (hormi KB908531)
question 2)
pourquoi s'en prend-il à *ma* dll alors que je débugge sans souci le
sample du Platform SDK 2003 (SampleswinuiShellSampView) ?
j'ai essayé les Shut-Down puis Cancel avec CTRL+ALT+SHIFT habituel, cela tue bien les process explorer, je lance la session debug qui recréé le bureau mais je ne rentre pas dans mon code lorsque je navige dans Poste de Travail (parce que ce faisant je lance un 2nd process?).
Même après log off/on, comme indiqué ds la doc ? http://tinyurl.com/odx35
oui, après tout ce qu'il faut, enfin IMHO.
ma DLL trace des infos en entrée de chaque fonction via OutputDebugString; ces traces apparaissent bien dans dbgview, de plus le debugger de visual est bien "sous contrôle" ("Run" actif, je peux placer mes breakpoints, etc) simplement il ne s'arrète jamais dans *mon* code.
ayant (depuis hier) ajouté à ces traces, le résultat de GetModuleFileName() avec le HINSTANCE reçu par DllMain, je vois que le process utilisé (vu du système) est %system32%verclsid.exe !! ce process appelant point à point toutes mes fonctions exportées.
question 1) c'est quoi cette plaisanterie ? (hormi KB908531) question 2) pourquoi s'en prend-il à *ma* dll alors que je débugge sans souci le sample du Platform SDK 2003 (SampleswinuiShellSampView) ?
Sylvain.
Sylvain
Sylvain wrote on 19/11/2006 21:13:
question 1) c'est quoi cette plaisanterie ? (hormi KB908531) question 2) pourquoi s'en prend-il à *ma* dll alors que je débugge sans souci le sample du Platform SDK 2003 (SampleswinuiShellSampView) ?
le KB908531 ne cause que d'un process (permanent) verclsid.exe; sur mon 2003 il n'y a qu'un verclsid.dll et aucun process (aucun identifiable) qui utilise cette dll en deamon; leur solution (liste verte etc) est donc inapplicable.
la suppression du patch 908531 (qui vire cette dll) corrige spontanément le problème - le débugger attrape tous les breakpoints - 36h de perdu, merci qui...
Sylvain.
Sylvain wrote on 19/11/2006 21:13:
question 1)
c'est quoi cette plaisanterie ? (hormi KB908531)
question 2)
pourquoi s'en prend-il à *ma* dll alors que je débugge sans souci le
sample du Platform SDK 2003 (SampleswinuiShellSampView) ?
le KB908531 ne cause que d'un process (permanent) verclsid.exe; sur mon
2003 il n'y a qu'un verclsid.dll et aucun process (aucun identifiable)
qui utilise cette dll en deamon; leur solution (liste verte etc) est
donc inapplicable.
la suppression du patch 908531 (qui vire cette dll) corrige spontanément
le problème - le débugger attrape tous les breakpoints - 36h de perdu,
merci qui...
question 1) c'est quoi cette plaisanterie ? (hormi KB908531) question 2) pourquoi s'en prend-il à *ma* dll alors que je débugge sans souci le sample du Platform SDK 2003 (SampleswinuiShellSampView) ?
le KB908531 ne cause que d'un process (permanent) verclsid.exe; sur mon 2003 il n'y a qu'un verclsid.dll et aucun process (aucun identifiable) qui utilise cette dll en deamon; leur solution (liste verte etc) est donc inapplicable.
la suppression du patch 908531 (qui vire cette dll) corrige spontanément le problème - le débugger attrape tous les breakpoints - 36h de perdu, merci qui...
