Pour résumé un peu tout ca...

- Une application 32 bits utilise des pointeurs sur 32 bits pour faire références à la mémoire. Ce qui donne en théorie une plage adressable de 4go de mémoire par processus, même si celle-ci est d'emblée limitée par l'OS.
- Windows XP, ainsi que tout autres OS 32 bits basé sur l'architecture des processeurs x86, ne peut adresser que 4Go de mémoire au maximum. Cependant, une partie de cette espace adressable est réservé au système, pour par exemple gérer une zone vidéo tampon, un mapping des ports des périphériques, le stockage du bios, etc...
- De par ce fait, seule une partie de la mémoire physique installé sur votre pc peut réellement être exploitée (3,2Go de ram en moyenne), car une partie de l'espace adressable est grapillé pour l'usage propre du système (imposé par l'architecture des micro-processeurs x86).
- Pour pouvoir exploiter totalement la mémoire physique sur votre système il faut que l'OS change sa méthode de gestion de la mémoire pour les applications en exploitant le PAE (Physical address extension). Ce qui est en fait une méthode de pagination spéciale de la mémoire sur 36 bits.
- L'utilisation de ce système d'adressage est fortement dépendant des éléments de votre système (driver compatible PAE?).
- Pour pouvoir exploiter ces adresses étendues, une application doit avoir été préalablement compilée avec le flag "LargeAddressAware". C'est le cas pour FSX, mais pas pour FS9 d'origine. Il existe des solutions permettant d'altérer les éxécutables ne le gérant pas, mais avec des résultats plutôt aléatoire selon les cas. Par conséquent, lorsque vous permettez à vos processus d'exploiter une certaine quantité de mémoire (paramètre /userva du boot.ini), vous risquez en fait que ces processus référence de la mémoire "protégé", entendez par là non référencable car reservé au système pour un autre usage. Cela peut donc être, sans l'affirmer, l'explication de certaines erreurs d'accès mémoire mentionnées dans ce post.

@+

Dernière modification par Cyberstorm (22-04-2009 11:52:33)

Skyline a écrit:

g2loq a écrit:

Raf37 a écrit:

D'accord, merci.

J'espère que ça va durer en tout cas, qu'est ce que c'est bon de voler sans plantage à l'atterro sur des belles scènes (pour l'instant...)

Ca se passe sur FSX ou sur FS9 tes tests?

Renaud

Forte chance que c’est sur FSX.
Précise également si c'est un Vista SP1 ou SP2 ?

C'est sur FS9 et Vista SP1 (pas encore de SP2 à ce que je sache ??!!)

Raf37 a écrit:

C'est sur FS9 et Vista SP1 (pas encore de SP2 à ce que je sache ??!!)

Salut Raf37,

Merci pour ta réponse.
Comment est configuré ta mémoire virtuel sur Vista ?

ok
Taille personnalisée, si je lis en tout petit.

Merci.

Apparemment le problème n'est toujours pas résolu, je viens d'avoir un plantage mémoire sur LFPG d'Aerosoft avec le PMDG 747 toujours, mais cette fois-ci sur le tarmac et en changeant de vue (donc y'a du mieux )

Cyberstorm a écrit:

Pour résumé un peu tout ca...

@+

Tu as raison, comme c'est un sujet qui apparemment intéresse les membres du forum...
Je me suis permis de réécrire quelques lignes la dessus afin de corriger quelques petites erreurs.
J'espère que tu ne m'en voudra pas !...
Je ne pensais pas, lorsque j'ai voulu aider Speed que j'écrirai un sujet là dessus....





Tous les processus exécutés dans un OS Windows 32 bits  tournent dans un environnement virtuel adressage mémoire (Virtual Address Space) qui s'étend de 0 à 4 294 967 295 (2*32-1 = 4 Go)

Par construction, Microsoft pour ses OS a réparti par moitié cet environnement utilisable.
Donc pour un environnement 32 bits cela donne donc la répartition suivante :
-    2 Go pour l'espace utilisateur (Application) => 0x00000000 à 0x7FFFFFFF
-    2 Go pour l'espace système (Noyau) => 0x80000000 à 0xFFFFFFFF


Nota : Pour un environnement 64 bits la même logique a été respectée.

Les applicatifs professionnels, notamment les SGBDRs, ayant de plus en plus besoins de ressources mémoires arrivaient en saturation dans l'espace utilisateur.
Donc à cette époque là, Microsoft a regardé comment libérer un peu de ressources sur les systèmes. Il s'avait qu'une partie de l'espace système n'était pas utilisé à 100 % par le noyau et les autres composants.

Ils ont donc créée l'option 4G que vous connaissez au travers du commutateur /3GB à mettre dans le boot.ini ainsi que son compère /USERVA qui permet d'affiner la restriction d'utilisation.

Donc pour un environnement 32 bits avec l'option 4GT cela donne donc la répartition suivante :
-    3 Go pour l'espace utilisateur (Application) => 0x00000000 à 0xBFFFFFFF
-    1 Go pour l'espace système (Noyau) => 0xCFFFFFFF à 0xFFFFFFFF


Parallèlement la taille maximale d'un processus était fixée à 2Go. Ce qui tombait bien vu que c'était initialement également la taille maximale de l'espace utilisateur.
Mais, puisque l'espace utilisateur a augmenté, il fallait que l'applicatif ai été prévu pour cela.
D’où l'apparition du flag IMAGE_FILE_LARGE_ADDRESS_AWARE dans le header de l'applicatif qui permet au noyau après la lecture de celui-ci de savoir si le processus peut dépasser les 2Go standard.


Mais les choses étant ce qu'elles sont, nous avons toujours besoins de plus!... Et comme les architectures hardwares s'orientaient vers du faux 64 bits (Vrai pour le processeur, Faux pour les CM)... Les OS devaient suivre…. CQFD !...

Microsoft a donc travaillé avec ces producteurs pour nous offrir une solution qui permet de s'affranchir partiellement de cette limite des 4 Go. Cette technologie est appelée : PAE X86 et elle permet grâce à un adressage sur 36 bits d'adresser jusqu'à 64 Go de mémoire.
Cette activation se fait au travers du fameux commutateur /PAE.

Pour les amoureux de la technique

Avec l'extension PAE activée, le système d'exploitation passe de la traduction d'adresse linéaire de niveau 2 à la traduction d'adresse de niveau 3. La couche supplémentaire de traduction fournit l'accès à la mémoire au dessus de 4 Go. Plutôt qu'être divisée en trois champs différents pour l'indexation dans les tables de mémoire, l'adresse linéaire sera divisée en quatre champs : un champ en 2 bits, deux champs en 9 bits, et un champ en 12 bits correspondant à la taille de la page implémentée par l'architecture Intel (4 Ko).

C'est très bien tout cela, nous savons adresser ces nouvelles ressources mémoires, mais les applicatifs eux ne sont codés que sur 32 Bits!!!!!......Donc 4 Go!....
Il faut donc faire quelque chose pour que les applicatifs puissent prendre en compte ces nouvelles ressources.
Microsoft a donc créée un ensemble d'API appelé : Address Windowing Extensions, qui permet de répondre à ce besoin si les applications sont compilées avec celui-ci.
Le roles de ces API est de permettre de mapper une plus grande quantité de mémoire physique dans l'espace d'adressage virtuel de l'application.



Mais toutes les applications que vous allez faire tourner sur votre machine n'auront pas automatiquement cette possibilité. Donc, parallèlement, il y a eu l'apparition d'une nouvelle fonctionnalité de sécurité appelée : DEP (Data Execution Prevention) qui comme son nom l'indique fait de la prévention d'exécution.

Maintenant pour en terminer, Microsoft pour ses plates formes utilisateurs XP et Vista, a préféré brider celles ci à 4Go. Donc, bien que le PAE soit actif, vous ne dépasserez pas 4Go.

Dernière modification par Ptipilot (23-04-2009 07:52:39)

C'est principalement Ptipilote qui faut remercier. Nous on a rien fait. A si on va quand même sortir les verres.

Je crois qu'on peut sortir la Pastaga





P.S: On croise les doigts on sais jamais si ça plante encore ... lol
Et si ça plante plus d'ici 2 semaines Ptipilote pourra proposer à PMDG sa solution.

Salut les amis,

Bon le Pastaga c'est pas tout de suite pour moi .

Deux tests ce matin, les deux sans pagefile et le deuxieme apres re-install du PMDG; toujours le meme message d'OOM avec une charge totale de 1.2 a 1.3GO dont 800-900 MO pour FS9 aux abords de EBBR d'aerosoft.

Je re-teste sur un autre parcours et apres je tente la solution de Bernard...si ca fonctionne pas j'ouvre la fenetre et je m'essaie au lance d'ordinateur!

Allez, on y croit!

Renaud

L'ordinateur l'a echapppe belle!

Je viens de faire un Marseille-Madrid de plus de 2 heures avec 3 circuits d'attente et une remise de gaz pour voir si tout tenait! j'ai pu me poser avec un FS qui consommait environ 650MO pour un total de 1222MO.

Je me demande si c'est pas Bruxelles qui me joue des tours mais d'un autre cote j'ai deja eu pas mal de fois ces OOMM a d'autres endroits notamment Heathrow d'Aerosoft!

A noter que pour mon vol vers Madrid dans le cockpit du B737 sur la piste FS comsommait 450MO seulement alors que pour un depart au meme endroit pour bruxelles j'etais a deja 700MO...a n'y rien comprendre les conditions etant strictement les memes Active Sky+ Fs Passengers+FS online center pour Live ATC et visionnage des cartes.

Alain, je n'ai pas encore teste mes barrettes, c'est pour ce soir.

Suite au prochain numero....

A+

Renaud

Tu as quoi comme add-on installés, mis à part le pmdg ?

Edit:
On dit que Data Execution Prevention ou DEP fait planter certains programmes.

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Home Edition 3GB" /fastdetect /noexecute=optin /3GB /userva=2560

noexecute=optin --> DEP activé
Mémoire non exécutable ...

http://www.pcastuces.com/pratique/windows/xp/1287.htm

Qu'en pensez-vous ?

Dernière modification par Skyline (24-04-2009 19:00:54)

Bonjour les depanneurs,

Hier soir test avec MemTest 86 version 3.4 la derniere ne voulant pas demarrer, rien a signaler, pas d'erreurs. J'ai ete surpris car le test complet n'a pris qu'une heure et demi alors que je m'attendais a une nuit complete!

Ce matin, San-Fransisco-Phoenix donc 2h30 de vol sans aucun add-on (pas ASV, FS Passengers) et je n'ai aucune scene aux USA, ni mesh seulement GEPro. Resultat, vol sans encombre avec une charge FS toujours stable entre 560-650MO et un total de 900-100MO.

Pour l'europe j'ai UTE ainsi que pas mal d'aeroports mais hier mon test sur Madrid etait aussi positif. Je refais un LFML-EBBR en desactivant EBBR d'aerosoft et dans ASV et FS Passengers.

Je precise que je suis toujours sur ce boot: multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Home Edition" /fastdetect /noexecute=optin....je ne touche pas ce parametre pour le moment, hein?

Au fait vous prenez combien de l'heure?

Renaud

Snif... problème toujours pas résolu de mon côté... encore un OOM en approche de LFPG (Aerosoft) en B747 de PMDG...

PS: j'ai également UT Europe avec la version 1.12 (la dernière).

g2loq a écrit:

Hier soir test avec MemTest 86 version 3.4 la derniere ne voulant pas demarrer, rien a signaler, pas d'erreurs. J'ai ete surpris car le test complet n'a pris qu'une heure et demi alors que je m'attendais a une nuit complete!

En fait cela dépend un peu des options que tu prends...
Mais le test par défaut, prends environ ce temps là. Après, ce qui est intéressant, c'est de le laisser tout seul... Il relance le test automatiquement et te logues les erreurs.
On va la considérer comme valide.

g2loq a écrit:

Ce matin, San-Fransisco-Phoenix donc 2h30 de vol sans aucun add-on (pas ASV, FS Passengers) et je n'ai aucune scene aux USA, ni mesh seulement GEPro. Resultat, vol sans encombre avec une charge FS toujours stable entre 560-650MO et un total de 900-100MO.

C'est très intéressant , car cela fait deux vols relativement longs dans deux configurations différentes que tu fait et tu n'as pas eu de problèmes.

Donc si l'on pratique comme le Dr House et que l'on fait un diagnostique différentiel on a :
- Une mémoire que l'on peut considérer comme sans problème,
- Une configuration NT correct (Sans fichier d'échange)
Néanmoins, pour les tests suivants, on va suivre l'idée de Sky.
Dans, ton Boot.ini tu remplaces noexecute=optin par noexecute=alwaysoff. A la fin, on remettra cela correctement...

- Et une config qui maintenant nous fait des siennes pour buguer!....

Donc, on va essayez de lui provoquer un plantage!....

Le prochain test que tu vas faire, tu le fera avec tous les éléments (Active Sky+ Fs Passengers+FS online center pour Live ATC et visionnage des cartes) et dans la région qui te faisait planter le plus!....

Par contre, nous allons appeler un autre Docteur à la rescousse (Si, il veut bien bosser!... Car quelquefois, Monsieur n'est pas très prolixe de ses faveurs....).
Avant de lancer le Dr Watson, nous allons toutefois, préparer un peu le terrain.

Tu vas allez dans :
C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson

Tu trouveras deux fichiers:
- user.dmp, qui est un dump de la mémoire au moment du crash. Pas très intéressant pour nous, car nous n'avons pas le moniteur pour le lire...

- drwtsn32.log, qui est un log pré-traité qui peut éventuellement nous apporter quels renseignements.

Donc, ce dernier : tu vas le renommer (Afin, qu'il nous en crée un tout neuf pour nous...)

Maintenant, tu vas dans :
C:\WINDOWS\system32

Et, tu vas double-cliquer sur drwatson.exe juste avant de lancer ton FS.
Normalement, tu vas le voir apparaitre dans la barre des tâches.


Et, tu fais un vol en espérant que ta configue plante en nous faisant un bel OOM!....

Si tel est le cas tu notes tous les trucs dont nous avons déjà parlé (addresses de plantage, volumétrie mémoire avant, pendant et au moment du crash) et tu retournes dans le répertoire :
C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson

Si, Monsieur a bien voulu bosser, nous devrions avoir un nouveau log....

Tu me l'envoie par mail ainsi que tous les éléments collectés et je jetterai un coup d'oeil pour voir si il y a des choses intéressantes...


Aparté:
1) En début de semaine, j'ai installé sur ma config le MD11 du même producteur.
A la fin de l'installe, il m'a proposé d'installer la librairie C++ 2008.
J'ai donc répondu OK, sachant que je n'avais pas cette version sur mon poste!...
Sauf que cet abruti n'as pas vérifié que j'avais déjà une version 2005 d'installée.

Moralité des courses, j'avais les deux librairies!.... Ce qui n'est pas génial...
Donc suppressions des deux et réinstallation de la 2008!...

Comme je n'ai pas le 737, vérifie aussi que tu n'as pas ce cas de figure avant de continuer nos tests!...


2) Effectivement, as tu patché de tous les éléments déjà connu...
Bien que pour moi, avec les éléments que tu nous as remonté ton problème n'est pas un OOM dû à un manque de mémoire, mais un OOM dû a une adresse (plutôt en bas de la mémoire...) qui ne peut pas être lu car vérrouillée par le système.
Pour qui, voila la question....
Avec le log du DrWatson, nous aurons connaissance des programmes montés en mémoire et de leurs localisation géographique.

g2loq a écrit:

Au fait vous prenez combien de l'heure?

Renaud

Comme Sky....
Pour le paiement quelques barils de pétrole suffiront.


Allez, bon test....

Dernière modification par Ptipilot (25-04-2009 19:28:23)