DLL Hell

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

bikerider7 - 23 Jul 2004 19:45 GMT

Hello,
I have a .DLL compiled on VC++ 6.0 and is being linked into an
application built using 7.0. For reasons that are too stupid to go
into, migrating the .dll to 7.0 isn't possible for the time being.

On my development PC (Windows XP), the application runs fine; i.e.
the DLL calls work great. But when we copy the application over to
any other PC (also running Windows XP), it crashes whenever a DLL call
is made. It seems like calls to DLL library routines are going to a bad
address.

I've made sure that the .dll and .exe are in the same
directory, and we've run the app with the current directory set
to the app directory. I also went through to see if there were
any missing system DLL's on the other PC's but no such luck.
Is there something that I'm missing?

Reply to this Message

Ronald Laeremans [MSFT] - 23 Jul 2004 23:24 GMT

Only if you are extremely careful will you be able to make an application
consisting of objects built against different versions of the same C++
library work. For C libraries it is somewhat more possible, but you still
need to be very careful. E.g. in the case of multiple versions of the C
runtime library, you need to be aware that you now have different memory
allocators so you can't pass something allocated in the dll and free it in
its client, nor can you pass any global handles (like for I/O) across the
boundary and expect it to work.

As to why it works on one machine and not on another is somewhat hard to
guess at. Seeing whether all the dependencies are exactly the same versions
could be a start, but unless the code obeys the rules above (and another
whole set of related ones) it probably is more an academic exercise than
something that will ever work reliably.

Ronald Laeremans
Visual C++ team

> Hello,
> I have a .DLL compiled on VC++ 6.0 and is being linked into an
[quoted text clipped - 12 lines]
> any missing system DLL's on the other PC's but no such luck.
> Is there something that I'm missing?

Reply to this Message

bikerider7 - 24 Jul 2004 23:51 GMT

> Only if you are extremely careful will you be able to make an application
> consisting of objects built against different versions of the same C++
[quoted text clipped - 4 lines]
> its client, nor can you pass any global handles (like for I/O) across the
> boundary and expect it to work.

Yes, I'm aware of the restrictions on microsoft shared libraries.
However, the DLL in question did not rely on standard C memory allocators,
etc. so this was not an issue.

And in any case, we just spent 2 days porting most of the DLL to 7.0 and
are still seeing the same problem. So the problem is not due to
mismatching compilers. Indeed, as a test I had the App call
this very simple DLL routine immediately in main:

BOOL DllLib::Test() { return TRUE; }

and it crashes (except on my PC which still runs fine). As long
as we don't make calls to the DLL, everything runs fine, but
that is obviously not an option....

Reply to this Message

Ronald Laeremans [MSFT] - 27 Jul 2004 08:59 GMT

Using a debugger to try and step through the call looks like the sanest bet
to me. That is after verifying that you are loading the same version of
everything with a tool like depends.

Ronald

>> Only if you are extremely careful will you be able to make an application
>> consisting of objects built against different versions of the same C++
[quoted text clipped - 20 lines]
> as we don't make calls to the DLL, everything runs fine, but
> that is obviously not an option....

Reply to this Message

Sebastian Dau - 26 Jul 2004 20:54 GMT

Have you tried to catch the exeption
and trace to it's origin / source?

Reply to this Message

DLL Hell

Free Magazines