2010-05-28 8 views
0

Je sais que je cherche des pailles ici, mais celui-ci est un mystère ... tous les pointeurs ou l'aide seraient les bienvenus, donc je fais appel à ceux plus intelligents que moi:Le blocage lié au timing lors du déchargement d'une DLL?

Nous avons un accident exposé dans nos versions binaires seulement. Le crash se produit lorsque le binaire s'abaisse et termine les sous-bibliothèques dont il dépend. Sa capacité à être reproduite dépend de la machine - certains sont fiables à 100% pour reproduire l'accident, d'autres ne présentent aucun problème et d'autres se situent entre les deux. Le crash est profond dans l'une des sous-bibliothèques, et il y a de bonnes chances que la pile soit corrompue au moment où les décombres peuvent être amenés dans un débogueur (MSVC 2008 SP1) pour être examinés. L'exécution du binaire sous le débogueur empêche le bug de se produire, tout comme le débogage à distance, tout comme (de toutes choses) la connexion à la machine via VNC. Nous avons essayé d'installer le Kit de développement de pilotes Microsoft, ce qui a également réduit le bug.

Quel serait le prochain meilleur endroit pour regarder? Quels outils seraient les meilleurs dans cette circonstance? Cela ressemble-t-il à une condition de course, ou à autre chose?

+0

Cela ressemble beaucoup à un bug de threading quelconque. Y a-t-il un modèle pour les machines qui fonctionnent vs ne fonctionnent pas? Par exemple. Le VNC est un mystère - y a-t-il du travail graphique effectué pendant l'arrêt? – mdma

+0

Votre application (ou ses bibliothèques) utilise-t-elle des fenêtres? Si c'est le cas, vous devrez peut-être décharger une DLL pour traiter les messages (par exemple, dll contient le fichier wndproc mais la DLL est déchargée avant que la fenêtre ne soit détruite). – jdigital

+0

@mdma: Aucun modèle que nous avons pu détecter jusqu'à présent. – fbrereto

Répondre

0

Le problème était un paramètre conflictuel de l'indicateur pernicieux _SECURE_SCL sous Visual Studio, provoquant des incompatibilités ABI silencieuses entre la DLL et l'une de ses dépendances.

1

Avez-vous essayé Rational Purify? J'ai utilisé ceci (il y a 4-5 ans). Ensuite, il a été utile pour repérer les bugs dans la mémoire, la corruption de la pile, les poignées invalides etc.

1

Essayez ensemble AppVerifier et GFlags pour trouver la page corruption Heap.

Vous aurez probablement besoin de WinDbg comme débogueur au lieu de Visual Studio pour déboguer.

Je recommande également this book sur le débogage avancé de Windows pour repérer les plantages tels que celui que vous rencontrez.

1

Utilisez-vous le pool de threads par hasard et n'annulez pas ou n'attendez pas la fin des objets de travail en attente?

Questions connexes