Delphi 2009 causing shell32.dll errors?

0
votes

I have a user that started experiencing access violations related to his shell32.dll file when using my software. This started to occur after upgrading to the latest version of our software, which is the first version we released that had been compiled in D2009.

No one else is reporting these AV problems, and I have been unable to replicate them myself. So it seems that it has something to do with his particular installation of Windows. I use EurekaLog, so I can tell that some of these AVs have to do with the creation or display of various forms in the application. Often, the following reference is given as the last thing the call stack:

shell32.dll > ILIsEqual

Does anyone have any ideas on how I can get this user going again? Or how I can get more clues as to what's actually the problem? In the past, I've found these errors that only occur on one user's machine to be very difficult to track down....

1
delphidelphi-2009
The last thing on the call stack is probably not so important as the last thing from your code on the call stack. What is your code doing, and what function is it calling that eventually calls into shell32? – David
Client's using XP Pro SP3. The problem is that the last thing from my code is not always the same. And the error doesn't come from any repeatable action (like clicking a button, etc). Plus, it's always from simple things like displaying a form. I'm starting to think there's something messed up with his OS install maybe? – croceldon
I don't think the OS install is messed up. The ILIsEqual could stand for ImageListIsEqual, and in that case there may well be problems with the combination of graphics card, graphics card driver, installed shell extensions and the format of image lists in your program. Try removing the artwork from your app, or replacing it by b/w or 16 colour versions, or get the customer to try different screen resolutions, colour depths or a newer card driver version. – mghie
Question should also be tagged "shell" – BennyBechDk

1 Answers

1
votes

I agree, it is hard to replicate such errors. This is why quality logging is so important. I would use a following approach with such a problem.

  1. Use a good logging method (you have that already)
  2. When the error happens have the user send you the report (you already have the report)
  3. Check the report for as much user computer settings, as possible
  4. Check the stack trace and look where in your code the error happened, or which is the last call your code made.
  5. If you still cannot find or replicate the error, make a new branch of you app in your versioning system. In that branch increase the logging around the spot that you identified in the stack trace. Log as much as possible. Send the user this version.
  6. Wait for the next user report.
  7. Repeat the procedure and try to log even more and maybe broden the heavy log radius if necessary.

If you have time you can also talk with the user. This way sometimes they tell you important new info that can help you.

I had two nasty bugs to find in the last week or so. I just started to methodically move towards the goal. And when I picked up the scent of the error it was just a matter of time finding it. I found out that if you are methodical, sooner or later you will find the cause.