Delphi Image Bases for Multiple DLL's

Is setting the bases completely necessary? I would recommend letting windows set the bases unless there are other circumstances you aren't saying.

We have been getting random Access Violations when we call a function from one of the Dll's and then a different function from the other Dll. The bug reports always start with the AV being in ntdll.dll

All three dll's use some of the same forms / functions.

Previous versions did not have an issue using all three with the same image base.

It does not happen on all users PC's.

Hope this helps giving us a better insight

So if I understand correctly (I just woke up), changing image bases has caused nothing but trouble. Why do you need to change them?

Sorry I may have explained myself properly.

Up to the last version of our system we did not get any (as far as we know) Access Violation issues with ntdll.dll.

In this version all three dll's had the default Delphi image base of $00400000.

With the latest version (all using $00400000) we started getting the odd one or two customer's with the same AV issue all refering to ntdll.dll, but this is out of 500+ users.

We found that (using the latest released versions code)  by changing the image bases to the three different values the issue (seems so far) to have been resolved.

Does this make sense

Thanks.

We are integrating a lot more issue logging into the system for the next release so hopefully we can then get to the bottom if it.

Have any of the DLL versions changed (between when it originally worked and now)?  You may need to double check that the interface to the functions in each DLL are still the same.  I would also look for a pattern of systems, OS's, etc where the errors occur.  ThievingSix recommended MadExcept, I like EurekaLog.  I cannot speak for MadExcept, but I have compiled a program with EurekaLog and had it set up to email me whenever an unhandled exception occurs.  With the email I gat a screen shot and a full call stack.  As long as you can build the same version the user is using you can get Delphi to show you all of the steps that led to the exception.

developmentguru:

Thanks we are using EurekaLog which I agree is very good but all it tells us is that the AV is in the CreateForm when we get the Parent Window handle from the calling program.

This code has not changed in the last five years so it is puzzling.

The user who gets the issue has three / four machines and only one gives the error.

Eureka log is not giving you the full call stack?  Do you have debug information turned on?

I also noticed that you did not address any of the questions I asked.  Are all of the DLL versions the same?  This can be checked with process explorer.
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Is there a pattern in the OS versions where the error occurs?

Is there a pattern in which other software is installed where the error occurs?

The good news is that today the customer came back and said that after updating all their ntdll.dll to the same version as their other (working) PC's the porblem PC no longer gives the AV.

It would appear to have been a damaged ntdll.dll

I notice that you said it was updated to the same version.  I would make a note of the version for future reference.  If it is a different version then the file was probably not damaged at all, just an incompatible version.