2009-11-12 10 views
0

J'ai un utilisateur qui a commencé à rencontrer des violations d'accès liées à son fichier shell32.dll lors de l'utilisation de mon logiciel. Cela a commencé à se produire après la mise à niveau vers la dernière version de notre logiciel, qui est la première version que nous avons publiée et qui a été compilée dans D2009. Personne d'autre ne signale ces problèmes AV, et j'ai été incapable de les répliquer moi-même. Il semble donc que cela a quelque chose à voir avec son installation particulière de Windows. J'utilise EurekaLog, donc je peux dire que certains de ces AV ont à voir avec la création ou l'affichage de diverses formes dans l'application. Souvent, la référence suivante est donnée comme la dernière chose que la pile d'appel:Delphi 2009 provoquant des erreurs shell32.dll?

shell32.dll > ILIsEqual 

Est-ce que quelqu'un a des idées sur la façon dont je peux obtenir cet utilisateur va à nouveau? Ou comment je peux obtenir plus d'indices quant à ce qui est réellement le problème? Dans le passé, j'ai trouvé ces erreurs qui se produisent uniquement sur la machine d'un utilisateur à être très difficile à traquer ....

+0

Quel système d'exploitation le client utilise-t-il? –

+0

La dernière chose sur la pile d'appels n'est probablement pas si importante que la dernière chose _de votre code_ sur la pile d'appels. Que fait votre code, et quelle fonction appelle-t-il qui finit par appeler shell32? –

+0

Le client utilise XP Pro SP3. Le problème est que la dernière chose de mon code n'est pas toujours la même. Et l'erreur ne vient pas d'une action reproductible (comme cliquer sur un bouton, etc.). De plus, c'est toujours à partir de choses simples comme l'affichage d'un formulaire. Je commence à penser qu'il y a quelque chose de foiré avec son système d'exploitation peut-être? – croceldon

Répondre

1

Je suis d'accord, il est difficile de reproduire de telles erreurs. C'est pourquoi l'enregistrement de qualité est si important. J'utiliserais une approche suivante avec un tel problème.

  1. Utilisez une bonne méthode d'enregistrement (vous avez déjà)
  2. Lorsque l'erreur se produit que l'utilisateur vous envoyer le rapport (vous avez déjà le rapport)
  3. Vérifiez le rapport pour les paramètres de l'ordinateur de l'utilisateur autant , autant que possible
  4. Vérifiez la trace de la pile et regardez où se trouve l'erreur dans votre code, ou quel est le dernier appel effectué par votre code.
  5. Si vous ne parvenez toujours pas à trouver ou répliquer l'erreur, créez une nouvelle branche de votre application dans votre système de gestion des versions. Dans cette branche, augmentez la journalisation autour de l'endroit que vous avez identifié dans la trace de la pile. Connectez-vous autant que possible. Envoyer l'utilisateur cette version.
  6. Attendez le prochain rapport d'utilisateur.
  7. Répétez la procédure et essayez de vous connecter encore plus et peut-être broder le rayon de bûche lourd si nécessaire.

Si vous avez le temps, vous pouvez aussi parler avec l'utilisateur. De cette façon, parfois, ils vous disent de nouvelles informations importantes qui peuvent vous aider. J'ai eu deux bogues désagréables à trouver dans la dernière semaine ou deux. Je viens juste de commencer méthodiquement vers l'objectif. Et quand j'ai senti l'odeur de l'erreur, c'était juste une question de temps pour la trouver. J'ai découvert que si vous êtes méthodique, tôt ou tard, vous trouverez la cause.