J'avais lancé une discussion sur fco.ms-windows, début décembre, car à
l'époque ça ressemblait à un problème de driver...
elf5of$bfo$1@shakotay.alphanet.ch
Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de
petits fichiers de texte (<20Ko), le traitement se faisant par des commandes
DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout sous
contrôle d'un makefile.
Le crash peut arriver même entre deux copy, et donc le seul vrai programme à
tourner à ce moment est make.exe (v.3.75). La cause semble liée au "débit",
puisque je le rends moins probable en rajoutant un délai d'une seconde entre
chaque traitement de fichier.
Le dump est inexploitable: plantage dans ntoskrnl.exe dû à une corruption de
mémoire... bien avant. Je pense aussi avoir innocenté tous les drivers.
Depuis, en cherchant sur les multiples forums hors Usenet, il semble qu'il y
ait un vrai problème avec GNU make sous Windows, mais sans plus de
précisions ni de solution (à part "de jeter Windows et de passer sous
Linux", bien sûr).
Voir par exemple:
http://www.cygwin.com/ml/cygwin/2004-03/msg00937.html
http://lists.freepascal.org/lists/fpc-devel/2001-January/000711.html
Est-ce que ceux d'entre-vous qui compilent à l'ancienne (makefiles manuels
plutôt que cliquodromes) ont déjà rencontré ce problème, et idéalement
identifié une solution ?
Merci de vos tuyaux.
--
Cordialement.
--
/***************************************\
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
\***************************************/
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
Thierry Murail
Bonjour,
J'avais lancé une discussion sur fco.ms-windows, début décembre, car à l'époque ça ressemblait à un problème de driver... elf5of$bfo$ Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de petits fichiers de texte (<20Ko), le traitement se faisant par des commandes DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout sous contrôle d'un makefile.
A mon avis la machine a un driver foireux. Essaye de faire cette compile sur une autre... Quel OS ?
Bonjour,
J'avais lancé une discussion sur fco.ms-windows, début décembre, car à
l'époque ça ressemblait à un problème de driver...
elf5of$bfo$1@shakotay.alphanet.ch
Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de
petits fichiers de texte (<20Ko), le traitement se faisant par des
commandes
DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout sous
contrôle d'un makefile.
A mon avis la machine a un driver foireux. Essaye de faire cette compile sur
une autre...
Quel OS ?
J'avais lancé une discussion sur fco.ms-windows, début décembre, car à l'époque ça ressemblait à un problème de driver... elf5of$bfo$ Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de petits fichiers de texte (<20Ko), le traitement se faisant par des commandes DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout sous contrôle d'un makefile.
A mon avis la machine a un driver foireux. Essaye de faire cette compile sur une autre... Quel OS ?
Vincent Burel
"Patrick 'Zener' Brunet" wrote in message news:eoirmv$ihq$
Bonjour.
J'avais lancé une discussion sur fco.ms-windows, début décembre, car à l'époque ça ressemblait à un problème de driver... elf5of$bfo$ Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de petits fichiers de texte (<20Ko), le traitement se faisant par des
commandes
DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout sous contrôle d'un makefile.
Le crash peut arriver même entre deux copy, et donc le seul vrai programme
à
tourner à ce moment est make.exe (v.3.75). La cause semble liée au
"débit",
puisque je le rends moins probable en rajoutant un délai d'une seconde
entre
chaque traitement de fichier. Le dump est inexploitable: plantage dans ntoskrnl.exe dû à une corruption
de
mémoire... bien avant. Je pense aussi avoir innocenté tous les drivers.
Depuis, en cherchant sur les multiples forums hors Usenet, il semble qu'il
y
ait un vrai problème avec GNU make sous Windows, mais sans plus de précisions ni de solution (à part "de jeter Windows et de passer sous Linux", bien sûr). Voir par exemple: http://www.cygwin.com/ml/cygwin/2004-03/msg00937.html http://lists.freepascal.org/lists/fpc-devel/2001-January/000711.html
Est-ce que ceux d'entre-vous qui compilent à l'ancienne (makefiles manuels plutôt que cliquodromes) ont déjà rencontré ce problème, et idéalement identifié une solution ?
Si vous avez des problemes inexplicables, avec des erreurs bizarres, notament lors de la gestion de fichiers (en nombre) ou tout autres opérations qui demande au systeme d'allouer quantité de mémoire. Alors le problème peut venir des barettes, notamment s'ils elle sont noname. changez les avec des barettes garantie pour vous en assuré (ou faite un test_mem).
Sinon, vous devriez utilisez le nmake de microsoft. Au moins ca ca marche.
VB
"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid> wrote in
message news:eoirmv$ihq$1@shakotay.alphanet.ch...
Bonjour.
J'avais lancé une discussion sur fco.ms-windows, début décembre, car à
l'époque ça ressemblait à un problème de driver...
elf5of$bfo$1@shakotay.alphanet.ch
Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de
petits fichiers de texte (<20Ko), le traitement se faisant par des
commandes
DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout sous
contrôle d'un makefile.
Le crash peut arriver même entre deux copy, et donc le seul vrai programme
à
tourner à ce moment est make.exe (v.3.75). La cause semble liée au
"débit",
puisque je le rends moins probable en rajoutant un délai d'une seconde
entre
chaque traitement de fichier.
Le dump est inexploitable: plantage dans ntoskrnl.exe dû à une corruption
de
mémoire... bien avant. Je pense aussi avoir innocenté tous les drivers.
Depuis, en cherchant sur les multiples forums hors Usenet, il semble qu'il
y
ait un vrai problème avec GNU make sous Windows, mais sans plus de
précisions ni de solution (à part "de jeter Windows et de passer sous
Linux", bien sûr).
Voir par exemple:
http://www.cygwin.com/ml/cygwin/2004-03/msg00937.html
http://lists.freepascal.org/lists/fpc-devel/2001-January/000711.html
Est-ce que ceux d'entre-vous qui compilent à l'ancienne (makefiles manuels
plutôt que cliquodromes) ont déjà rencontré ce problème, et idéalement
identifié une solution ?
Si vous avez des problemes inexplicables, avec des erreurs bizarres,
notament lors de la gestion de fichiers (en nombre) ou tout autres
opérations qui demande au systeme d'allouer quantité de mémoire. Alors le
problème peut venir des barettes, notamment s'ils elle sont noname. changez
les avec des barettes garantie pour vous en assuré (ou faite un test_mem).
Sinon, vous devriez utilisez le nmake de microsoft. Au moins ca ca marche.
"Patrick 'Zener' Brunet" wrote in message news:eoirmv$ihq$
Bonjour.
J'avais lancé une discussion sur fco.ms-windows, début décembre, car à l'époque ça ressemblait à un problème de driver... elf5of$bfo$ Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de petits fichiers de texte (<20Ko), le traitement se faisant par des
commandes
DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout sous contrôle d'un makefile.
Le crash peut arriver même entre deux copy, et donc le seul vrai programme
à
tourner à ce moment est make.exe (v.3.75). La cause semble liée au
"débit",
puisque je le rends moins probable en rajoutant un délai d'une seconde
entre
chaque traitement de fichier. Le dump est inexploitable: plantage dans ntoskrnl.exe dû à une corruption
de
mémoire... bien avant. Je pense aussi avoir innocenté tous les drivers.
Depuis, en cherchant sur les multiples forums hors Usenet, il semble qu'il
y
ait un vrai problème avec GNU make sous Windows, mais sans plus de précisions ni de solution (à part "de jeter Windows et de passer sous Linux", bien sûr). Voir par exemple: http://www.cygwin.com/ml/cygwin/2004-03/msg00937.html http://lists.freepascal.org/lists/fpc-devel/2001-January/000711.html
Est-ce que ceux d'entre-vous qui compilent à l'ancienne (makefiles manuels plutôt que cliquodromes) ont déjà rencontré ce problème, et idéalement identifié une solution ?
Si vous avez des problemes inexplicables, avec des erreurs bizarres, notament lors de la gestion de fichiers (en nombre) ou tout autres opérations qui demande au systeme d'allouer quantité de mémoire. Alors le problème peut venir des barettes, notamment s'ils elle sont noname. changez les avec des barettes garantie pour vous en assuré (ou faite un test_mem).
Sinon, vous devriez utilisez le nmake de microsoft. Au moins ca ca marche.
VB
Patrick 'Zener' Brunet
Bonsoir.
"Thierry Murail" a écrit dans le message de news: 45ad049b$0$293$
Bonjour,
> J'avais lancé une discussion sur fco.ms-windows, début décembre, car à > l'époque ça ressemblait à un problème de driver... > elf5of$bfo$ > Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de > petits fichiers de texte (<20Ko), le traitement se faisant par des > commandes > DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout
sous
> contrôle d'un makefile.
A mon avis la machine a un driver foireux. Essaye de faire cette compile
sur
une autre... Quel OS ?
Win2000 Pro + SP4.
Le système a été réinstallé depuis, sans effet sur ce problème. Il n'y a aucun problème avec des choses très gourmandes telles que la vidéo, les copies/destructions massives de fichiers, la comm Internet, etc. Uniquement ce cas.
Avant d'en arriver à cette conclusion, j'ai passé beaucoup de temps à essayer de cerner un driver foireux, avec Verifier et en désactivant même l'anti-virus... Ils sont tous très sages pendant cette opération.
A moi aussi il me paraît peu naturel qu'une appli en mode console arrive à provoquer un BSOD, mais selon les liens que j'ai donnés par exemple, c'est arrivé à d'autres...
-- Cordialement. -- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonsoir.
"Thierry Murail" <yarglah@com.invalid> a écrit dans le message de news:
45ad049b$0$293$426a34cc@news.free.fr...
Bonjour,
> J'avais lancé une discussion sur fco.ms-windows, début décembre, car à
> l'époque ça ressemblait à un problème de driver...
> elf5of$bfo$1@shakotay.alphanet.ch
> Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de
> petits fichiers de texte (<20Ko), le traitement se faisant par des
> commandes
> DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout
sous
> contrôle d'un makefile.
A mon avis la machine a un driver foireux. Essaye de faire cette compile
sur
une autre...
Quel OS ?
Win2000 Pro + SP4.
Le système a été réinstallé depuis, sans effet sur ce problème.
Il n'y a aucun problème avec des choses très gourmandes telles que la vidéo,
les copies/destructions massives de fichiers, la comm Internet, etc.
Uniquement ce cas.
Avant d'en arriver à cette conclusion, j'ai passé beaucoup de temps à
essayer de cerner un driver foireux, avec Verifier et en désactivant même
l'anti-virus... Ils sont tous très sages pendant cette opération.
A moi aussi il me paraît peu naturel qu'une appli en mode console arrive à
provoquer un BSOD, mais selon les liens que j'ai donnés par exemple, c'est
arrivé à d'autres...
--
Cordialement.
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
"Thierry Murail" a écrit dans le message de news: 45ad049b$0$293$
Bonjour,
> J'avais lancé une discussion sur fco.ms-windows, début décembre, car à > l'époque ça ressemblait à un problème de driver... > elf5of$bfo$ > Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de > petits fichiers de texte (<20Ko), le traitement se faisant par des > commandes > DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout
sous
> contrôle d'un makefile.
A mon avis la machine a un driver foireux. Essaye de faire cette compile
sur
une autre... Quel OS ?
Win2000 Pro + SP4.
Le système a été réinstallé depuis, sans effet sur ce problème. Il n'y a aucun problème avec des choses très gourmandes telles que la vidéo, les copies/destructions massives de fichiers, la comm Internet, etc. Uniquement ce cas.
Avant d'en arriver à cette conclusion, j'ai passé beaucoup de temps à essayer de cerner un driver foireux, avec Verifier et en désactivant même l'anti-virus... Ils sont tous très sages pendant cette opération.
A moi aussi il me paraît peu naturel qu'une appli en mode console arrive à provoquer un BSOD, mais selon les liens que j'ai donnés par exemple, c'est arrivé à d'autres...
-- Cordialement. -- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Patrick 'Zener' Brunet
Bonsoir.
"Vincent Burel" a écrit dans le message de news: 45adf44c$0$27376$
"Patrick 'Zener' Brunet" wrote in message news:eoirmv$ihq$ > J'avais lancé une discussion sur fco.ms-windows, début décembre, car à > l'époque ça ressemblait à un problème de driver... > elf5of$bfo$ > Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de > petits fichiers de texte (<20Ko), le traitement se faisant par des commandes > DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout
sous
> contrôle d'un makefile. >
[...]
> Est-ce que ceux d'entre-vous qui compilent à l'ancienne (makefiles
manuels
> plutôt que cliquodromes) ont déjà rencontré ce problème, et idéalement > identifié une solution ?
Si vous avez des problemes inexplicables, avec des erreurs bizarres, notament lors de la gestion de fichiers (en nombre) ou tout autres opérations qui demande au systeme d'allouer quantité de mémoire. Alors le problème peut venir des barettes, notamment s'ils elle sont noname.
changez
les avec des barettes garantie pour vous en assuré (ou faite un test_mem).
Le système a été réinstallé avec soin, les barrettes changées, et de plus j'ai pris de la marque. Le problème a survécu. J'ajoute que je n'ai aucun problème avec d'autres applis bien plus critiques (vidéo, copies massives de fichiers, etc.).
Sinon, vous devriez utilisez le nmake de microsoft. Au moins ca ca marche.
Il ne supporte pas les règles implicites (pattern rules) utilisant les %, et elles sont incontournables en génération automatisée de code. C'est pourquoi je suis forcé de me taper le portage du GNU.
Merci de vos tuyaux.
-- Cordialement. -- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonsoir.
"Vincent Burel" <vincent.burel@nospam.wanadoo.fr> a écrit dans le message de
news: 45adf44c$0$27376$ba4acef3@news.orange.fr...
"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid> wrote in
message news:eoirmv$ihq$1@shakotay.alphanet.ch...
> J'avais lancé une discussion sur fco.ms-windows, début décembre, car à
> l'époque ça ressemblait à un problème de driver...
> elf5of$bfo$1@shakotay.alphanet.ch
> Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de
> petits fichiers de texte (<20Ko), le traitement se faisant par des
commandes
> DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout
sous
> contrôle d'un makefile.
>
[...]
> Est-ce que ceux d'entre-vous qui compilent à l'ancienne (makefiles
manuels
> plutôt que cliquodromes) ont déjà rencontré ce problème, et idéalement
> identifié une solution ?
Si vous avez des problemes inexplicables, avec des erreurs bizarres,
notament lors de la gestion de fichiers (en nombre) ou tout autres
opérations qui demande au systeme d'allouer quantité de mémoire. Alors le
problème peut venir des barettes, notamment s'ils elle sont noname.
changez
les avec des barettes garantie pour vous en assuré (ou faite un test_mem).
Le système a été réinstallé avec soin, les barrettes changées, et de plus
j'ai pris de la marque. Le problème a survécu.
J'ajoute que je n'ai aucun problème avec d'autres applis bien plus critiques
(vidéo, copies massives de fichiers, etc.).
Sinon, vous devriez utilisez le nmake de microsoft. Au moins ca ca marche.
Il ne supporte pas les règles implicites (pattern rules) utilisant les %, et
elles sont incontournables en génération automatisée de code. C'est pourquoi
je suis forcé de me taper le portage du GNU.
Merci de vos tuyaux.
--
Cordialement.
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
"Vincent Burel" a écrit dans le message de news: 45adf44c$0$27376$
"Patrick 'Zener' Brunet" wrote in message news:eoirmv$ihq$ > J'avais lancé une discussion sur fco.ms-windows, début décembre, car à > l'époque ça ressemblait à un problème de driver... > elf5of$bfo$ > Globalement j'ai un BSOD répétitif lors du traitement d'une multitude de > petits fichiers de texte (<20Ko), le traitement se faisant par des commandes > DOS (copy, del, type, etc.) et des outils tels que SED et M4, le tout
sous
> contrôle d'un makefile. >
[...]
> Est-ce que ceux d'entre-vous qui compilent à l'ancienne (makefiles
manuels
> plutôt que cliquodromes) ont déjà rencontré ce problème, et idéalement > identifié une solution ?
Si vous avez des problemes inexplicables, avec des erreurs bizarres, notament lors de la gestion de fichiers (en nombre) ou tout autres opérations qui demande au systeme d'allouer quantité de mémoire. Alors le problème peut venir des barettes, notamment s'ils elle sont noname.
changez
les avec des barettes garantie pour vous en assuré (ou faite un test_mem).
Le système a été réinstallé avec soin, les barrettes changées, et de plus j'ai pris de la marque. Le problème a survécu. J'ajoute que je n'ai aucun problème avec d'autres applis bien plus critiques (vidéo, copies massives de fichiers, etc.).
Sinon, vous devriez utilisez le nmake de microsoft. Au moins ca ca marche.
Il ne supporte pas les règles implicites (pattern rules) utilisant les %, et elles sont incontournables en génération automatisée de code. C'est pourquoi je suis forcé de me taper le portage du GNU.
Merci de vos tuyaux.
-- Cordialement. -- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Patrick 'Zener' Brunet
Bonsoir.
"Jseb" a écrit dans le message de news:
>Est-ce que ceux d'entre-vous qui compilent à l'ancienne (makefiles
manuels
>plutôt que cliquodromes) ont déjà rencontré ce problème, et idéalement >identifié une solution ?
Je sais qu'avec mingw (environnement simplifié que je préfère à cygwin pour mes compiles), il y a deux versions de make. Une fonctionne et fait l'objet d'un paquet à part, l'autre ne fonctionne pas bien (d'après les faqs) et est incluse dans les paquets de base. Tu peux essayer de récupérer le paquet "make" de mingw, et remplacer temporairement celui de cyngwin.
En fait je n'ai pas Cygwin, j'ai récupéré des portages indépendants de SED, M4 et MAKE.
J'ai parlé de CygWin parce que dans tout ce que j'ai pu trouver sur les forums au sujet de ce problème, il semble que soient impliqués des bugs +/- connus du code CygWin, selon les auteurs. Il faut dire aussi que chercher "make" sur Google, même avec "GNU" devant, c'est assez hasardeux.
Je vais voir si je trouve un site pour MINGW.
Merci du tuyau.
-- Cordialement. -- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonsoir.
"Jseb" <jseb@alussinan.org> a écrit dans le message de news:
buurq2lbcknoiv3p60g9i3ksbrelvm3l3i@4ax.com...
>Est-ce que ceux d'entre-vous qui compilent à l'ancienne (makefiles
manuels
>plutôt que cliquodromes) ont déjà rencontré ce problème, et idéalement
>identifié une solution ?
Je sais qu'avec mingw (environnement simplifié que je préfère à cygwin
pour mes compiles), il y a deux versions de make.
Une fonctionne et fait l'objet d'un paquet à part, l'autre ne
fonctionne pas bien (d'après les faqs) et est incluse dans les paquets
de base.
Tu peux essayer de récupérer le paquet "make" de mingw, et remplacer
temporairement celui de cyngwin.
En fait je n'ai pas Cygwin, j'ai récupéré des portages indépendants de SED,
M4 et MAKE.
J'ai parlé de CygWin parce que dans tout ce que j'ai pu trouver sur les
forums au sujet de ce problème, il semble que soient impliqués des bugs +/-
connus du code CygWin, selon les auteurs.
Il faut dire aussi que chercher "make" sur Google, même avec "GNU" devant,
c'est assez hasardeux.
Je vais voir si je trouve un site pour MINGW.
Merci du tuyau.
--
Cordialement.
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
>Est-ce que ceux d'entre-vous qui compilent à l'ancienne (makefiles
manuels
>plutôt que cliquodromes) ont déjà rencontré ce problème, et idéalement >identifié une solution ?
Je sais qu'avec mingw (environnement simplifié que je préfère à cygwin pour mes compiles), il y a deux versions de make. Une fonctionne et fait l'objet d'un paquet à part, l'autre ne fonctionne pas bien (d'après les faqs) et est incluse dans les paquets de base. Tu peux essayer de récupérer le paquet "make" de mingw, et remplacer temporairement celui de cyngwin.
En fait je n'ai pas Cygwin, j'ai récupéré des portages indépendants de SED, M4 et MAKE.
J'ai parlé de CygWin parce que dans tout ce que j'ai pu trouver sur les forums au sujet de ce problème, il semble que soient impliqués des bugs +/- connus du code CygWin, selon les auteurs. Il faut dire aussi que chercher "make" sur Google, même avec "GNU" devant, c'est assez hasardeux.
Je vais voir si je trouve un site pour MINGW.
Merci du tuyau.
-- Cordialement. -- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Thierry Murail
> Win2000 Pro + SP4.
C'est le dernier SP ? Je ne suis plus les 2K :-)
Avant d'en arriver à cette conclusion, j'ai passé beaucoup de temps à essayer de cerner un driver foireux, avec Verifier et en désactivant même l'anti-virus... Ils sont tous très sages pendant cette opération.
Voir la piste d'un probleme hard, alors. Le disque ? Essaye sur une autre machine, ou en copiant les sources dans un autre rep.
A moi aussi il me paraît peu naturel qu'une appli en mode console arrive à provoquer un BSOD,
L'appli n'est pas en cause, c'est au systeme de ne pas provoquer les BSOD.
mais selon les liens que j'ai donnés par exemple, c'est arrivé à d'autres...
Ils parlent d'un crash de make, pas de BSOD.
> Win2000 Pro + SP4.
C'est le dernier SP ? Je ne suis plus les 2K :-)
Avant d'en arriver à cette conclusion, j'ai passé beaucoup de temps à
essayer de cerner un driver foireux, avec Verifier et en désactivant même
l'anti-virus... Ils sont tous très sages pendant cette opération.
Voir la piste d'un probleme hard, alors. Le disque ?
Essaye sur une autre machine, ou en copiant les sources dans un autre rep.
A moi aussi il me paraît peu naturel qu'une appli en mode console arrive à
provoquer un BSOD,
L'appli n'est pas en cause, c'est au systeme de ne pas provoquer les BSOD.
mais selon les liens que j'ai donnés par exemple, c'est arrivé à
d'autres...
Avant d'en arriver à cette conclusion, j'ai passé beaucoup de temps à essayer de cerner un driver foireux, avec Verifier et en désactivant même l'anti-virus... Ils sont tous très sages pendant cette opération.
Voir la piste d'un probleme hard, alors. Le disque ? Essaye sur une autre machine, ou en copiant les sources dans un autre rep.
A moi aussi il me paraît peu naturel qu'une appli en mode console arrive à provoquer un BSOD,
L'appli n'est pas en cause, c'est au systeme de ne pas provoquer les BSOD.
mais selon les liens que j'ai donnés par exemple, c'est arrivé à d'autres...
