Microsoft 365 Plantages runtime incohérents suite à de nombreuses erreurs de runtime ou de compilation

[oguruma]

Bonsoir le Forum,
je suis persuadé que parmi les développeurs VBA vous avez déjà rencontré ce problème.
Contexte :
- développement en cours d'un projet, fonction, module, etc.
- bien évidemment il arrive que que vous rencontrez des erreur Runtime etc. etc. etc.
- pendant la phase de mise au point ces erreurs malheureusement se cumulent
- elles semblent être résolues
- et LA ! VBA plante bizarrement sur des lignes de codes inattendues qui fonctionnent très bien, ou plante sur un END SUB, un END FUNCTION, vous balance erreur Automation, erreur de pile, etc..
- Excel VBA perd les pédales... en quelques sortes
- L'arrêt d'Excel et rechargement du classeur en question ne change rien ça plante toujours
--> la mémoire est donc dans un état instable selon mon analyse
--> pas d'autre solution de se déconnecter (fermer la session et se reconnecter) ou parfois insuffisant c'est le reboot complet
--> après réinit de la session ou reboot rechargement du fichier Excel en question et là tout va bien les erreurs runtime inattendues ont disparu

Si vous avez une astuce miracle qui évite la relance de la session windows ou le reboot total je suis preneur
ps : même l'arrêt du service Microsoft via le gestionnaire de tâches ne corrige pas le problème

merci... bcp si vous avez la baguette magique qui va bien 🙂

 

[Dranreb]

Bonsoir.
Il est relativement fréquent que ce genre de chose soit dû à un processus récursif non maitrisé et d'ailleurs non voulu, généralement.
Typiquement : oubli d'un Application.Enablevents = False devant une instruction qui modifie une cellule dans une Sub Worksheet_Change, ce qui lui fait reprendre l'exécution depuis le début avec un nouveau jeu de paramètres, variables locales et adresse de retour dans le code appelant, jusqu'à rapide saturation de la pile, c'est à dire de l'espace de mémoire qui leur est réservé. Après ça peut dépendre du bout de code précis (non forcément de l'utilisateur) qui réclame un espace supplémentaire, car, malgré de nombreuse sécurités, il n'y a qu'une pile pour tout le fonctionnement du système depuis son démarrage et les conséquences peuvent aller jusqu'à son égarement total, ce qui le plante …

 

[oguruma]

Bonsoir.
Il est relativement fréquent que ce genre de chose soit dû à un processus récursif non maitrisé et d'ailleurs non voulu, généralement.
Typiquement : oubli d'un Application.Enablevents = False devant une instruction qui modifie une cellule dans une Sub Worksheet_Change, ce qui lui fait reprendre l'exécution depuis le début avec un nouveau jeu de paramètres, variables locales et adresse de retour dans le code appelant, jusqu'à rapide saturation de la pile, c'est à dire de l'espace de mémoire qui leur est réservé. Après ça peut dépendre du bout de code précis (non forcément de l'utilisateur) qui réclame un espace supplémentaire, car, malgré de nombreuse sécurités, il n'y a qu'une pile pour tout le fonctionnement du système depuis son démarrage et les conséquences peuvent aller jusqu'à son égarement total, ce qui le plante …

Bonsoir Dranreb
Merci pour cet éclairage.
Je ne suis pas réellement dans le contexte que tu décris en introduction, mais j'en prends bonne note. Toujours bon à connaître.

"car, malgré de nombreuse sécurités, il n'y a qu'une pile pour tout le fonctionnement du système depuis son démarrage et les conséquences peuvent aller jusqu'à son égarement total, ce qui le plante" ==> sur ta conclusion, quand je parlais de pile c'est en effet le constat que j'ai fait.
Après on peut dire aussi "il suffit de coder juste du 1er coup 🙂" mais cette règle est relative en fonction de la complexité de ce que l'on écrit ou quand on tente de nouvelles choses pour pousser un peu plus VBA dans ses retranchements.

Dans le passé quand je codais en C Natif de K & R, des pointeurs ou tableaux de pointeurs mis en place de manière sauvage ou mal gérés, la sanction était immédiate - plantage du système - reboot - bon ça c'était sous le bon vieux MS-DOS 😉

 

[mapomme]

Bonjour à tous😉,

L'arrêt d'Excel et rechargement du classeur en question ne change rien ça plante toujours

pour le cas que vous décrivez, Il m'est arrivé plusieurs fois qu'un redémarrage d'Excel ne suffise pas et qu'il faille arrêter Windows et le relancer.
Ce n'est pas uniquement la pile Excel qui est altérée mais aussi le système (Windows, Excel) qui semble affecté. Conclusion sans doute hâtive, mais à chaque fois cela a fonctionné. Donc maintenant quand des choses étranges se produisent, allez hop, un vrai arrêt suivi d'un vrai démarrage.

 

[Dranreb]

Bonjour.

Je ne suis pas réellement dans le contexte que tu décris en introduction

Ben si, vous y êtes si vous avez une saturation de la pile. Il faut absolument trouver d'où ça vient et y remédier !

 

[oguruma]

Bonjour à tous😉,


pour le cas que vous décrivez, Il m'est arrivé plusieurs fois qu'un redémarrage d'Excel ne suffise pas et qu'il faille arrêter Windows et le relancer.
Ce n'est pas uniquement la pile Excel qui est altérée mais aussi le système (Windows, Excel) qui semble affecté. Conclusion sans doute hâtive, mais à chaque fois cela a fonctionné. Donc maintenant quand des choses étranges se produisent, allez hop, un vrai arrêt suivi d'un vrai démarrage.

Bonjour MaPomme, le Forum,
" Donc maintenant quand des choses étranges se produisent, allez hop, un vrai arrêt suivi d'un vrai démarrage." ==> j'en suis aussi venu à cette conclusion.
Pour faire simple en dehors de toutes sécurisations possibles dans le code pour éviter cela, je penche plus que c'est du côté d'Excel la solution.
A chaque erreur répétitive VBA/excel est dans un état instable et la balle est chez $Krosoft - exprimé comme ceci c'est facile comme on pourrait le dire.

 

[Dranreb]

Vous ne pouvez pas joindre un classeur, qu'on puisse chercher ce qui provoque le processus récursif intempestif ?

 

[oguruma]

Vous ne pouvez pas joindre un classeur, qu'on puisse chercher ce qui provoque le processus récursif intempestif ?

Rebonjour,
Merci pour la proposition "bouée de sauvetage" 🙂 depuis le prb est résolu. Je pourrais fournir plusieurs fichiers à ce titre.
Mais bientôt il y aura un cas concret et bien complet en code : LIBMAC 3.3 qui sera bientôt publié dans les ressources.
Ce dernier a subi quelques tests en grande volumétrie ce qui m'a permis de découvrir quelques failles.
Il y aura aussi une compilation des extractions de modules et de Rq Pwq dans un seul et unique répertoire et lieu et place de disperser ces extractions dans les répertoires qui hébergent les classeurs Excel. En fait on aura le choix. Soit placer l'extraction dans les répertoires respectifs soit la placer dans un répertoire central.
La libération de la log cumulée dans une collection se fait désormais par paquet de 100 lignes dans le fichier. Dans le fichier actuel elle se fait en fin de traitement. En fonction de la volumétrie des traitements cette libération de log en grosse quantité "freezait" Excel. Ce sont les traitements en grosse volumétrie qui m'on permis de le découvrir.
Le traitement en grosse volumétrie consiste à l'exploration d'un dossier comportant environ 5000 fichiers Excel dupliqués et créés pour l'occasion.
Tout se déroulait très bien pour dossier comportant peu de fichiers Excel. Et c'est à travers ces tests que j'ai eu ces problèmes de pile avec plantages successifs liés bien entendu à des erreurs de code avec résolution au fil de l'eau quand ceux-ci survenaient.
Pour conclure, ce qui est étrange au moment du plantage quand on continue le code en mode debug sur "la-dite" ligne qui ne fonctionne pas, le code se déroule normalement et jusqu'au bout en mode pas-à-pas avec la touche F8 mais dès l'on relance sans le mode debug pas-à-pas ça plante de nouveau.
Donc grand merci pour cette proposition, la nouvelle version devrait être bientôt dans les bacs. Bon Week-End.