Excel 2021 x64 plante de manière intermittente (erreur 0xC0000005) avec VBA — plusieurs signatures de vidage WER

Merci. J'ai suivi votre recommandation et j'ai vérifié physiquement. VBE > Tools > Referencessur une copie d'assurance qualité isolée.

Aucune référence vérifiée n'est marquée MISSING . Cinq références sont activées et toutes sont présentes

Avant de mettre en œuvre votre deuxième recommandation (exporter/réimporter le projet VBA dans un classeur vierge), j'ai effectué un inventaire complet car il s'agit d'un projet de grande envergure.

Le classeur contient actuellement 237 feuilles de calcul , tandis que l'inventaire du projet VBA extrait contient 426 composants VBA . En particulier, 137 composants nommés comme des modules de feuille de calcul ( Feuil…) n'a pu être associé à aucun nom de code de feuille de calcul actuelle . L'extraction révèle également deux composants nommés **** ThisWorkbook, et au moins un UserForm dont les ressources associées ne peuvent être fidèlement récupérées avec la méthode d'extraction dont je dispose.

J'ai donc arrêté avant de reconstruire quoi que ce soit, car une opération d'exportation/importation standard pouvait produire un classeur qui n'était pas structurellement équivalent à l'original.

Pourriez-vous me conseiller, s'il vous plaît ?

Est-il possible pour un Excel .xlsmUn projet VBA doit-il légitimement contenir des modules de documents de feuilles de calcul historiques/orphelins qui ne correspondent plus aux noms de code des feuilles de calcul actuelles ?

Peut dupliquer ThisWorkbookLes composants apparaissent-ils légitimement dans la représentation interne du projet VBA, ou cela suggérerait-il un artefact d'extraction ou une incohérence du projet ?

Quelle méthode prise en charge par Microsoft recommanderiez-vous pour reconstruire un projet Excel VBA complexe tout en préservant les modules du document de feuille de calcul ? ThisWorkbook, noms de code de feuille de calcul, ressources UserForms/FRX, références et liaisons d'événements ?

Compte tenu de l'intermittence 0xC0000005Des plantages ayant déjà été documentés, recommanderiez-vous d'examiner ces modules de documentation non appariés avant de tenter une reconstruction ?

Je n'ai ni modifié ni reconstruit le classeur . Le classeur original et la copie de contrôle qualité conservent leurs hachages SHA-256 attendus.

Je peux fournir un manifeste de composant anonymisé si nécessaire, mais je ne publierai pas publiquement le classeur ni les vidages mémoire complets.

Merci pour vos recommandations. Le mode sans échec a déjà été testé et Office a déjà été mis à jour depuis la dernière version. 16.0.20430.20092 à 16.0.20430.20140; un nouveau 0xC0000005L'accident s'est également produit sous 20140.

Je n'ai actuellement pas accès à un deuxième ordinateur comparable.

Je vais donc procéder à l'exécution de vos recommandations dans cet ordre :

Vérifiez toutes les références VBA pour toute MISSINGdépendance;

S'il n'en manque aucun, testez une reconstruction contrôlée du projet VBA dans un classeur expérimental propre.

Le projet est exceptionnellement volumineux (environ 426 composants, y compris les modules standard, les classes, les formulaires utilisateur, les modules de feuille de calcul et ThisWorkbookPourriez-vous préciser si Microsoft recommande une méthode particulière pour reconstruire un tel projet tout en préservant les UserForms, les CodeNames des feuilles de calcul, les références et les liaisons d'événements ?

Je reporte la réparation d'Office jusqu'après ces tests afin de ne modifier qu'une seule variable à la fois.

Bonjour,

Merci pour votre réponse.

Plusieurs des contrôles proposés ont déjà été réalisés dans le cadre de notre diagnostic.

1. Mode sans échec : déjà testé. Les essais courts n'ont pas reproduit le crash, mais le défaut étant intermittent, cela n'a pas permis d'identifier une cause.

2. Reconstruction du projet VBA : c'est effectivement l'une des pistes que nous envisagions. Le projet est toutefois important (environ 426 composants, avec modules standards, classes, modules de feuilles, ThisWorkbook et UserForms). Nous souhaitons donc préserver strictement l'équivalence du projet lors de l'export/réimport.

3. Références VBA : nous allons confirmer formellement l'absence de références MISSING.

4. Réparation Office : elle n'a pas encore été effectuée, car nous souhaitons éviter de modifier plusieurs variables simultanément avant d'avoir terminé les tests discriminants.

5. Test sur un autre ordinateur : nous allons privilégier cette étape, idéalement avec la même architecture et la même build Office, afin de distinguer un problème lié au classeur/projet VBA d'un problème propre à l'environnement de la machine.

Pour information, Office a déjà été mis à jour de 16.0.20430.20092 vers 16.0.20430.20140. Un nouveau crash 0xC0000005 est survenu sous 20140, de sorte qu'un simple retour à 20092 ne nous paraît pas, à lui seul, suffisamment discriminant.

Nous disposons par ailleurs de full dumps WER et d'analyses WinDbg montrant plusieurs signatures distinctes de 0xC0000005.

Concernant votre recommandation d'exporter/réimporter le projet VBA, pourriez-vous préciser si Microsoft recommande une procédure particulière pour reconstruire proprement un projet VBA Excel complexe comprenant modules standards, classes, UserForms, modules de feuilles et ThisWorkbook, sans perdre les références ni les liaisons aux feuilles ?

Merci pour votre aide.

(La réponse a été traduite automatiquement. Par conséquent, elle peut contenir des erreurs grammaticales ou des formulations inhabituelles.) 

Bonjour hc delloue,

Étant donné que le problème survient lors de l'utilisation d'un classeur contenant du code VBA et provoque un plantage avec l'erreur 0xC0000005 (violation d'accès), voici quelques étapes de dépannage susceptibles d'aider à en identifier la cause :

1/ Vérifiez si le plantage se produit lorsque vous lancez Excel en mode sans échec (appuyez sur les touches Windows + R, puis tapez excel.exe /safe). Cela permet de déterminer si un complément ou une personnalisation est à l'origine du problème.

2/ Créez une copie du classeur et essayez d'exporter puis d'importer tous les modules VBA dans un nouveau classeur afin d'écarter une éventuelle corruption du fichier ou du projet VBA.

3/ Dans l'éditeur VBA, vérifiez la section Outils > Références et assurez-vous qu'aucune référence n'est marquée comme « MANQUANTE » (MISSING).

4/ Exécutez la réparation rapide d'Office via le Panneau de configuration > Programmes et fonctionnalités : sélectionnez Microsoft Office Professionnel Plus 2021, puis cliquez sur Modifier.

Si nécessaire, effectuez une réparation en ligne pour garantir l'intégrité de l'installation d'Office.

5/ Testez le classeur sur un autre ordinateur disposant de la même version d'Office pour déterminer si le problème est spécifique à la machine.

En attendant, vous pouvez également tester le classeur sur une autre machine utilisant la même version (build) d'Office, ou revenir temporairement à la version précédente (16.0.20430.20092) afin de vérifier si le comportement est lié à une mise à jour récente.

Remarque : Veuillez suivre les étapes décrites dans documentation du forum pour activer les notifications par e-mail afin de recevoir la notification associée à ce fil de discussion.