j'ai migré un projet de WD9 en WD14.
le programme tourne comme une horloge sous WD9 mais en WD14 je vois
réapparaitre des vieux démons que sont les "Access violation (GPF)" et
qui me rappelle le pb de l'hyperthreading des pentium 4. généralement
des machines sous XP.
avez vous une idée pour résoudre ?
peut-on bloquer un des processeurs/coeurs ?
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
Fredo
Salut,
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été causé par l'accès aux champs d'une fenêtre par un thread secondaire, pour résoudre ceci, nous avons déplacé les codes modifiants les champs dans des procédure interne à la fenêtre et déclenchée par évènement, le thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14. le programme tourne comme une horloge sous WD9 mais en WD14 je vois réapparaitre des vieux démons que sont les "Access violation (GPF)" et qui me rappelle le pb de l'hyperthreading des pentium 4. généralement des machines sous XP.
avez vous une idée pour résoudre ? peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
Salut,
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été causé
par l'accès aux champs d'une fenêtre par un thread secondaire, pour
résoudre ceci, nous avons déplacé les codes modifiants les champs dans
des procédure interne à la fenêtre et déclenchée par évènement, le
thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14.
le programme tourne comme une horloge sous WD9 mais en WD14 je vois
réapparaitre des vieux démons que sont les "Access violation (GPF)" et
qui me rappelle le pb de l'hyperthreading des pentium 4. généralement
des machines sous XP.
avez vous une idée pour résoudre ?
peut-on bloquer un des processeurs/coeurs ?
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été causé par l'accès aux champs d'une fenêtre par un thread secondaire, pour résoudre ceci, nous avons déplacé les codes modifiants les champs dans des procédure interne à la fenêtre et déclenchée par évènement, le thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14. le programme tourne comme une horloge sous WD9 mais en WD14 je vois réapparaitre des vieux démons que sont les "Access violation (GPF)" et qui me rappelle le pb de l'hyperthreading des pentium 4. généralement des machines sous XP.
avez vous une idée pour résoudre ? peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
titou44
Fredo avait énoncé :
Salut,
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été causé par l'accès aux champs d'une fenêtre par un thread secondaire, pour résoudre ceci, nous avons déplacé les codes modifiants les champs dans des procédure interne à la fenêtre et déclenchée par évènement, le thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14. le programme tourne comme une horloge sous WD9 mais en WD14 je vois réapparaitre des vieux démons que sont les "Access violation (GPF)" et qui me rappelle le pb de l'hyperthreading des pentium 4. généralement des machines sous XP.
avez vous une idée pour résoudre ? peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
bonjour
pas de thread et quand le pg plante, cela peut arriver dès la déclaration des globales du projet !!! donc en début du projet.
titou44 chez libresurf.com
Fredo avait énoncé :
Salut,
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été causé par
l'accès aux champs d'une fenêtre par un thread secondaire, pour résoudre
ceci, nous avons déplacé les codes modifiants les champs dans des procédure
interne à la fenêtre et déclenchée par évènement, le thread secondaire
déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14.
le programme tourne comme une horloge sous WD9 mais en WD14 je vois
réapparaitre des vieux démons que sont les "Access violation (GPF)" et
qui me rappelle le pb de l'hyperthreading des pentium 4. généralement
des machines sous XP.
avez vous une idée pour résoudre ?
peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
bonjour
pas de thread et quand le pg plante, cela peut arriver dès la
déclaration des globales du projet !!! donc en début du projet.
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été causé par l'accès aux champs d'une fenêtre par un thread secondaire, pour résoudre ceci, nous avons déplacé les codes modifiants les champs dans des procédure interne à la fenêtre et déclenchée par évènement, le thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14. le programme tourne comme une horloge sous WD9 mais en WD14 je vois réapparaitre des vieux démons que sont les "Access violation (GPF)" et qui me rappelle le pb de l'hyperthreading des pentium 4. généralement des machines sous XP.
avez vous une idée pour résoudre ? peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
bonjour
pas de thread et quand le pg plante, cela peut arriver dès la déclaration des globales du projet !!! donc en début du projet.
titou44 chez libresurf.com
Fredo
Le 11/01/2012 19:33, titou44 a écrit :
Fredo avait énoncé :
Salut,
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été causé par l'accès aux champs d'une fenêtre par un thread secondaire, pour résoudre ceci, nous avons déplacé les codes modifiants les champs dans des procédure interne à la fenêtre et déclenchée par évènement, le thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14. le programme tourne comme une horloge sous WD9 mais en WD14 je vois réapparaitre des vieux démons que sont les "Access violation (GPF)" et qui me rappelle le pb de l'hyperthreading des pentium 4. généralement des machines sous XP.
avez vous une idée pour résoudre ? peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
bonjour
pas de thread et quand le pg plante, cela peut arriver dès la déclaration des globales du projet !!! donc en début du projet.
titou44 chez libresurf.com
Salut,
Il y a quoi de particulier alors ? activeX, API, ... ?
Fred
Le 11/01/2012 19:33, titou44 a écrit :
Fredo avait énoncé :
Salut,
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été
causé par l'accès aux champs d'une fenêtre par un thread secondaire,
pour résoudre ceci, nous avons déplacé les codes modifiants les champs
dans des procédure interne à la fenêtre et déclenchée par évènement,
le thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14.
le programme tourne comme une horloge sous WD9 mais en WD14 je vois
réapparaitre des vieux démons que sont les "Access violation (GPF)" et
qui me rappelle le pb de l'hyperthreading des pentium 4. généralement
des machines sous XP.
avez vous une idée pour résoudre ?
peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
bonjour
pas de thread et quand le pg plante, cela peut arriver dès la
déclaration des globales du projet !!! donc en début du projet.
titou44 chez libresurf.com
Salut,
Il y a quoi de particulier alors ? activeX, API, ... ?
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été causé par l'accès aux champs d'une fenêtre par un thread secondaire, pour résoudre ceci, nous avons déplacé les codes modifiants les champs dans des procédure interne à la fenêtre et déclenchée par évènement, le thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14. le programme tourne comme une horloge sous WD9 mais en WD14 je vois réapparaitre des vieux démons que sont les "Access violation (GPF)" et qui me rappelle le pb de l'hyperthreading des pentium 4. généralement des machines sous XP.
avez vous une idée pour résoudre ? peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
bonjour
pas de thread et quand le pg plante, cela peut arriver dès la déclaration des globales du projet !!! donc en début du projet.
titou44 chez libresurf.com
Salut,
Il y a quoi de particulier alors ? activeX, API, ... ?
Fred
titou44
Fredo a présenté l'énoncé suivant :
Le 11/01/2012 19:33, titou44 a écrit :
Fredo avait énoncé :
Salut,
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été causé par l'accès aux champs d'une fenêtre par un thread secondaire, pour résoudre ceci, nous avons déplacé les codes modifiants les champs dans des procédure interne à la fenêtre et déclenchée par évènement, le thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14. le programme tourne comme une horloge sous WD9 mais en WD14 je vois réapparaitre des vieux démons que sont les "Access violation (GPF)" et qui me rappelle le pb de l'hyperthreading des pentium 4. généralement des machines sous XP.
avez vous une idée pour résoudre ? peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
bonjour
pas de thread et quand le pg plante, cela peut arriver dès la déclaration des globales du projet !!! donc en début du projet.
titou44 chez libresurf.com
Salut,
Il y a quoi de particulier alors ? activeX, API, ... ?
Fred
bonjour
et bien, rien !
d'où le pb. je suis sec
titou44 chez libresurf.com
Fredo a présenté l'énoncé suivant :
Le 11/01/2012 19:33, titou44 a écrit :
Fredo avait énoncé :
Salut,
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été
causé par l'accès aux champs d'une fenêtre par un thread secondaire,
pour résoudre ceci, nous avons déplacé les codes modifiants les champs
dans des procédure interne à la fenêtre et déclenchée par évènement,
le thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14.
le programme tourne comme une horloge sous WD9 mais en WD14 je vois
réapparaitre des vieux démons que sont les "Access violation (GPF)" et
qui me rappelle le pb de l'hyperthreading des pentium 4. généralement
des machines sous XP.
avez vous une idée pour résoudre ?
peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
bonjour
pas de thread et quand le pg plante, cela peut arriver dès la
déclaration des globales du projet !!! donc en début du projet.
titou44 chez libresurf.com
Salut,
Il y a quoi de particulier alors ? activeX, API, ... ?
Les GPF que nous avons détectés / corrigés en WD14 ont souvent été causé par l'accès aux champs d'une fenêtre par un thread secondaire, pour résoudre ceci, nous avons déplacé les codes modifiants les champs dans des procédure interne à la fenêtre et déclenchée par évènement, le thread secondaire déclenchant l'évènement par un postmessage ad'hoc.
Bon dev,
Fred
Le 10/01/2012 19:52, titou44 a écrit :
bonjour
j'ai migré un projet de WD9 en WD14. le programme tourne comme une horloge sous WD9 mais en WD14 je vois réapparaitre des vieux démons que sont les "Access violation (GPF)" et qui me rappelle le pb de l'hyperthreading des pentium 4. généralement des machines sous XP.
avez vous une idée pour résoudre ? peut-on bloquer un des processeurs/coeurs ?
titou44 chez libresurf.com
bonjour
pas de thread et quand le pg plante, cela peut arriver dès la déclaration des globales du projet !!! donc en début du projet.
titou44 chez libresurf.com
Salut,
Il y a quoi de particulier alors ? activeX, API, ... ?
Fred
bonjour
et bien, rien !
d'où le pb. je suis sec
titou44 chez libresurf.com
Alex
Hello,
Vous avez peut-être un nud dans lordre d'initialisation de variables / classes. Ex. : une classe qui instancie un objet (ou utilise une variable) d'une autre classe, alors que celle-ci n'a pas encore été initialisée / chargée.
Autre possibilité : un fichier corrompu (fichier projet ou fichier de classe ou autre).
Essayez de créer un nouveau projet, et d'importer les éléments un par un, et d'initialiser ce projet à chaque fois que vous importez un nouvel élément. Vous devriez identifier l'élément qui fait buguer les autres.
J'ai eu des problèmes de ce type avec les composants également. Dans ce cas faites un projet et importez tous les éléments sans passer par les composants : importer directement les éléments inclus dans les composants sans importer les composants.
Autre possibilité : placer des points darrêt dans le code de déclaration de variables de chaque classe. Ça vous aidera à voir dans quel ordre elles sont initialisées.
Cordialement,
Alex
Hello,
Vous avez peut-être un nud dans lordre d'initialisation de
variables / classes.
Ex. : une classe qui instancie un objet (ou utilise une variable)
d'une autre classe, alors que celle-ci n'a pas encore été initialisée /
chargée.
Autre possibilité : un fichier corrompu (fichier projet ou fichier de
classe ou autre).
Essayez de créer un nouveau projet, et d'importer les éléments un par
un, et d'initialiser ce projet à chaque fois que vous importez un
nouvel élément.
Vous devriez identifier l'élément qui fait buguer les autres.
J'ai eu des problèmes de ce type avec les composants également.
Dans ce cas faites un projet et importez tous les éléments sans passer
par les composants : importer directement les éléments inclus dans les
composants sans importer les composants.
Autre possibilité : placer des points darrêt dans le code de
déclaration de variables de chaque classe. Ça vous aidera à voir dans
quel ordre elles sont initialisées.
Vous avez peut-être un nud dans lordre d'initialisation de variables / classes. Ex. : une classe qui instancie un objet (ou utilise une variable) d'une autre classe, alors que celle-ci n'a pas encore été initialisée / chargée.
Autre possibilité : un fichier corrompu (fichier projet ou fichier de classe ou autre).
Essayez de créer un nouveau projet, et d'importer les éléments un par un, et d'initialiser ce projet à chaque fois que vous importez un nouvel élément. Vous devriez identifier l'élément qui fait buguer les autres.
J'ai eu des problèmes de ce type avec les composants également. Dans ce cas faites un projet et importez tous les éléments sans passer par les composants : importer directement les éléments inclus dans les composants sans importer les composants.
Autre possibilité : placer des points darrêt dans le code de déclaration de variables de chaque classe. Ça vous aidera à voir dans quel ordre elles sont initialisées.