2010-12-14 101 views
1

J'étudie un crash d'une application sur laquelle je travaille. La partie visuelle de base est un formulaire simple qui crée des PictureBox et des boutons. Les appels sont faits au C + dll sur les clics de bouton. Les PictureBox fournissent des handles à la DLL qui les utilise pour créer des fenêtres à l'aide de WINAPI et les affiche dans OpenGL.Violation d'accès dans MSVBVM60.dll avec VB6 et C++ dll

Initialement, les vues sont créées dans les PictureBox sans problème et s'affichent correctement, mais lors d'un événement de réinitialisation, les vues sont détruites et recréées. C'est quand le crash arrive.

J'ai essayé de nombreux outils, vérificateur d'application, Windbg et outil de diagnostic de débogage. Les deux Windbg et Debug Diagnostic Tool pointent vers l'endroit, mais je ne sais pas comment le réparer.

Malheureusement, le passage de VB6 n'est pas une option pour moi car il est hors de mon contrôle.

Veuillez suivre les liens vers les journaux de plantage.

link text (coshe autorisés à poster 1 lien, mais les deux journaux sont visibles)

Toute aide grandement appréciée,

Leon

+0

Probablement quelque chose dans les appels de l'API C++ plutôt que de faire quoi que ce soit avec le VB6 en tant que tel. Peut-être détruit-il les poignées Windows qui ne lui appartiennent pas? – MarkJ

+0

Ce serait aussi mon choix, vous mettez probablement en cache un handle de fenêtre ou un autre handle dans le code C++ qui n'est plus valide après la réinitialisation, mais le code essaie toujours de l'utiliser. – DarinH

+0

Avez-vous essayé de charger le code C++ avec la connexion à l'ID où il échoue? – DarinH

Répondre

2

De votre fichier texte:

(134c.1344): Access violation - code c0000005 (first chance) 
First chance exceptions are reported before any exception handling. 
This exception may be expected and handled. 
eax=034b0ebc ebx=00000000 ecx=7352e100 edx=00000000 esi=02e6813c edi=02e6813c 
eip=7349fdd2 esp=0012fc20 ebp=0012fc44 iopl=0   nv up ei pl nz na po nc 
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000    efl=00010202 
MSVBVM60!HrMenuHandleMenuCommand+0x3f: 
7349fdd2 ffb048010000 push dword ptr <Unloaded_Ed20.dll>+0x147 (00000148)[eax] ds:0023:034b1004=???????? 
0:000> kb 
ChildEBP RetAddr Args to Child    
0012fc28 7347e1b9 034b0ebc 00000000 02e92ee8 MSVBVM60!HrMenuHandleMenuCommand+0x3f 
0012fc44 7347dc27 034b0ebc 000f144a 00000111 MSVBVM60!_DefWmCommand+0xc7 
0012fcb0 734d378a 02e92ee8 000f144a 00000111 MSVBVM60!VBDefControlProc+0xb47 
0012fcf0 7347ce03 034b0ebc 000f144a 00000111 MSVBVM60!PixCtlProc+0x57c 
0012fd18 7347f800 034b0ebc 000f144a 00000111 MSVBVM60!CommonGizWndProc+0xae 
0012fd74 7e418734 000f144a 00000111 00000000 MSVBVM60!StdCtlWndProc+0x232 
0012fda0 7e418816 7347f5d1 000f144a 00000111 USER32!InternalCallWinProc+0x28 
0012fe08 7e4189cd 00000000 7347f5d1 000f144a USER32!UserCallWinProcCheckWow+0x150 
0012fe68 7e4196c7 0012fe90 00000001 0012feb8 USER32!DispatchMessageWorker+0x306 
0012fe78 7342a6b0 0012fe90 ffffffff 02e76fec USER32!DispatchMessageA+0xf 
0012feb8 7342a627 ffffffff 02e78f8c 02e60000 MSVBVM60!ThunderMsgLoop+0xfd 
0012fecc 7342a5c9 02e76fec ffffffff 02e7efcc MSVBVM60!CMsoCMHandler::FPushMessageLoop+0x19 
0012fefc 7342a505 02e7efcc ffffffff 0000134c MSVBVM60!SCM::FPushMessageLoop+0xb9 
0012ff18 7342a4d0 02e78f88 02e7efcc ffffffff MSVBVM60!SCM_MsoCompMgr::FPushMessageLoop+0x2b 
0012ff3c 73423644 ffffffff 0183f558 0078c2bc MSVBVM60!CMsoComponent::PushMsgLoop+0x26 
0012ffb8 004013aa 00401ac4 7c817077 0183f558 MSVBVM60!ThunRTMain+0x9b 
0012fff0 00000000 004013a0 00000000 78746341 with_debug_info!__vbaS+0xa 

Vous étaient dans: MSVBVM60! HrMenuHandleMenuCommand + 0x3f

L'instruction qui a fialed: appuyez sur dword ptr + 0x147 (00000148) [eax] ds: 0023: 034b1004 = ???????? Eax est invalide, ainsi le derefernce a échoué.

Ma conjecture est que vous avez un gestionnaire de menu dans Ed20.dll que vous essayez d'exécuter, mais cette DLL a été déchargée (comme indiqué par le <Unloaded_Ed20.dll>). Vous devriez savoir pourquoi 1. la DLL a été déchargée ou 2. Pourquoi le gestionnaire est toujours enregistré après le déchargement.

+0

Yup. Ça sent comme un bug classique de comptage de référence. –