Erreur Java - RemoteException occurred in server thread, etc.
5 réponses
Otto Haldi
Bonjour,
Je ne programme pas en java, mais j'ai une application de gestion de temps écris dans ce language.
Cette application était installé sur un PC avec Win XP et fonctionnait sans problème.
J'ai réinstallé cette application sur un PC avec WIN 7 Prof 64 bits. Cela à bien fonctionné quelques jours,
mais maintenant, j'ai l'erreur suivante:
Exception : RemoteException occurred in server thread; nested excpetion is:
java.mrmi.ConnectException: Connection refused to host:
PC-NAME; nested exception is:
java.net.ConnectException: Connection timed out: connect
Je n'ai pourtant rien changé sur ce poste de travail. Y-a t'il un problème de droit avec java?
Comme antivirus j'ai Microsoft Security Essentials .
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
Bertrand Usse
Otto Haldi wrote:
Bonjour, Je ne programme pas en java, mais j'ai une application de gestion de temps écris dans ce language. Cette application était installé sur un PC avec Win XP et fonctionnait sans problème. J'ai réinstallé cette application sur un PC avec WIN 7 Prof 64 bits. Cela à bien fonctionné quelques jours, mais maintenant, j'ai l'erreur suivante: Exception : RemoteException occurred in server thread; nested excpetion is: java.mrmi.ConnectException: Connection refused to host: PC-NAME; nested exception is: java.net.ConnectException: Connection timed out: connect Je n'ai pourtant rien changé sur ce poste de travail.
Le serveur distant n'a pas pu être contacté. Refus ou délai dépassé, je ne saurais trop dire laquelle des deux est à retenir puisque la première concerne java.mrmi (une connexion spécialisée) et la seconde concerne java.net (une connexion générique) mais personnellement, j'aurais plutôt tendance à prendre en compte l'erreur générique qui indique que l'hôte distant ne répond pas et donc de tester la connectivité / le raccordement entre le poste client et la machine serveur hébergeant le service réseau auquel le programme client essaie de se connecter. (ce qui implique de vérifier aussi le pare-feu local s'il ne bloque pas cette connexion en particulier ou si une règle plus large ne s'applique pas dans ce cas et au pire désactiver le pare-feu _temporairement_ pour exclure cet élément.
Y-a t'il un problème de droit avec java?
Tout dépend de comment le programme a été écrit mais puisque vous ne pouvait pas répondre à cette question le mieux est encore de tester le programme avec un utilisateur membre du groupe administrateurs de la machine locale - bien que normalement ça ne devrait pas être nécessaire au bon fonctionnement d'un programme client n'ayant a priori pas de tâches administrative à accomplir sur la machine locale. (dans le cas contraire vous avez trouvé l'origine du problème ou au moins une partie)
Comme antivirus j'ai Microsoft Security Essentials .
Un antivirus n'est pas supposé bloquer les connexions réseau d'un programme (hormis dans la cas particulier des navigateurs web et cette interaction s'effectue le plus souvent via un plugin spécifique) c'est plutôt le travail du pare-feu. Cela dit, si l'antivirus considère que le programme en question est un virus alors il est susceptible de bloquer son lancement mais dans ce cas vous le verriez immédiatement via une notification de l'antivirus et le fichier serait déplacé dans la quarantaine.
Merci d'avance pour votre aide.
Otto Haldi wrote:
Bonjour, Je ne programme pas en java, mais j'ai une application de
gestion de temps écris dans ce language. Cette application était
installé sur un PC avec Win XP et fonctionnait sans problème. J'ai
réinstallé cette application sur un PC avec WIN 7 Prof 64 bits. Cela
à bien fonctionné quelques jours, mais maintenant, j'ai l'erreur
suivante: Exception : RemoteException occurred in server thread;
nested excpetion is: java.mrmi.ConnectException: Connection refused
to host: PC-NAME; nested exception is: java.net.ConnectException:
Connection timed out: connect Je n'ai pourtant rien changé sur ce
poste de travail.
Le serveur distant n'a pas pu être contacté. Refus ou délai dépassé, je
ne saurais trop dire laquelle des deux est à retenir puisque la première
concerne java.mrmi (une connexion spécialisée) et la seconde concerne
java.net (une connexion générique) mais personnellement, j'aurais plutôt
tendance à prendre en compte l'erreur générique qui indique que l'hôte
distant ne répond pas et donc de tester la connectivité / le
raccordement entre le poste client et la machine serveur hébergeant le
service réseau auquel le programme client essaie de se connecter. (ce
qui implique de vérifier aussi le pare-feu local s'il ne bloque pas
cette connexion en particulier ou si une règle plus large ne s'applique
pas dans ce cas et au pire désactiver le pare-feu _temporairement_ pour
exclure cet élément.
Y-a t'il un problème de droit avec java?
Tout dépend de comment le programme a été écrit mais puisque vous ne
pouvait pas répondre à cette question le mieux est encore de tester le
programme avec un utilisateur membre du groupe administrateurs de la
machine locale - bien que normalement ça ne devrait pas être nécessaire
au bon fonctionnement d'un programme client n'ayant a priori pas de
tâches administrative à accomplir sur la machine locale. (dans le cas
contraire vous avez trouvé l'origine du problème ou au moins une partie)
Comme antivirus j'ai Microsoft Security Essentials .
Un antivirus n'est pas supposé bloquer les connexions réseau d'un
programme (hormis dans la cas particulier des navigateurs web et cette
interaction s'effectue le plus souvent via un plugin spécifique) c'est
plutôt le travail du pare-feu. Cela dit, si l'antivirus considère que le
programme en question est un virus alors il est susceptible de bloquer
son lancement mais dans ce cas vous le verriez immédiatement via une
notification de l'antivirus et le fichier serait déplacé dans la
quarantaine.
Bonjour, Je ne programme pas en java, mais j'ai une application de gestion de temps écris dans ce language. Cette application était installé sur un PC avec Win XP et fonctionnait sans problème. J'ai réinstallé cette application sur un PC avec WIN 7 Prof 64 bits. Cela à bien fonctionné quelques jours, mais maintenant, j'ai l'erreur suivante: Exception : RemoteException occurred in server thread; nested excpetion is: java.mrmi.ConnectException: Connection refused to host: PC-NAME; nested exception is: java.net.ConnectException: Connection timed out: connect Je n'ai pourtant rien changé sur ce poste de travail.
Le serveur distant n'a pas pu être contacté. Refus ou délai dépassé, je ne saurais trop dire laquelle des deux est à retenir puisque la première concerne java.mrmi (une connexion spécialisée) et la seconde concerne java.net (une connexion générique) mais personnellement, j'aurais plutôt tendance à prendre en compte l'erreur générique qui indique que l'hôte distant ne répond pas et donc de tester la connectivité / le raccordement entre le poste client et la machine serveur hébergeant le service réseau auquel le programme client essaie de se connecter. (ce qui implique de vérifier aussi le pare-feu local s'il ne bloque pas cette connexion en particulier ou si une règle plus large ne s'applique pas dans ce cas et au pire désactiver le pare-feu _temporairement_ pour exclure cet élément.
Y-a t'il un problème de droit avec java?
Tout dépend de comment le programme a été écrit mais puisque vous ne pouvait pas répondre à cette question le mieux est encore de tester le programme avec un utilisateur membre du groupe administrateurs de la machine locale - bien que normalement ça ne devrait pas être nécessaire au bon fonctionnement d'un programme client n'ayant a priori pas de tâches administrative à accomplir sur la machine locale. (dans le cas contraire vous avez trouvé l'origine du problème ou au moins une partie)
Comme antivirus j'ai Microsoft Security Essentials .
Un antivirus n'est pas supposé bloquer les connexions réseau d'un programme (hormis dans la cas particulier des navigateurs web et cette interaction s'effectue le plus souvent via un plugin spécifique) c'est plutôt le travail du pare-feu. Cela dit, si l'antivirus considère que le programme en question est un virus alors il est susceptible de bloquer son lancement mais dans ce cas vous le verriez immédiatement via une notification de l'antivirus et le fichier serait déplacé dans la quarantaine.
Merci d'avance pour votre aide.
Otto Haldi
On Mon, 04 Feb 2013 18:30:31 +0100, Bertrand Usse wrote:
Merci pour toutes ces explications. Je vais recontroller ce problème de pare-feu. Juste pour info. Il n'y a pas de server distant. Tout est installé sur le même PC en local.
Otto Haldi wrote:
Bonjour, Je ne programme pas en java, mais j'ai une application de gestion de temps écris dans ce language. Cette application était installé sur un PC avec Win XP et fonctionnait sans problème. J'ai réinstallé cette application sur un PC avec WIN 7 Prof 64 bits. Cela à bien fonctionné quelques jours, mais maintenant, j'ai l'erreur suivante: Exception : RemoteException occurred in server thread; nested excpetion is: java.mrmi.ConnectException: Connection refused to host: PC-NAME; nested exception is: java.net.ConnectException: Connection timed out: connect Je n'ai pourtant rien changé sur ce poste de travail.
Le serveur distant n'a pas pu être contacté. Refus ou délai dépassé, je ne saurais trop dire laquelle des deux est à retenir puisque la première concerne java.mrmi (une connexion spécialisée) et la seconde concerne java.net (une connexion générique) mais personnellement, j'aurais plutôt tendance à prendre en compte l'erreur générique qui indique que l'hôte distant ne répond pas et donc de tester la connectivité / le raccordement entre le poste client et la machine serveur hébergeant le service réseau auquel le programme client essaie de se connecter. (ce qui implique de vérifier aussi le pare-feu local s'il ne bloque pas cette connexion en particulier ou si une règle plus large ne s'applique pas dans ce cas et au pire désactiver le pare-feu _temporairement_ pour exclure cet élément.
Y-a t'il un problème de droit avec java?
Tout dépend de comment le programme a été écrit mais puisque vous ne pouvait pas répondre à cette question le mieux est encore de tester le programme avec un utilisateur membre du groupe administrateurs de la machine locale - bien que normalement ça ne devrait pas être nécessaire au bon fonctionnement d'un programme client n'ayant a priori pas de tâches administrative à accomplir sur la machine locale. (dans le cas contraire vous avez trouvé l'origine du problème ou au moins une partie)
Comme antivirus j'ai Microsoft Security Essentials .
Un antivirus n'est pas supposé bloquer les connexions réseau d'un programme (hormis dans la cas particulier des navigateurs web et cette interaction s'effectue le plus souvent via un plugin spécifique) c'est plutôt le travail du pare-feu. Cela dit, si l'antivirus considère que le programme en question est un virus alors il est susceptible de bloquer son lancement mais dans ce cas vous le verriez immédiatement via une notification de l'antivirus et le fichier serait déplacé dans la quarantaine.
Merci d'avance pour votre aide.
On Mon, 04 Feb 2013 18:30:31 +0100, Bertrand Usse <bertrand.usse@free.fr> wrote:
Merci pour toutes ces explications.
Je vais recontroller ce problème de pare-feu.
Juste pour info. Il n'y a pas de server distant. Tout est installé sur le même PC en local.
Otto Haldi wrote:
Bonjour, Je ne programme pas en java, mais j'ai une application de
gestion de temps écris dans ce language. Cette application était
installé sur un PC avec Win XP et fonctionnait sans problème. J'ai
réinstallé cette application sur un PC avec WIN 7 Prof 64 bits. Cela
à bien fonctionné quelques jours, mais maintenant, j'ai l'erreur
suivante: Exception : RemoteException occurred in server thread;
nested excpetion is: java.mrmi.ConnectException: Connection refused
to host: PC-NAME; nested exception is: java.net.ConnectException:
Connection timed out: connect Je n'ai pourtant rien changé sur ce
poste de travail.
Le serveur distant n'a pas pu être contacté. Refus ou délai dépassé, je
ne saurais trop dire laquelle des deux est à retenir puisque la première
concerne java.mrmi (une connexion spécialisée) et la seconde concerne
java.net (une connexion générique) mais personnellement, j'aurais plutôt
tendance à prendre en compte l'erreur générique qui indique que l'hôte
distant ne répond pas et donc de tester la connectivité / le
raccordement entre le poste client et la machine serveur hébergeant le
service réseau auquel le programme client essaie de se connecter. (ce
qui implique de vérifier aussi le pare-feu local s'il ne bloque pas
cette connexion en particulier ou si une règle plus large ne s'applique
pas dans ce cas et au pire désactiver le pare-feu _temporairement_ pour
exclure cet élément.
Y-a t'il un problème de droit avec java?
Tout dépend de comment le programme a été écrit mais puisque vous ne
pouvait pas répondre à cette question le mieux est encore de tester le
programme avec un utilisateur membre du groupe administrateurs de la
machine locale - bien que normalement ça ne devrait pas être nécessaire
au bon fonctionnement d'un programme client n'ayant a priori pas de
tâches administrative à accomplir sur la machine locale. (dans le cas
contraire vous avez trouvé l'origine du problème ou au moins une partie)
Comme antivirus j'ai Microsoft Security Essentials .
Un antivirus n'est pas supposé bloquer les connexions réseau d'un
programme (hormis dans la cas particulier des navigateurs web et cette
interaction s'effectue le plus souvent via un plugin spécifique) c'est
plutôt le travail du pare-feu. Cela dit, si l'antivirus considère que le
programme en question est un virus alors il est susceptible de bloquer
son lancement mais dans ce cas vous le verriez immédiatement via une
notification de l'antivirus et le fichier serait déplacé dans la
quarantaine.
On Mon, 04 Feb 2013 18:30:31 +0100, Bertrand Usse wrote:
Merci pour toutes ces explications. Je vais recontroller ce problème de pare-feu. Juste pour info. Il n'y a pas de server distant. Tout est installé sur le même PC en local.
Otto Haldi wrote:
Bonjour, Je ne programme pas en java, mais j'ai une application de gestion de temps écris dans ce language. Cette application était installé sur un PC avec Win XP et fonctionnait sans problème. J'ai réinstallé cette application sur un PC avec WIN 7 Prof 64 bits. Cela à bien fonctionné quelques jours, mais maintenant, j'ai l'erreur suivante: Exception : RemoteException occurred in server thread; nested excpetion is: java.mrmi.ConnectException: Connection refused to host: PC-NAME; nested exception is: java.net.ConnectException: Connection timed out: connect Je n'ai pourtant rien changé sur ce poste de travail.
Le serveur distant n'a pas pu être contacté. Refus ou délai dépassé, je ne saurais trop dire laquelle des deux est à retenir puisque la première concerne java.mrmi (une connexion spécialisée) et la seconde concerne java.net (une connexion générique) mais personnellement, j'aurais plutôt tendance à prendre en compte l'erreur générique qui indique que l'hôte distant ne répond pas et donc de tester la connectivité / le raccordement entre le poste client et la machine serveur hébergeant le service réseau auquel le programme client essaie de se connecter. (ce qui implique de vérifier aussi le pare-feu local s'il ne bloque pas cette connexion en particulier ou si une règle plus large ne s'applique pas dans ce cas et au pire désactiver le pare-feu _temporairement_ pour exclure cet élément.
Y-a t'il un problème de droit avec java?
Tout dépend de comment le programme a été écrit mais puisque vous ne pouvait pas répondre à cette question le mieux est encore de tester le programme avec un utilisateur membre du groupe administrateurs de la machine locale - bien que normalement ça ne devrait pas être nécessaire au bon fonctionnement d'un programme client n'ayant a priori pas de tâches administrative à accomplir sur la machine locale. (dans le cas contraire vous avez trouvé l'origine du problème ou au moins une partie)
Comme antivirus j'ai Microsoft Security Essentials .
Un antivirus n'est pas supposé bloquer les connexions réseau d'un programme (hormis dans la cas particulier des navigateurs web et cette interaction s'effectue le plus souvent via un plugin spécifique) c'est plutôt le travail du pare-feu. Cela dit, si l'antivirus considère que le programme en question est un virus alors il est susceptible de bloquer son lancement mais dans ce cas vous le verriez immédiatement via une notification de l'antivirus et le fichier serait déplacé dans la quarantaine.
Merci d'avance pour votre aide.
Bertrand Usse
Otto Haldi wrote:
Merci pour toutes ces explications. Je vais recontroller ce problème de pare-feu. Juste pour info. Il n'y a pas de server distant. Tout est installé sur le même PC en local.
Le fait que le logiciel serveur se trouve sur la même machine ne change rien à ce que j'ai écrit et au principe de fonctionnement du programme.
A la rigueur vous pouvez vérifier que le processus serveur soit bel et bien lancé et fonctionnel puisque vous y avez accès. Le cas échéant tester la connexion avec un client réseau générique si vous avez ça sous la main - le client telnet doit convenir pour ce genre de test.
Otto Haldi wrote:
Merci pour toutes ces explications. Je vais recontroller ce problème
de pare-feu. Juste pour info. Il n'y a pas de server distant. Tout
est installé sur le même PC en local.
Le fait que le logiciel serveur se trouve sur la même machine ne change
rien à ce que j'ai écrit et au principe de fonctionnement du programme.
A la rigueur vous pouvez vérifier que le processus serveur soit bel et
bien lancé et fonctionnel puisque vous y avez accès. Le cas échéant
tester la connexion avec un client réseau générique si vous avez ça sous
la main - le client telnet doit convenir pour ce genre de test.
Merci pour toutes ces explications. Je vais recontroller ce problème de pare-feu. Juste pour info. Il n'y a pas de server distant. Tout est installé sur le même PC en local.
Le fait que le logiciel serveur se trouve sur la même machine ne change rien à ce que j'ai écrit et au principe de fonctionnement du programme.
A la rigueur vous pouvez vérifier que le processus serveur soit bel et bien lancé et fonctionnel puisque vous y avez accès. Le cas échéant tester la connexion avec un client réseau générique si vous avez ça sous la main - le client telnet doit convenir pour ce genre de test.
Otto Haldi
On Wed, 06 Feb 2013 12:11:11 +0100, Bertrand Usse wrote:
Otto Haldi wrote:
Merci pour toutes ces explications. Je vais recontroller ce problème de pare-feu. Juste pour info. Il n'y a pas de server distant. Tout est installé sur le même PC en local.
Le fait que le logiciel serveur se trouve sur la même machine ne change rien à ce que j'ai écrit et au principe de fonctionnement du programme.
A la rigueur vous pouvez vérifier que le processus serveur soit bel et bien lancé et fonctionnel puisque vous y avez accès. Le cas échéant tester la connexion avec un client réseau générique si vous avez ça sous la main - le client telnet doit convenir pour ce genre de test.
Petite question pour le test telnet! Faut-t'il untiliser un client Telnet puis se connecter sur l'adresse IP localhost, Y-a-t'il un port spécifique ? J'ai Putty comme outils Telnet.
On Wed, 06 Feb 2013 12:11:11 +0100, Bertrand Usse <bertrand.usse@free.fr> wrote:
Otto Haldi wrote:
Merci pour toutes ces explications. Je vais recontroller ce problème
de pare-feu. Juste pour info. Il n'y a pas de server distant. Tout
est installé sur le même PC en local.
Le fait que le logiciel serveur se trouve sur la même machine ne change
rien à ce que j'ai écrit et au principe de fonctionnement du programme.
A la rigueur vous pouvez vérifier que le processus serveur soit bel et
bien lancé et fonctionnel puisque vous y avez accès. Le cas échéant
tester la connexion avec un client réseau générique si vous avez ça sous
la main - le client telnet doit convenir pour ce genre de test.
Petite question pour le test telnet!
Faut-t'il untiliser un client Telnet puis se connecter sur l'adresse IP localhost, Y-a-t'il un port spécifique ?
J'ai Putty comme outils Telnet.
On Wed, 06 Feb 2013 12:11:11 +0100, Bertrand Usse wrote:
Otto Haldi wrote:
Merci pour toutes ces explications. Je vais recontroller ce problème de pare-feu. Juste pour info. Il n'y a pas de server distant. Tout est installé sur le même PC en local.
Le fait que le logiciel serveur se trouve sur la même machine ne change rien à ce que j'ai écrit et au principe de fonctionnement du programme.
A la rigueur vous pouvez vérifier que le processus serveur soit bel et bien lancé et fonctionnel puisque vous y avez accès. Le cas échéant tester la connexion avec un client réseau générique si vous avez ça sous la main - le client telnet doit convenir pour ce genre de test.
Petite question pour le test telnet! Faut-t'il untiliser un client Telnet puis se connecter sur l'adresse IP localhost, Y-a-t'il un port spécifique ? J'ai Putty comme outils Telnet.
Bertrand Usse
Otto Haldi wrote:
On Wed, 06 Feb 2013 12:11:11 +0100, Bertrand Usse wrote:
Otto Haldi wrote:
Merci pour toutes ces explications. Je vais recontroller ce problème de pare-feu. Juste pour info. Il n'y a pas de server distant. Tout est installé sur le même PC en local.
Le fait que le logiciel serveur se trouve sur la même machine ne change rien à ce que j'ai écrit et au principe de fonctionnement du programme.
A la rigueur vous pouvez vérifier que le processus serveur soit bel et bien lancé et fonctionnel puisque vous y avez accès. Le cas échéant tester la connexion avec un client réseau générique si vous avez ça sous la main - le client telnet doit convenir pour ce genre de test.
Petite question pour le test telnet! Faut-t'il untiliser un client Telnet puis se connecter sur l'adresse IP localhost, Y-a-t'il un port spécifique ?
Très certainement, sans port point de salut ! (salut = service :P) Si le numéro de port n'est précisé nul part dans la configuration du programme* et que le programme serveur fonctionne vous pouvez déterminer le numéro de port en listant les ports ouverts et en cherchant la (ou les) ligne(s) de l'exécutable concerné et donc son (ou ses) numéro(s) de port ouvert.
* ou dans la documentation du programme s'il y en a une ...
Au cas où : netstat -nab en tant qu'administrateur (peut être long) fournira l'information recherchée, sinon en tant que simple utilisateur : netstat -nao donne le PID du processus et il faut faire la corrélation avec un gestionnaire de processus - le gestionnaire des tâches de Windows convient pour cette tâche à condition d'ajouter la colonne PID.
J'ai Putty comme outils Telnet.
C'est encore mieux !
Otto Haldi wrote:
On Wed, 06 Feb 2013 12:11:11 +0100, Bertrand Usse
<bertrand.usse@free.fr> wrote:
Otto Haldi wrote:
Merci pour toutes ces explications. Je vais recontroller ce
problème de pare-feu. Juste pour info. Il n'y a pas de server
distant. Tout est installé sur le même PC en local.
Le fait que le logiciel serveur se trouve sur la même machine ne
change rien à ce que j'ai écrit et au principe de fonctionnement
du programme.
A la rigueur vous pouvez vérifier que le processus serveur soit
bel et bien lancé et fonctionnel puisque vous y avez accès. Le cas
échéant tester la connexion avec un client réseau générique si
vous avez ça sous la main - le client telnet doit convenir pour ce
genre de test.
Petite question pour le test telnet! Faut-t'il untiliser un client
Telnet puis se connecter sur l'adresse IP localhost, Y-a-t'il un
port spécifique ?
Très certainement, sans port point de salut ! (salut = service :P)
Si le numéro de port n'est précisé nul part dans la configuration du
programme* et que le programme serveur fonctionne vous pouvez déterminer
le numéro de port en listant les ports ouverts et en cherchant la (ou
les) ligne(s) de l'exécutable concerné et donc son (ou ses) numéro(s) de
port ouvert.
* ou dans la documentation du programme s'il y en a une ...
Au cas où : netstat -nab en tant qu'administrateur (peut être long)
fournira l'information recherchée, sinon en tant que simple utilisateur
: netstat -nao donne le PID du processus et il faut faire la corrélation
avec un gestionnaire de processus - le gestionnaire des tâches de
Windows convient pour cette tâche à condition d'ajouter la colonne PID.
On Wed, 06 Feb 2013 12:11:11 +0100, Bertrand Usse wrote:
Otto Haldi wrote:
Merci pour toutes ces explications. Je vais recontroller ce problème de pare-feu. Juste pour info. Il n'y a pas de server distant. Tout est installé sur le même PC en local.
Le fait que le logiciel serveur se trouve sur la même machine ne change rien à ce que j'ai écrit et au principe de fonctionnement du programme.
A la rigueur vous pouvez vérifier que le processus serveur soit bel et bien lancé et fonctionnel puisque vous y avez accès. Le cas échéant tester la connexion avec un client réseau générique si vous avez ça sous la main - le client telnet doit convenir pour ce genre de test.
Petite question pour le test telnet! Faut-t'il untiliser un client Telnet puis se connecter sur l'adresse IP localhost, Y-a-t'il un port spécifique ?
Très certainement, sans port point de salut ! (salut = service :P) Si le numéro de port n'est précisé nul part dans la configuration du programme* et que le programme serveur fonctionne vous pouvez déterminer le numéro de port en listant les ports ouverts et en cherchant la (ou les) ligne(s) de l'exécutable concerné et donc son (ou ses) numéro(s) de port ouvert.
* ou dans la documentation du programme s'il y en a une ...
Au cas où : netstat -nab en tant qu'administrateur (peut être long) fournira l'information recherchée, sinon en tant que simple utilisateur : netstat -nao donne le PID du processus et il faut faire la corrélation avec un gestionnaire de processus - le gestionnaire des tâches de Windows convient pour cette tâche à condition d'ajouter la colonne PID.
