Erreurs, bugs, questions - page 2456
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Est-il préférable de ne pas ouvrir Metatrader sur votre téléphone ? Ou est-ce sans intérêt ?
Vous pouvez ouvrir un terminal sur votre PC local ou sur votre téléphone - vous avez besoin de surveiller les transactions, n'est-ce pas ? L'essentiel est de ne pas se retrouver dans une situation où l'abonnement au signal est activé en même temps sur deux terminaux.
Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading
Bugs, bugs, questions
Alexey Kozitsyn, 2019.05.03 11:24
Il n'est pas possible d'entrer un fichier avec # dans son nom dans le stockage. Est-ce un comportement normal ou un bug ?Après avoir redémarré le PC, le fichier d'inclusion du projet (*.mqh) était complètement vide (toutes les données ont été écrasées donc NUL (0x00)).
C'est quoi ce bordel ?
Faites des sauvegardes, si la compilation du code peut faire disparaître les données de l'utilisateur pour toujours, ce n'est pas le cas.
Un fichier dont le nom contient un # ne peut pas être ajouté au stockage. Est-ce un comportement normal ou un bug ?
Lors de la compilation du projet dans ME (build 2025), Win10 s'est planté (pas de mini-dump).
Après avoir redémarré le PC, le fichier du projet (*.mqh) s'est avéré être complètement vide (toutes les données ont été écrasées par NUL (0x00)).
C'est quoi ce bordel ?
Faites des sauvegardes, si la compilation du code peut faire disparaître les données de l'utilisateur pour toujours, ce n'est pas le cas.
Quel type d'erreur était indiqué dans le BSOD ?
Quelle est la fréquence de ce comportement ?
J'en ai entendu parler par une connaissance, lorsque je travaillais avec VS, lors de la compilation (très rarement, pas plus d'une fois par mois) il y avait un BSOD, après lequel le contenu des fichiers sources semblait être rempli de zéros.
Je ne me souviens pas des détails, mais le problème a été résolu en remplaçant le PC.
Le compilateur MQL n'utilise aucune astuce et lit le contenu des fichiers de compilation de manière simple et fiable :
Si l'erreur se produit fréquemment, essayez par exemple de désactiver l'antivirus.
Quelle erreur était indiquée dans le BSOD ?
Merci beaucoup pour cette réponse détaillée.
Le BSOD a pris la forme d'un redémarrage du PC, donc pas de code d'erreur ni de fichier minidump.
Rien d'intéressant dans les journaux d'événements (le standard "Le système a redémarré sans s'arrêter proprement d'abord...").
Le problème de l'effacement du fichier n'est pas nouveau, il s'est produit il y a 3 ans sur Windwos 7, le code source du fichier mq4 a été effacé lors de la compilation/débogage pendant le BSOD.
Il y a environ 2 ans, un utilisateur a également signalé ce problème sur le forum, mais aucun commentaire n'a pu être trouvé.
Quelle est la fréquence de ce comportement ?
Pas de BSOD depuis environ 9 mois, mais c'est le 3ème la semaine dernière (une fois un BSOD avec MEMORY CORRUPTION dans le processus du noyau, la seconde fois un gel de Windows, aujourd'hui un reboot pendant la compilation/débogage dans MT).
A part skype, rien de nouveau n'a été installé, le supprimer n'a pas aidé.
Le problème d'essuyage se produit lorsqu'un arrêt non standard de Windows frappe la compilation/débogage de MT.
Aujourd'hui, le travail réel a été écrasé, et non un morceau de code de test comme c'était le cas auparavant (il y a quelques années) - il y a donc une réaction à l'incident.
Si l'erreur se produit souvent, essayez de désactiver l'antivirus, par exemple
Le problème est d'avoir ce problème, et non de trouver une solution de contournement.
Je vais vérifier comment les fichiers sont enregistrés avant de commencer la compilation.
Ce n'est pas difficile pour moi de le chercher moi-même,
Malheureusement, je n'ai aucune connaissance du comportement en cas de crash du système d'exploitation, donc nous supposerons, sur la base du résultat, que toutes les données sources *.mqh sont écrasées à 0x00.
Que se passe-t-il lorsque vous compilez le projet dans MT5 (build 2025) :
1. La première chose qui attire mon attention est que je passe par tous les onglets dans ME et que j'écris des flux NTFS pour chacun des fichiers ouverts.
J'ai > 50 onglets ouverts, dont 8 fichiers de projet.
En conséquence, pour une compilation de projet, nous obtenons (8 + 50) * 2 = 116 fichiers de flux NTFS écrasés de 440 octets chacun.
Sur un SSD, cela prend 0,2 seconde.
2. Si vous trouvez un fichier avec des modifications et qu'il existe sur le disque, il est écrasé par les nouvelles données de la mémoire.
L'écrasement a lieu pour tous les fichiers modifiés, qu'ils appartiennent ou non à ce projet.
Il est très probable qu'à la suite d'un crash, Windows soit vidé de la mémoire allouée dans ME pour la source *.mqh, mais le thread qui écrit dans le fichier continue son travail.
Par conséquent, lors de l'enregistrement des modifications dans le fichier, le nombre d'octets à écrire est correct, mais la référence pointe vers la mémoire déjà effacée, écrasant le code source dans \x00.
Après avoir changé le mot de passe du compte, il n'est pas possible de se connecter à metaeditor avec le nouveau mot de passe et d'accéder au référentiel.
Si vous récupérez votre mot de passe, vous pouvez vous reconnecter.
ce n'est pas une blague ou une histoire vraie, c'est une alerte d'erreur. Essayez de changer le mot de passe via le site web, puis connectez-vous au référentiel via metaeditor.