PowerBuilder à Donf ! / [RESOLU] Même application qui marche ou plante selon le nom de l'exe

_francois_ · 27-01-2014 15:23:45

Bonjour,

nous avons une suite d'applications (avant en PB10, migrées en PB12.5)

A l'époque PB10 nous avions 5 gros exe, chaque application reprenant une partie d'une même pool de pbd
Maintenant les 5 applications ont la même library list et tout est compilé en pbd
Nous appellerons dans l'exemple nos applications tata.exe tete.exe titi.exe toto.exe et tutu.exe

Nous venons de rencontrer deux fois le même problème sur du TSE 2008 (hébergeant aussi la base SQL Server 2008 R2)
Si je parle de l'historique c'est que nous avions eu une fois le problème sur un poste client (XP si j'ai bonne mémoire)

En gros:
Sur le premier serveur titi.exe ne fonctionne pas (on prend un application crash report à l'ouverture) si on le renomme en tata2.exe il fonctionne, si on le renomme en titi2.exe il ne fonctionne pas
Sur le deuxième serveur c'est tete.exe toto.exe et tutu.exe qui ne fonctionnent pas (tete.exe fonctionne) si on les renomme en tete2.exe tete3.exe et tete4.exe ils fonctionnent
sur ce deuxième serveur tout a bien fonctionné pendant plus d'une semaine sans soucis (ça marchait encore ce matin).
D'autres clients ont une configuration identique et tout fonctionne bien.

J'ai essayé de désactiver l'antivirus (Norton sur un et Kaspersky sur l'autre) toujours pareil.
J'ai aussi essayé de les ajouter en exception dans la DEP (Data Execution Prevention) mais c'est pas ça non plus.
J'ai voulu regarder du coté du prefetch mais je ne trouve pas le répertoire.

Les icones sont toutes de la forme X:\repertoire_app\tata.exe c:\rep_usr x:\rep_ini

Dans rep_usr on a un fichier ini qui permet d'enregistrer quelques informations sur comme le dernier login etc.
Dans les deux installations c'est c:\users\%USERNAME%
Dans rep_ini on a un fichier ini qui stocke des paramètres comme le DSN ODBC etc.

J'ai tenté de faire un petit /PBDEBUG en transformant mon icone comme ceci
X:\repertoire_app\tata.exe /PBDEDUG x:\rep_ini
mais là ça fonctionne correctement
J'ai tenté de mettre autre chose que c:\users\%USERNAME% (un répertoire existant ou inexistant ou même n'importe quoi) ça ne fonctionne pas

Le open des divers modules est sensiblement le même (certains initialisent deux trois variables globales de plus ou de moins)

Donc si vous avez des idées ou des pistes parceque moi là

Dernière modification par _francois_ (04-03-2014 17:23:56)

rincevent · 27-01-2014 15:32:28

Salut,

en effet ça à l'air bien comme problème.

pas d'infos exploitables dans l'application crash report ou l'event viewer Windows ?

_francois_ · 27-01-2014 15:45:10

Ca c'est le crash report dans l'observateur des événements.

Nom de l’application défaillante toto.exe, version : 7.1.3.0, horodatage : 0x51835e47
Nom du module défaillant : PBVM125.dll, version : 12.5.2.5550, horodatage : 0x51835eb3
Code d’exception : 0xc0000005
Décalage d’erreur : 0x0014df8b
ID du processus défaillant : 0x2c78
Heure de début de l’application défaillante : 0x01cf1b5a8184abcb
Chemin d’accès de l’application défaillante : D:\suite_metier\app\toto.exe
Chemin d’accès du module défaillant: D:\suite_metier\app\PBVM125.dll
ID de rapport : bf5e70d0-874d-11e3-80ea-001999b90363

Je vais demander à leur technicien de redémarrer le serveur quand il pourra pour voir si ça arrange les chosesmais quand on avait eu le problème à l'époque ça n'avait rien changé.

seki · 27-01-2014 16:02:34

Tu ne serait pas victime du Fault Tolerant Heap ?
En résumé : quand une application qui a des soucis de gestion mémoire est exécutée sur un windows récent (rencontré ici sur du Win7) :
- windows signale les problèmes via OutputDebugString() ce qui peut se voir si on a un DebugView qui écoute
- si jamais on est en train d'exécuter l'appli dans un debugger (OllyDbg, WinDbg, gdb), le système force un point d'arrêt pour le debugger
- et le système stocke des infos pour patcher l'application lors de la prochaine exécution pour éviter le bug. Seulement une correction automatique peut aussi casser des trucs...

Je suppose que changer le nom de l'éxécutable doit suffire à tromper le patch automatique.

Cette réponse StackOverflow parle du problème. Dans mon cas c'était une appli buggée développée sous XP où on ne voyait pas le problème, et quand on l'exécutait sur Win7 on remarquait les messages et des exceptions inattendues dans le debugger.

_francois_ · 27-01-2014 16:31:58

Merci du tuyau

Mais
Je ne trouve pas le FTH dans l'observateur des évènements
Je ne trouve pas les clés FTH dans la base de registre
Quand j'essaye de lancer Rundll32.exe fthsvc.dll,FthSysprepSpecialize il me dit que le module spécifié est introuvable

J'ai recherché le nom de l'exe dans la base de registre mais à part dans des clés Muicache et Windows Error Reporting rien...

seki · 27-01-2014 17:17:38

_francois_ a écrit:
Je ne trouve pas le FTH dans l'observateur des évènements

Bizarre. Chez moi ça met plusieurs secondes avant d'afficher des trucs au niveau de "application and service logs", tu as attendu suffisamment ?

Maintenant, il n'y a peut-être pas cette fonctionnalité sur TSE 2008 ?

_francois_ · 28-01-2014 08:16:15

Oui j'ai bien attendu ;)
Pour être sûr j'ai regardé sur mon PC (Windows 7 Pro 64 Bits) et j'ai trouvé sans difficulté le FTH dans l'observateur d'événements et dans la base de registre.

Le serveur est un Windows 2008R2 SP1 Standard 64 Bits
Je me demande si les deux serveurs ne sont pas aussi contrôleurs de domaine.

Pour le moment je pense qu'on va les laisser avec le workaround et voir si la prochaine version de notre logiciel rencontre le même problème ou non.

_francois_ · 04-03-2014 16:01:53

Code: pb

ContextKeyword  lcxk_base

GetContextService("Keyword", lcxk_base)

bon après enquête c'est ce bout de code dans une fonction qui ferait planter l'application
si j'ajoute des messageBox dans la fonction ça ne plante plus
J'ai essayé de remplacer par du sleep ou du yield mais ça plante quand même :'(
Je vais regarder du côté de l'API Windows voir comment je pourrais récupérer le répertoire temporaire

buck · 04-03-2014 16:12:34

Bonjour,

Sinon, la fonction de l'API qui permet de récupérer le répertoire temporaire de windows est la suivante :

Code: pb

// Récupérer les informations sur les dossiers spéciaux de windows
FUNCTION ulong  SHGetFolderPath(ulong hwndOwner, int nFolder, ulong hToken, long dwFlags, ref string pszPath) LIBRARY "shell32.dll" ALIAS FOR "SHGetFolderPathA;Ansi"

_francois_ · 04-03-2014 17:23:41

ouais c'est ce que j'ai utilisé en mode Unicode et ça fonctionne
je ne saurais sans jamais pourquoi une version qui marche pendant des semaines se mets à planter tout d'un coup sur X postes clients en fonction du nom de l'exe mais bon le principal est d'avoir trouvé une solution

Pas d'inquiétude, avec PBAdonf, c'est dans la poche ! ^^

Annonce

#1 27-01-2014 15:23:45

[RESOLU] Même application qui marche ou plante selon le nom de l'exe

#2 27-01-2014 15:32:28

Re: [RESOLU] Même application qui marche ou plante selon le nom de l'exe

#3 27-01-2014 15:45:10

Re: [RESOLU] Même application qui marche ou plante selon le nom de l'exe

#4 27-01-2014 16:02:34

Re: [RESOLU] Même application qui marche ou plante selon le nom de l'exe

#5 27-01-2014 16:31:58

Re: [RESOLU] Même application qui marche ou plante selon le nom de l'exe

#6 27-01-2014 17:17:38

Re: [RESOLU] Même application qui marche ou plante selon le nom de l'exe

_francois_ a écrit:

#7 28-01-2014 08:16:15

Re: [RESOLU] Même application qui marche ou plante selon le nom de l'exe

#8 04-03-2014 16:01:53

Re: [RESOLU] Même application qui marche ou plante selon le nom de l'exe

Code: pb

#9 04-03-2014 16:12:34

Re: [RESOLU] Même application qui marche ou plante selon le nom de l'exe

Code: pb

#10 04-03-2014 17:23:41

Re: [RESOLU] Même application qui marche ou plante selon le nom de l'exe

Pied de page des forums