Serveur occupé....

Le
Didier
Bonjour,

Je travaille en ce moment sur le symptôme "Serveur occupé - Impossible de
terminer cette action car l'autre programme est occupé.".

Celui ci se produit aléatoirement chez un utilisateur loin de mon lieu de
travail. Je connais la signification de ce message. Pour mémoire : c'est une
application OLE / RPC qui ne réagit plus car elle attend quelque chose.

Le poste de l'utilisateur contient diverses applications : MS Office, en
particulier Access et des applications spécifiques spécialisées (KaNest pour
ne pas la nommer), qui utilisent DCOM en local et en distant.

La question est la suivante : comment déterminer qui est le serveur ?
C'est-à-dire quelle est l'application qui ne réponds pas ? J'ai besoin de
connaitre son nom, ou bien son Process ID, ou bien l'UUID de l'interface
sollicitée.

- J'ai cherché sur le web : on trouve des correctifs pour supprimer ce
message d'erreur dans des contextes particuliers (par ex. Outlook, Access,
Exchange Serveur, et autres applications exotiques), mais qui ne
correspondent pas au contexte présent. On trouve les codes d'erreur. Mais
on ne trouve pas d'outil générique, par exemple un traceur, qui donnerait
par exemple l'Id du processus bloquant.

- Du coté des journaux d'évènements il n' y a rien.

- J'ai essayé du coté des audits de la console "Paramètres de sécurité
locaux" : rien n'est remonté.

- J'ai essayé du coté Moniteur de Performance : RAS :-(

- Kit de Resource windows 2003 : pas trouvé non plus un utilitaire qui irait
bien.

En anglais le message d'erreur est "This action cannot be completed because
ApplicationName is busy. Click SwitchTo to activate ApplicationName and
correct the problem." ( page 364/537 du document suivant :
"http://download.microsoft.com/download/0/4/6/046bbd36-0812-4c22-a870-41911c6487a6/WindowsUserExperience.pdf"
)

Avec cela, j'ai cherché aussi tout le web, essentiellement en anglais, sans
plus de succès.

Donc le but de la manouvre est de fournir à l'utilisateur un outil ou une
méthode directe qui lui permettrait de me dire qui est "ApplicationName ".
J'essaye d'éviter la méthode déductive ou approximative qui consisterait à
arrêter et éliminer toute les applications qui tournent obligatoirement dans
le contexte où il se trouve.

Voilà, j'espère avoir été suffisamment clair.

Didier
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
mdnews
Le #20274141
On Thu, 1 Oct 2009 17:32:09 +0200, "Didier" wrote:

Bonjour,

Je travaille en ce moment sur le symptôme "Serveur occupé - Impossible de
terminer cette action car l'autre programme est occupé.".

Celui ci se produit aléatoirement chez un utilisateur loin de mon lieu de
travail. Je connais la signification de ce message. Pour mémoire : c'est une
application OLE / RPC qui ne réagit plus car elle attend quelque chose.

Le poste de l'utilisateur contient diverses applications : MS Office, en
particulier Access et des applications spécifiques spécialisées (KaNest pour
ne pas la nommer), qui utilisent DCOM en local et en distant.

La question est la suivante : comment déterminer qui est le serveur ?
C'est-à-dire quelle est l'application qui ne réponds pas ? J'ai besoin de
connaitre son nom, ou bien son Process ID, ou bien l'UUID de l'interface
sollicitée.

- J'ai cherché sur le web : on trouve des correctifs pour supprimer ce
message d'erreur dans des contextes particuliers (par ex. Outlook, Access,
Exchange Serveur, et autres applications exotiques), mais qui ne
correspondent pas au contexte présent. On trouve les codes d'erreur.... Mais
on ne trouve pas d'outil générique, par exemple un traceur, qui donnerait
par exemple l'Id du processus bloquant.

- Du coté des journaux d'évènements il n' y a rien.

- J'ai essayé du coté des audits de la console "Paramètres de sécurité
locaux" : rien n'est remonté.

- J'ai essayé du coté Moniteur de Performance : RAS... :-(

- Kit de Resource windows 2003 : pas trouvé non plus un utilitaire qui irait
bien.

En anglais le message d'erreur est "This action cannot be completed because
ApplicationName is busy. Click SwitchTo to activate ApplicationName and
correct the problem." ( page 364/537 du document suivant :
"http://download.microsoft.com/download/0/4/6/046bbd36-0812-4c22-a870-41911c6487a6/WindowsUserExperience.pdf"
)

Avec cela, j'ai cherché aussi tout le web, essentiellement en anglais, sans
plus de succès.

Donc le but de la manouvre est de fournir à l'utilisateur un outil ou une
méthode directe qui lui permettrait de me dire qui est "ApplicationName ".
J'essaye d'éviter la méthode déductive ou approximative qui consisterait à
arrêter et éliminer toute les applications qui tournent obligatoirement dans
le contexte où il se trouve.




J'ai peut être mal lu, mais le "gestionnaire de tâches" ne semble pas
cité ?
C'est pourtant le premier qu'on regarde quand une machine ne répond
plus (onglet Pocessus, classer par Processeur, ordre descendant)
Didier
Le #20274271
> J'ai peut être mal lu, mais le "gestionnaire de tâches" ne semble pas
cité ?
C'est pourtant le premier qu'on regarde quand une machine ne répond
plus (onglet Pocessus, classer par Processeur, ordre descendant)




Il s'agit d'un processus OLE, et le gestionnaire des tâches ne visualise que
les processus hôtes comme svchost.exe et services.exe, sous Windows XP qui
est l'OS de l'utilisateur. D'autre part ce n'est pas parcequ'un thread de
serveur OLE ne réponds plus qu'il est planté. En effet, passé un certain
délais, 15 à 60 secondes, on peut annuler la pop-up "Serveur occupé..." et
tout redevient normal. L'hypothèse est qu'il attend une réponse, ou un
time-out, du réseau ou d'un autre processus interne. Donc la question est de
savoir qui est ce serveur OLE et ensuite d'en déduire ce qu'il peut
attendre.

Mais votre idée me donne une piste, car les gestionnaires de tâches Vista /
2003 / Seven sont plus riches en informations. D'autre part cela me fait
penser aux outils Sysinternals, comme Process Explorer... En provoquant
cette pop-up sous l'un de ces OS je vais peut être trouver...

Merci pour votre suggestion.

Didier
Publicité
Poster une réponse
Anonyme