Lors de l'exécution de l'un de nos logiciels, un testeur était confronté à la boîte de dialogue de prévention d'exécution des données de Windows.Prévention de l'exécution des données de piste (DEP)
Nous essayons de reproduire cette situation sur un ordinateur développeur à des fins de débogage: sans succès.
Est-ce que quelqu'un sait comment trouver ce qui peut causer la protection DEP pour tuer l'application? Existe-t-il des outils disponibles pour cela?
La boîte de dialogue DEP s'affiche généralement uniquement lorsque vous tentez d'exécuter du code à partir d'une région que vous ne marquez pas en tant qu'exécutable. Cela peut être dû à des «thunks» dans une bibliothèque que vous utilisez, par ex. Fenêtre ATL. Ce problème est résolu dans ATL 8.0. Un bogue de pile-trashing - par exemple, un dépassement de mémoire tampon - peut également provoquer ce problème, en définissant l'adresse de retour à un emplacement qui n'est pas exécutable. Cela peut ne pas provoquer une violation d'accès, mais plutôt un comportement étrange, si DEP est désactivé pour le processus ou n'est pas disponible sur le matériel.
Cela peut également se produire si vous lancez une exception C++ ou déclenchez une exception SEH, et que vos gestionnaires d'exceptions structurés ont été supprimés par un dépassement de mémoire tampon.
Potentiellement, je pense que chaque fois que vous essayez d'écrire en mémoire qui n'est pas alloué ce serait un résultat possible. Cela pourrait être quelque chose comme supprimer un objet puis l'utiliser, ou écrire une chaîne dans un tampon qui est trop petit pour le contenir.
DEP est influencé par la présence de fonctionnalités matérielles. Nous avons récemment eu une situation où notre application fonctionnait correctement sur les anciennes machines, mais échouait sur les nouvelles. Il s'est avéré que même si DEP était activé à la fois sur les anciens serveurs et sur les nouveaux serveurs, nous nous sommes plantés sur les nouveaux parce que la détection du matériel était meilleure, plus agressive ou quelque chose comme ça. Donc si votre QA peut se reproduire mais que le DEV ne le peut pas, alors essayez avec du matériel identique ... Bien qu'il semble déraisonnable que le QA ait un PC plus récent/meilleur que le dev ... Je le crois totalement!
Voici mes notes sur notre récente expérience avec ceci: Incompatibilities between Indy 9 and Windows Server 2003?
Je connais toutes les raisons que DEP peut tuer mon application. Le problème est que l'application est de 10 ans en attente, contient beaucoup de code et de bibliothèques. C'est un peu un problème de trouver la cause possible "à la main". – Nicolas
Une fois l'erreur effacée, vous êtes à peu près SOL si vous ne disposez pas d'une sauvegarde de pile ou d'une journalisation très détaillée. Traquer et résoudre ces problèmes quand ils ne sont pas facilement reproductibles est juste là avec le problème d'arrêt. – tloach