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

Question

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

hc delloue 0

Environment

Windows 11
Office Professional Plus 2021 Retail x64
Click-to-Run, Canal actuel
Build Excel : 16.0.20430.20140
Build précédente : 16.0.20430.20092
Classeur : .xlsm avec un important projet VBA

Problème

Excel se bloque de manière intermittente avec l'erreur 0xC0000005 lors de l'utilisation de ce classeur contenant du code VBA.

Le support technique Microsoft a déjà examiné le problème et m'a orienté vers la communauté technique Excel, car il s'agit d'un problème complexe lié à des plantages Excel/VBA.

0 commentaires

4 réponses

Votre réponse

Answer 1

Darren Bruce 1,935 Conseiller(ère) indépendant(e)

(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.

hc delloue 0 Points de réputation

2026-10-07T10:58:50.4933333+00:00

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.
hc delloue 0 Points de réputation

2026-10-07T11:03:48.1333333+00:00

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.
hc delloue 0 Points de réputation

2026-10-07T12:12:38.62+00:00
Merci. J'ai effectué une analyse structurelle plus approfondie en lecture seule avant de tenter la reconstruction par exportation/importation que vous avez suggérée.

Cela a permis de faire une découverte importante.

Le classeur contient actuellement 237 feuilles de calcul, dont les modules de document VBA actifs sont Feuil138 jusqu'à Feuil374.

Cependant, les métadonnées du projet VBA (PROJECT, PROJECTwm, VBA/dir et les flux OLE) déclarent également 137 modules de document de feuille de calcul supplémentaires, ********Feuil1 à ********Feuil137, qui n'ont plus d'hôte de feuille de calcul correspondant dans le classeur actuel.

Ces 137 modules contiennent uniquement des attributs VBA ; aucune procédure VBA ni référence textuelle entrante provenant d'autres modules du projet n'a été trouvée.

Le projet déclare également deux modules de document de classeur : ********ThisWorkbook et ****ThisWorkbook1. Le classeur actuel utilise ThisWorkbook1 comme module de document hôte. L'événement Workbook_BeforeSave impliqué dans l'un des vidages mémoire sur incident existe uniquement dans ThisWorkbook1.

Il ne s'agit pas d'un artefact d'extraction : les composants sont déclarés de manière cohérente dans les métadonnées du projet VBA et les flux OLE.

Je n'ai rien supprimé, renommé ni reconstruit.

Avant de suivre la recommandation de reconstruire le projet, pourriez-vous me conseiller :

Est-il normal/pris en charge qu'un projet Excel VBA conserve des modules de document de feuille de calcul dont les hôtes de feuille de calcul n'existent plus ?

Est-il normal/pris en charge qu'un projet conserve deux modules de document de classeur alors que seul ThisWorkbook1 est l'hôte actuel ?

Microsoft recommande-t-il de reconstruire le classeur/projet spécifiquement pour supprimer ces anciens modules de document, ou faut-il les laisser intacts sauf si un lien direct avec les plantages est démontré ?

Je peux fournir un inventaire des composants anonymisé si nécessaire.
Darren Bruce 1,935 Points de réputation Conseiller(ère) indépendant(e)

2026-10-08T06:08:35.38+00:00

Since you are using English instead of French as your first question. Therefore, I will use English to response you. If there is anything unclear about my reply, please leave a comment and I will get back to you as soon as possible.

Thank you for the detailed investigation results.

Before addressing your specific questions, I would like to note that I was unable to find any Microsoft official documentation that explicitly describes the expected behavior of orphaned worksheet document modules, duplicate ThisWorkbook components, or the internal consistency rules of a VBA project after years of workbook evolution. Therefore, the comments below should be treated as general Excel/VBA observations rather than documented Microsoft guidance.

1/Regarding the unmatched worksheet document modules: in a normal VBA project, each worksheet document module is associated with an existing worksheet host. Finding a large number of modules that no longer correspond to current worksheet CodeNames would generally be unusual and may suggest legacy artifacts, workbook history, or possible project inconsistency rather than a normal workbook structure.

2/Regarding the duplicate ThisWorkbook entries: a workbook normally exposes a single active ThisWorkbook document module. Seeing two ThisWorkbook components in an extracted inventory would not be considered typical. However, from the available information it is not possible to determine whether this reflects actual project corruption or an artifact of the extraction method.

3/Regarding rebuilding the project: I would be cautious about rebuilding solely to remove these historical components. Since the workbook contains hundreds of VBA components, worksheet modules, and UserForms, a rebuild introduces its own risks (such as changes to CodeNames, event bindings, or form resources). Unless there is stronger evidence that these findings are directly related to the intermittent 0xC0000005 crashes, I would treat them as items for further investigation rather than proof of the root cause

Additionally, because this discussion has moved into advanced VBA project architecture and internals, you may benefit from seeking input through VBA-focused support channels. Microsoft maintains a page listing available VBA support and feedback resources, including developer communities and discussion forums:

Office VBA support and feedback

I hope it helps

Answer 2

Supprimé

Cette réponse a été supprimée en raison d’une violation de notre code de conduite. La réponse a été signalée manuellement ou identifiée via la détection automatisée avant que l’action ne soit entreprise. Pour obtenir plus d’informations, veuillez consulter notre code de conduite.

Les commentaires ont été désactivés. En savoir plus

Answer 3

Supprimé

Cette réponse a été supprimée en raison d’une violation de notre code de conduite. La réponse a été signalée manuellement ou identifiée via la détection automatisée avant que l’action ne soit entreprise. Pour obtenir plus d’informations, veuillez consulter notre code de conduite.

Les commentaires ont été désactivés. En savoir plus

Answer 4

hc delloue 0

Merci pour votre réponse détaillée et prudente.

Je suis d'accord : les modules de documents VBA historiques ne doivent pas être supprimés ni considérés comme la cause avérée des plantages d'Excel.

Pour information, les 137 modules de feuilles de calcul non appariés et les deux modules de documents de classeur ont été confirmés par recoupement des métadonnées PROJECT, PROJECTwm et VBA/dir, ainsi que des flux OLE sous-jacents. Ils sont bien déclarés dans le projet VBA et ne sont pas des fichiers dupliqués créés par l'outil d'extraction.

Cependant, nous n'avons établi aucun lien de causalité entre cette structure et les violations d'accès.

Nous avons donc décidé de reporter la reconstruction et de poursuivre les tests d'assurance qualité contrôlés, tout en conservant le classeur d'origine.

Une dernière question : connaissez-vous un service de diagnostic ou un canal spécialisé pris en charge par Microsoft, capable d'examiner les problèmes d'exécution d'Excel/VBE7 à l'aide de vidages mémoire WER complets et de données WinDbg ?

Merci encore pour votre aide.

Darren Bruce 1,935 Points de réputation Conseiller(ère) indépendant(e)

2026-10-08T10:00:54.9266667+00:00

Concernant votre question, je n'ai pas connaissance d'un canal public pris en charge par Microsoft qui soit spécifiquement dédié à l'analyse des plantages du moteur d'exécution (runtime) d'Excel/VBE7 à l'aide de vidages mémoire WER complets et de données WinDbg.

Si une analyse au niveau du vidage mémoire s'avère nécessaire, l'option la plus proche prise en charge par Microsoft consisterait généralement à faire appel aux services officiels du support Microsoft. Pour les questions relatives à VBA, Microsoft oriente actuellement les clients vers les canaux de support communautaires et de développement que j'ai mentionnés.
Support et commentaires sur VBA pour Office

Les forums communautaires peuvent fournir des informations sur le fonctionnement interne de VBA, mais ils ne proposent généralement pas de services officiels d'analyse de vidages mémoire. Par ailleurs, vous pouvez également exposer votre problème sur la communauté technique (Tech Community) ; vous y trouverez de nombreux experts et utilisateurs expérimentés dans le domaine d'Excel/VBA qui seront peut-être plus à même de vous aider.

https://techcommunity.microsoft.com/category/microsoft365

J'espère que vous comprenez que je fais toujours de mon mieux pour fournir des informations utiles et une assistance, dans la limite de mes connaissances et des ressources disponibles.

Si mes réponses vous ont été utiles, je vous saurais gré de cliquer sur « Oui » et d'envisager de voter pour ma réponse. Cela pourrait également aider d'autres membres de la communauté confrontés à des problèmes similaires à trouver plus facilement ces informations.

N'hésitez pas à me contacter si vous avez d'autres questions.

Passez une excellente journée et bonne chance pour la suite de vos recherches.