Comment puis-je déboguer un contrôle ActiveX (OCX), ou de faire des erreurs dans le journal?
Je suis actuellement en train de travailler avec un vieux Borland C++, qui est une application à l'aide d'un composant ActiveX pour dessiner des graphiques. Dans l'application de multiples de windows avec l'ActiveX comp. peut être ouverte à tout moment; celles - ci peuvent montrer le même graphique (différentes facteur de zoom, etc), ou de graphiques.
L'application est pour le positionnement, et l'ActiveX est le dessin et montrant les positions des différentes unités.
Environ 10 fois par seconde Borland application a obtenu un nouveau poste, et découvre les formes (et de leur ActiveX) a besoin de savoir à propos de la mise à jour de position afin de dessiner. Cela va bien pendant un long moment, mais j'ai eu à le faire tout à fait quelques changements dans l'ActiveX pour une nouvelle version du produit.
Environ un an, j'ai eu à faire quelques changements mineurs dans le composant aswell, et j'ai trouvé que l'application pourrait finir dans un état, provoquant un "index out of bounds" erreur dans le composant. Le résultat de ce n'était pas une erreur lors de l'obtention affichée ou le programme de la résiliation, mais plutôt l'application a commencé à utiliser une grande quantité de mémoire - et continué à aller très vite. À un certain moment il s'est arrêté et la composante de l'erreur tout simplement cessé de montrer quoi que ce soit (arrêté de dessiner lui-même).
Maintenant avec les dernières modifications que j'ai faites, j'ai le même problème dont l'une des composantes semble être une erreur, ce qui n'est pas montré, et au lieu de cela, il n'est pas redessiner lui-même, et l'utilisation de la mémoire va ciel élevé. Sur certains PC, il semble qu'une Violation d'Accès est jeté qui est en train de dire que l'erreur qui s'est passé dans l'OCX, mais sur PC je développe, je ne peux pas obtenir cette Violation d'Accès en aucune façon.
Aussi je n'arrive pas à suivre exactement quand l'erreur se produit - c'est à dire ce qui est à l'origine de l'erreur. Je peux exécuter le programme d'installation même 10 fois de suite pendant 15 minutes, parfois, il arrive que l'utilisation de la mémoire monter et un composant d'un bug, d'autres fois il ne se passe rien et il fonctionne comme il se doit pour toute la durée.
Que c'est un OCX, il est enregistré à l'aide regsvr32, et est donc au niveau du code ne fait pas partie de la demande principale. Donc je ne peux pas utiliser les points d'arrêt et le corriger de cette façon.
Je suis sûr que certains d'erreur qui se passe à l'intérieur du composant, ce qui n'est pas passé, donc je ne vois pas ce que c'est.
Donc faire ce que quelqu'un sais comment je peut corriger cela? Puis-je faire en quelque sorte l'OCX journal des erreurs qui se passe, ou en faire apparaître l'erreur, ou que puis-je faire?
Toute aide serait grandement apprécié essayé de retrouver l'erreur 3 jours maintenant sans résultat, afin que jamais.
Je peux, en effet, de modifier et de construire l'ocx. Je ne suis pas du tout familier avec les MFC et OCX, donc je ne suis pas tout à fait sûr sur la façon d'utiliser les fichiers PDB et attacher le débogueur au processus en cours d'exécution?
OriginalL'auteur Knirkegaard | 2012-09-06
Vous devez vous connecter pour publier un commentaire.
Essentiellement, vous vous demandez comment déboguer une DLL. Un OCX est juste un fichier DLL qui est chargée dans un processus. C'est un peu vaste sujet, mais je vais essayer de donner un bref début:
DLL /EXE fichiers OCX sont généralement appelées "modules" dans le contexte de la programmation sous Windows. Ils sont tous essentiellement la même chose. Je vais les appeler des Dll ici, mais juste par souci de clarté.
Débogueurs (Visual Studio Borland sont à la fois des débogueurs ainsi que des IDEs) "joindre", comme un parasite, aux processus, vous permettant de faire des choses comme l'ensemble des points d'arrêt, de lecture de la mémoire du processus, voir la trace de la pile, etc. Ils peuvent voir et de manipuler la mémoire & ressources pour ce processus, y compris toutes les Dll.
Dll ne contient pas beaucoup d'informations pour aider les débogueurs, même dans une version de débogage. En fait, ils contiennent simplement binaire en code machine et si vous entrez dans un appel de DLL avec le débogueur, vous ne serez en mesure de voir le code assembleur -- pas le code source d'origine. Les fonctions sont quelques adresses dans la mémoire, les variables locales ne sont même pas visibles, vous ne obtenir quelques conseils dans la pile mémoire.
Fichiers PDB ("programme de base de données") contiennent toutes les informations complémentaires et les métadonnées pour le débogueur de faire des choses comme le mappage d'adresses dans la mémoire de lignes de code source, les variables locales, les types de données, des signatures de fonction, etc. Cette information est appelée "les symboles de débogage" ou tout simplement "symboles". Lorsque Visual Studio génère une DLL, il génère un fichier PDB correspondant. C'est ce fichier PDB qui permet à toute la magie de pas à pas dans votre code source dans le débogueur, la visualisation de variables locales, l'affichage des types de données correctement dans la fenêtre espion.
Lorsque Visual Studio débogueur est attaché à un processus et voit une DLL en cours de chargement, il cherche sa correspondante fichier PDB. Il recherche dans un certain nombre de lieux - la plus simple de ce qui est dans le même dossier que la DLL. Donc, si vous avez chargé
C:\something\myctl.ocx
, il va chercher lesC:\something\myctl.pdb
. Si l'on peut le trouver, il va l'utiliser et vous pouvez déboguer le fichier DLL avec de riches débogueur. Si elle ne le trouvez pas, vous serez où vous êtes maintenant - où DLL appels sont une boîte noire, vous ne pouvez pas voir.Microsoft fournit même les fichiers PDB pour les Dll de Windows comme
ntdll.dll
. Ils doivent être téléchargés en tant que de besoin. Visual Studio peut faire cela automatiquement en vaTools -> Options -> Debugging -> Symbols
et il devrait y avoir une option pour utiliser Microsoft Serveurs de symboles pour extraire automatiquement symbole manquant fichiers.Petit exemple pour vous mettre dans la bonne direction:
Disons que vous avez écrit un OCX appelé
myctl.ocx
qui se bloque lorsqu'il est ajouté à un document Wordpad. La façon de déboguer c'est d'attacher le débogueurwordpad.exe
. Dans Visual StudioDebug -> Attach to Process
je crois. Quand il est attaché, vous pouvez même voir dans la fenêtre de sortie:Vous pouvez voir comment Visual Studio charge les fichiers PDB (les fichiers de symboles) qui fournissent un peu plus d'informations pour ces. Lorsque vous chargez
myctl.ocx
, vous verrez que en ligne. Simyctl.pdb
est accessible, il se charge aussi bien.Avec cela, vous pouvez déboguer n'importe quoi dans
myctl.ocx
avec le code source et tout et tout. Lorsque Wordpad se bloque à l'intérieur demyctl.ocx
, il devrait vous montrer le code source et tout et tout, en supposant encore une fois il est dans un endroit accessible.OriginalL'auteur tenfour
Ajouter du code à la OCX qui ouvre un fichier et imprime ce qui se passe, peut-être avec un horodatage. Le contenu du journal pourrait inclure le flux d'exécution, les valeurs d'entrée, critique les valeurs de la variable, important interne de l'état.
C'est du moins la façon dont je l'approche.
OriginalL'auteur wallyk
Comment déboguer OCX/C++ dans l'IE.10 + WIN8 64bit + VS2008
C:\Program Files (x86)\Internet Explorer\iexplore.exe,Attach = Yes,Debugger Type=Native Only
OriginalL'auteur Sparkler Chen