Quelle est exactement la portée de la violation d'accès '0xc0000005'?
Je me posais des questions sur l'exception 0xc0000005 et ce qu'elle englobe réellement.
C'est à dire. Je suppose que cela se produit si une application tente d'accéder à la mémoire libérée/à la mémoire appartenant à un autre processus.
Mais qu'en est-il, par exemple, d'une adresse mappée pour le matériel? Ou une adresse en dehors de la plage valide? Les tentatives d'accès à ces pannes ont-elles le même code ou ont-elles le leur? Cela inclut-il les échecs de lecture vers des adresses valides appartenant au processus?
Essentiellement, je veux savoir quand une application échoue avec cette exception, ce qui a peut-être mal tourné; est-ce une faute étroite qui ne pouvait provenir que des applications. code ou est-ce que je regarde quoi que ce soit et y compris les problèmes matériels?
(Je sais qu'il doit y avoir une page MSDN à ce sujet, mais la recherche sur Google ou MSDN fait apparaître les 100 pages attendues de dépannage des applications aléatoires;))
Merci!
Vous devez lire le manuel du processeur pour l'explorer. Il est déclenché par un "piège", mieux décrit comme une exception dans le processeur. Une interruption interrompt l'exécution de code et permet à un gestionnaire de "capture" du système d'exploitation de traiter le problème. Une erreur bénigne très courante est une erreur de page, déclenchée lorsque le processeur essaie de lire des données de RAM qui n'est pas encore mappé. C'est ainsi que la mémoire virtuelle est implémentée.
Une AccessViolation appartient à un groupe d'interruptions qui sont des erreurs matérielles que le système d'exploitation ne sait pas gérer. Il est appelé "Erreur de protection générale" dans le manuel du processeur. C'est un peu un sac à main, il existe de nombreuses façons de déclencher un GPF. De loin, la plus courante consiste à lire la mémoire non mappée, généralement causée par une corruption de la mémoire du tas. Suivi en essayant d'exécuter une instruction de code machine qui n'est pas valide ou ne peut être exécutée que par du code privilégié, généralement causé par une corruption de la mémoire de la pile.
Ces pièges sont aussi désagréables qu'ils viennent, le processeur ne peut tout simplement pas continuer à exécuter le programme. Le système d'exploitation ne sait certainement pas comment le gérer, il déclenche une exception AccessViolation pour donner au programme une chance de renvoyer le processeur au bon code. Possible en utilisant le __try/__except mots clés dans votre code. Ce n'est pas une bonne idée, à part le rapport d'erreurs personnalisé, vous n'avez aucune idée réelle de la façon dont l'état de votre programme a été modifié avant sa mort et donc aucun moyen de le restaurer.
Sans un tel gestionnaire SEH, cela se termine par un filet de sécurité fourni par Windows. Vous pouvez fournir le vôtre avec SetUnhandledExceptionFilter () , utile pour personnaliser le rapport de plantage. Celui fourni par le système y met fin en déclenchant WER, le composant de rapport d'erreurs Windows. Ce qui met finalement fin au processus.
Tout d'abord, vous devez comprendre que les adresses dans un processus en mode utilisateur sont des adresses virtuelles. Ce ne sont pas les adresses réelles utilisées pour accéder au matériel. Il y a plutôt un circuit de traduction virtuel-physique dans le CPU (qui fait partie de l'unité de gestion de mémoire) qui trouve une entrée correspondante dans le "Translation Lookaside Buffer". Lors de chaque changement de contexte, le système d'exploitation remplit le TLB avec les mappages de mémoire appartenant à votre processus.
Il n'y a donc aucun moyen d'essayer d'accéder à la mémoire appartenant à d'autres processus, ni d'essayer d'accéder au matériel. Ce n'est pas que cet accès soit détecté et échoue, c'est qu'aucun mappage n'existe pour la mémoire qui n'appartient pas à votre programme.
Si votre programme accède à une adresse qui ne correspond à aucun endroit, un piège se produira, comme l'a dit Hans. C'est le même piège pour les "défauts de page" et les "violations d'accès". D'abord, le système d'exploitation vérifiera si l'adresse est valide mais pas dans le TLB (par exemple, votre PC a manqué de mémoire et une partie a été échangée sur le disque). Dans ce cas, le système d'exploitation remettra les données dans la RAM physique, définira le mappage approprié dans le TLB et continuera d'exécuter votre programme. Si le système d'exploitation détermine que l'adresse est complètement invalide (aucun emplacement de swap ne lui est associé), il générera une "violation d'accès" (dénomination Windows) ou une "erreur de segmentation" (dénomination POSIX).
Habituellement, la cause est un bug logique, mais si vous aviez par exemple a RAM qui a un peu changé dans l'un de vos pointeurs, la défaillance matérielle peut également déclencher une violation d'accès.
J'ai obtenu this comme premier résultat pour "violation d'accès" (sans guillemets) sur google. Je ne suis pas sûr des détails, mais un AV signifie simplement que: le processeur a essayé de lire ou d'écrire à une adresse particulière que son état actuel ne permettait pas. Il peut s'agir d'un problème matériel, d'une erreur de bus, d'une mémoire virtuelle non mappée, d'un mauvais processeur; à peu près tout ce qui indique une violation des protections d'accès.