MCF DLL collision error ?????
Danny Lauwers -- dlauwers@innet.be
Monday, June 17, 1996
NT4b2/MFC4/VC++4.1
These are the errors I get When I use a the vsFlexArray OCX ?
I think I know what the LDR errors mean but the rest is like chinees to me ????
Does anybody has any clues !
The errors are copied from the debug window when I quit my application.
The Application seems to be running OK, but there is a big delay in loading
a file.
I have included WNASPI32 as a lib for doing some SCSI communication.
In my document there is a table (vsFlexArray OCX) and some other standard views.
When I leave out the table, then these errors are gone ?
Loaded symbols for 'N:\WINNT4\system32\MFC40D.DLL'
Loaded symbols for 'N:\WINNT4\system32\MSVCR40D.DLL'
Loaded symbols for 'N:\WINNT4\system32\MFCO40D.DLL'
** I opened a File
MRU: open file (1) 'G:\test.FF
LDR: WARNING ! MAJOR PERFORMANCE LOSS in myApp.exe
LDR: Dll VSFLEX32.OCX base 10000000 relocated due to collision with
N:\WINNT4\System32\WNASPI32.dll
LDR: WARNING ! MAJOR PERFORMANCE LOSS in myApp.exe
LDR: Dll MFC40.DLL base 5f800000 relocated due to collision with
N:\WINNT4\System32\MFC40D.DLL
First-chance exception in myApp.exe(MFC40.DLL): 0xE06D7363: Microsoft C++
Exception.
Warning: constructing COleException, scode = DISP_E_MEMBERNOTFOUND ($80020003).
First-chance exception in myApp.exe(MFCO40D.DLL): 0xE06D7363: Microsoft C++
Exception.
Warning: constructing COleException, scode = DISP_E_MEMBERNOTFOUND ($80020003).
First-chance exception in myApp.exe(MFCO40D.DLL): 0xE06D7363: Microsoft C++
Exception.
Thanks
Danny Lauwers
==========================================================
Ing. Danny Lauwers (dlauwers@innet.be)
Intersoft Electronics
Lammerdries 27
2250 Olen Belgium Europe
Tel: +32 14 231811
Fax: +32 14 231944
----------------------------------------------------------
Radar verification Hard- & software
Fotofinish and timing of sportevents
Footscan applications
and more ...
==========================================================
Mike Dickson -- mike@digimed.com
Tuesday, June 18, 1996
NT4b2/MFC4/VC4.1
I have been getting the same sort of error,
But my collision is with a different file.
Loaded symbols for 'C:\WINNT\system32\MFC40D.DLL'
Loaded symbols for 'C:\WINNT\system32\MSVCR40D.DLL'
Loaded symbols for 'C:\WINNT\system32\MFCO40D.DLL'
Loaded symbols for 'C:\WINNT\system32\MFCD40D.DLL'
Loaded symbols for 'D:\MSDEV\ObjGrid\lib\GX1140D.dll'
GX1140D.DLL Initializing!
LDR: WARNING ! MAJOR PERFORMANCE LOSS in MEDBUI~1.EXE
LDR: DLL dbnmpntw.DLL base 10000000 relocated due to collision with
d:\msdev\ObjGrid\Lib\GX1140D.dll
This DLL is from a third party. Now from what I understand the collision
means that there are similar
classes and/or calls in the DLL's but I'm not 100% sure.
I did try running this under NT3.51 and still got a collision but the error
read different.
Any ideas?
Michael Dickson
----------
From: Danny Lauwers[SMTP:dlauwers@innet.be]
Sent: Monday, June 17, 1996 1:50 PM
To: mfc-l@netcom.com
Subject: MCF DLL collision error ?????
NT4b2/MFC4/VC++4.1
These are the errors I get When I use a the vsFlexArray OCX ?
I think I know what the LDR errors mean but the rest is like chinees to me
????
Does anybody has any clues !
The errors are copied from the debug window when I quit my application.
The Application seems to be running OK, but there is a big delay in loading
a file.
I have included WNASPI32 as a lib for doing some SCSI communication.
In my document there is a table (vsFlexArray OCX) and some other standard
views.
When I leave out the table, then these errors are gone ?
Loaded symbols for 'N:\WINNT4\system32\MFC40D.DLL'
Loaded symbols for 'N:\WINNT4\system32\MSVCR40D.DLL'
Loaded symbols for 'N:\WINNT4\system32\MFCO40D.DLL'
** I opened a File
MRU: open file (1) 'G:\test.FF
LDR: WARNING ! MAJOR PERFORMANCE LOSS in myApp.exe
LDR: Dll VSFLEX32.OCX base 10000000 relocated due to collision with
N:\WINNT4\System32\WNASPI32.dll
LDR: WARNING ! MAJOR PERFORMANCE LOSS in myApp.exe
LDR: Dll MFC40.DLL base 5f800000 relocated due to collision with
N:\WINNT4\System32\MFC40D.DLL
First-chance exception in myApp.exe(MFC40.DLL): 0xE06D7363: Microsoft C++
Exception.
Warning: constructing COleException, scode = DISP_E_MEMBERNOTFOUND
($80020003).
First-chance exception in myApp.exe(MFCO40D.DLL): 0xE06D7363: Microsoft C++
Exception.
Warning: constructing COleException, scode = DISP_E_MEMBERNOTFOUND
($80020003).
First-chance exception in myApp.exe(MFCO40D.DLL): 0xE06D7363: Microsoft C++
Exception.
Thanks
Danny Lauwers
==========================================================
Ing. Danny Lauwers (dlauwers@innet.be)
Intersoft Electronics
Lammerdries 27
2250 Olen Belgium Europe
Tel: +32 14 231811
Fax: +32 14 231944
----------------------------------------------------------
Radar verification Hard- & software
Fotofinish and timing of sportevents
Footscan applications
and more ...
==========================================================
Mike Dickson -- mike@digimed.com
Tuesday, June 18, 1996
NT4b2/MFC4/VC4.1
I have been getting the same sort of error,
But my collision is with a different file.
Loaded symbols for 'C:\WINNT\system32\MFC40D.DLL'
Loaded symbols for 'C:\WINNT\system32\MSVCR40D.DLL'
Loaded symbols for 'C:\WINNT\system32\MFCO40D.DLL'
Loaded symbols for 'C:\WINNT\system32\MFCD40D.DLL'
Loaded symbols for 'D:\MSDEV\ObjGrid\lib\GX1140D.dll'
GX1140D.DLL Initializing!
LDR: WARNING ! MAJOR PERFORMANCE LOSS in MEDBUI~1.EXE
LDR: DLL dbnmpntw.DLL base 10000000 relocated due to collision with
d:\msdev\ObjGrid\Lib\GX1140D.dll
This DLL is from a third party. Now from what I understand the collision
means that there are similar
classes and/or calls in the DLL's but I'm not 100% sure.
I did try running this under NT3.51 and still got a collision but the error
read different.
Any ideas?
Michael Dickson
----------
From: Danny Lauwers[SMTP:dlauwers@innet.be]
Sent: Monday, June 17, 1996 1:50 PM
To: mfc-l@netcom.com
Subject: MCF DLL collision error ?????
NT4b2/MFC4/VC++4.1
These are the errors I get When I use a the vsFlexArray OCX ?
I think I know what the LDR errors mean but the rest is like chinees to me
????
Does anybody has any clues !
The errors are copied from the debug window when I quit my application.
The Application seems to be running OK, but there is a big delay in loading
a file.
I have included WNASPI32 as a lib for doing some SCSI communication.
In my document there is a table (vsFlexArray OCX) and some other standard
views.
When I leave out the table, then these errors are gone ?
Loaded symbols for 'N:\WINNT4\system32\MFC40D.DLL'
Loaded symbols for 'N:\WINNT4\system32\MSVCR40D.DLL'
Loaded symbols for 'N:\WINNT4\system32\MFCO40D.DLL'
** I opened a File
MRU: open file (1) 'G:\test.FF
LDR: WARNING ! MAJOR PERFORMANCE LOSS in myApp.exe
LDR: Dll VSFLEX32.OCX base 10000000 relocated due to collision with
N:\WINNT4\System32\WNASPI32.dll
LDR: WARNING ! MAJOR PERFORMANCE LOSS in myApp.exe
LDR: Dll MFC40.DLL base 5f800000 relocated due to collision with
N:\WINNT4\System32\MFC40D.DLL
First-chance exception in myApp.exe(MFC40.DLL): 0xE06D7363: Microsoft C++
Exception.
Warning: constructing COleException, scode = DISP_E_MEMBERNOTFOUND
($80020003).
First-chance exception in myApp.exe(MFCO40D.DLL): 0xE06D7363: Microsoft C++
Exception.
Warning: constructing COleException, scode = DISP_E_MEMBERNOTFOUND
($80020003).
First-chance exception in myApp.exe(MFCO40D.DLL): 0xE06D7363: Microsoft C++
Exception.
Thanks
Danny Lauwers
==========================================================
Ing. Danny Lauwers (dlauwers@innet.be)
Intersoft Electronics
Lammerdries 27
2250 Olen Belgium Europe
Tel: +32 14 231811
Fax: +32 14 231944
----------------------------------------------------------
Radar verification Hard- & software
Fotofinish and timing of sportevents
Footscan applications
and more ...
==========================================================
Niels Ull Jacobsen -- nuj@kruger.dk
Wednesday, June 19, 1996
[Mini-digest: 5 responses]
At 22:50 17-06-96 +0200, you wrote:
>NT4b2/MFC4/VC++4.1
>
>These are the errors I get When I use a the vsFlexArray OCX ?
>
>I think I know what the LDR errors mean but the rest is like chinees to =
me ????
>Does anybody has any clues !
>The errors are copied from the debug window when I quit my application.
>The Application seems to be running OK, but there is a big delay in load=
ing
>a file.
>I have included WNASPI32 as a lib for doing some SCSI communication.
I don't think this has anything to do with the problem. I could be wrong,
though.
>In my document there is a table (vsFlexArray OCX) and some other standar=
d
views.
>When I leave out the table, then these errors are gone ?
>
>Loaded symbols for 'N:\WINNT4\system32\MFC40D.DLL'
>Loaded symbols for 'N:\WINNT4\system32\MSVCR40D.DLL'
>Loaded symbols for 'N:\WINNT4\system32\MFCO40D.DLL'
>
>** I opened a File
>
>MRU: open file (1) 'G:\test.FF
>LDR: WARNING ! MAJOR PERFORMANCE LOSS in myApp.exe
>LDR: Dll VSFLEX32.OCX base 10000000 relocated due to collision with
>N:\WINNT4\System32\WNASPI32.dll
The OCX should be rebased. Read more about rebasing on MSDN.
As this involves changing the OCX, it may be a violation of=20
your redistribution licenses though...
>LDR: WARNING ! MAJOR PERFORMANCE LOSS in myApp.exe
>LDR: Dll MFC40.DLL base 5f800000 relocated due to collision with
>N:\WINNT4\System32\MFC40D.DLL
It seems that you are running with *two* versons of the MFC DLL
- the debug version MFC40D.DLL (used by your app) and the release version
MFC40.DLL
(probably loaded by the ocx). This is probably what is messing things up.
It will go away in your release version, but could probably cause problem=
s=20
while debugging?
>First-chance exception in myApp.exe(MFC40.DLL): 0xE06D7363: Microsoft C+=
+
>Exception.
>Warning: constructing COleException, scode =3D DISP_E_MEMBERNOTFOUND ($8=
0020003).
>First-chance exception in myApp.exe(MFCO40D.DLL): 0xE06D7363: Microsoft =
C++
>Exception.
>Warning: constructing COleException, scode =3D DISP_E_MEMBERNOTFOUND ($8=
0020003).
>First-chance exception in myApp.exe(MFCO40D.DLL): 0xE06D7363: Microsoft =
C++
>Exception.
Go into your debugger and turn on exception trapping (Debug, exceptions,
Stop always)
This should allow you to find out where they are thrown, why and whether =
you
should worry.
>
>Thanks
>Danny Lauwers
>
Niels Ull Jacobsen, Kr=FCger A/S (nuj@kruger.dk)
Everything stated herein is THE OFFICIAL POLICY of the entire Kruger=20
group and should be taken as legally binding in every respect.=20
Pigs will grow wings and fly.
-----From: Niels Ull Jacobsen
No. The problem is that two DLLs are based at the same address.=20
Every DLL has a "preferred load address" built into it at compile time.
If it can't be loaded at that address, it has to be "rebased", which=20
involves patching a lot of addresses. This is basically what the linker
does at compile time, but in this case it is done at runtime. This slows=20
down the loading of the DLL considerably. For details, see the MSDN artic=
les
"Rebasing Win32 DLLs: The Whole Story" and "High-Performance Tuning for W=
in32"
Niels Ull Jacobsen, Kr=FCger A/S (nuj@kruger.dk)
Everything stated herein is THE OFFICIAL POLICY of the entire Kruger=20
group and should be taken as legally binding in every respect.=20
Pigs will grow wings and fly.
-----From: Barry Tannenbaum
Actually, this is a collision when the DLL is loaded into memory. It has
nothing to do with the contents of the DLLs.
NT has the ability to specify where in memory a DLL is loaded. If that
memory range is available, the DLL is loaded into memory and the image
activator is done. If there's something already there, the image activator
has to relocate every jump and every reference within the DLL. Obviously
this is time consuming, so MSVC++ is warning you that you've got a major
startup time consumer.
- Barry
--------------------------------------------------------------------------------
3DV Technology, Inc Phone: (603) 595-2200 X228
410 Amherst St., Suite 150 Fax: (603) 595-2228
Nashua, NH 03063 Net: barry@dddv.com
-----From: "Jeff Lomax"
Doesn't this have to do with REBASE?
-----From: Dave Kolb
I used both the Stingray Objective Grid MFC class extension dll
(gx1140d.dll) and the VS FlexArray OCX. Both are nice though I finally
settled on the Stingray MFC code as it came with source code and was more
fully featured and was supported from VC++ whereas at the time the VS Flex
folks would support VB only (though it worked in VC++).
The loader errors are from default loader fixup addresses and not class or
EP conflicts. No big deal it just means you took a performance hit loading
the DLL as it had to be relocated into a different memory address than what
it was built at for default loading. Also some of the previous mentioned
errors were from mixing code that referenced debug and release versions of
the same dll that seemed to be at the same addresses and so conflicted. If
you are building the dll that conflicts then just move it's default loader
address.
I also noticed that VS FlexArray got DISP_E_MEMBERNOTFOUND calls on two
calls from the default CWnd support for OCX's when I used them and again no
big deal as they were optional properties (or were they methods - I forget)
that the CWnd code looked for but were not really needed. I think the OCX
could but did not need to support the two calls.
Dave Kolb
Dave Kolb Compuserve: 72410,407@compuserve.com
SAS Institute, Inc. EMAIL: sasdxk@unx.sas.com
SAS Campus Drive - R3282 Phone: (919) 677-8000 x6827
Cary, NC 27513-2414 USA FAX: (919) 677-8123
emiro@datmarkets.com.ar
Monday, June 24, 1996
------ =_NextPart_000_01BB6210.E641EEA0
Content-Type: text/plain; charset="iso-8859-1"
Mike Dickson -- mike@digimed.com
Tuesday, June 25, 1996
Yes, the problem is in the default load address assigned to the DLL's.
I have the code and make file for one of the DLL's in my project that was
causing the collision
and I changed the default load address and viola, no more collision.
This kind-a brings up a issue in my mind. It seems that there are DLL's
being produced and distributed that
don't get 'rebased' ( as mentioned below ), meaning that there are some
DLL's be distributed around
that just use the default load address. Otherwise we would not be on this
topic.(?)
In my case I have a third party DLL and a DLL from Microsoft that where both
using the default load address.
I was lucky that I have the code and make file from the third party so I
could change the load address.
But I could see that it might happen that one might not be so lucky, or what
if there are more than
two DLL's using the default load address?
I guess that I'm not offering a solution but just voicing a concern.
Michael Dickson
Fortune favors the brave.
--- Terence, 185-159 BC
----------
From: Eugenio A Miro[SMTP:emiro@datmarkets.com.ar]
Sent: Monday, June 24, 1996 12:27 PM
To: 'mfc-l@netcom.com'
Subject: RE: MCF DLL collision error ?????
I agree Barry Tannenbaum when he says that no matter the dll's contents. I
have the same warning but Im using a dll to use a database called uniVerse
and the messages are the same. Here is the message:
LDR: WARNING ! MAJOR PERFORMANCE LOSS in Manc040.exe
LDR: Dll UVCLNT32.dll base 10000000 relocated due to collision with
C:\WINNT40\System32\UVIC32.dll
Loaded symbols for 'C:\WINNT40\system32\MFC40D.DLL'
Loaded symbols for 'C:\WINNT40\system32\MSVCR40D.DLL'
Loaded symbols for 'C:\WINNT40\system32\MFCO40D.DLL'
The thread 0xC8 has exited with code 0 (0x0).
The program 'C:\MSDEV\Projects\Manc040\Debug\Manc040.exe' has exited with
code 0 (0x0).
----------
From: Niels Ull Jacobsen[SMTP:nuj@kruger.dk]
Sent: Wednesday, June 19, 1996 6:21 AM
To: mfc-l@netcom.com
Subject: Re: MCF DLL collision error ?????
[Mini-digest: 5 responses]
At 22:50 17-06-96 +0200, you wrote:
>NT4b2/MFC4/VC++4.1
>
>These are the errors I get When I use a the vsFlexArray OCX ?
>
>I think I know what the LDR errors mean but the rest is like chinees to me
????
>Does anybody has any clues !
>The errors are copied from the debug window when I quit my application.
>The Application seems to be running OK, but there is a big delay in loading
>a file.
>I have included WNASPI32 as a lib for doing some SCSI communication.
I don't think this has anything to do with the problem. I could be wrong,
though.
>In my document there is a table (vsFlexArray OCX) and some other standard
views.
>When I leave out the table, then these errors are gone ?
>
>Loaded symbols for 'N:\WINNT4\system32\MFC40D.DLL'
>Loaded symbols for 'N:\WINNT4\system32\MSVCR40D.DLL'
>Loaded symbols for 'N:\WINNT4\system32\MFCO40D.DLL'
>
>** I opened a File
>
>MRU: open file (1) 'G:\test.FF
>LDR: WARNING ! MAJOR PERFORMANCE LOSS in myApp.exe
>LDR: Dll VSFLEX32.OCX base 10000000 relocated due to collision with
>N:\WINNT4\System32\WNASPI32.dll
The OCX should be rebased. Read more about rebasing on MSDN.
As this involves changing the OCX, it may be a violation of
your redistribution licenses though...
>LDR: WARNING ! MAJOR PERFORMANCE LOSS in myApp.exe
>LDR: Dll MFC40.DLL base 5f800000 relocated due to collision with
>N:\WINNT4\System32\MFC40D.DLL
It seems that you are running with *two* versons of the MFC DLL
- the debug version MFC40D.DLL (used by your app) and the release version
MFC40.DLL
(probably loaded by the ocx). This is probably what is messing things up.
It will go away in your release version, but could probably cause problems
while debugging?
>First-chance exception in myApp.exe(MFC40.DLL): 0xE06D7363: Microsoft C++
>Exception.
>Warning: constructing COleException, scode = DISP_E_MEMBERNOTFOUND
($80020003).
>First-chance exception in myApp.exe(MFCO40D.DLL): 0xE06D7363: Microsoft C++
>Exception.
>Warning: constructing COleException, scode = DISP_E_MEMBERNOTFOUND
($80020003).
>First-chance exception in myApp.exe(MFCO40D.DLL): 0xE06D7363: Microsoft C++
>Exception.
Go into your debugger and turn on exception trapping (Debug, exceptions,
Stop always)
This should allow you to find out where they are thrown, why and whether you
should worry.
>
>Thanks
>Danny Lauwers
>
Niels Ull Jacobsen, Kruger A/S (nuj@kruger.dk)
Everything stated herein is THE OFFICIAL POLICY of the entire Kruger
group and should be taken as legally binding in every respect.
Pigs will grow wings and fly.
-----From: Niels Ull Jacobsen
No. The problem is that two DLLs are based at the same address.
Every DLL has a "preferred load address" built into it at compile time.
If it can't be loaded at that address, it has to be "rebased", which
involves patching a lot of addresses. This is basically what the linker
does at compile time, but in this case it is done at runtime. This slows
down the loading of the DLL considerably. For details, see the MSDN articles
"Rebasing Win32 DLLs: The Whole Story" and "High-Performance Tuning for
Win32"
Niels Ull Jacobsen, Kruger A/S (nuj@kruger.dk)
Everything stated herein is THE OFFICIAL POLICY of the entire Kruger
group and should be taken as legally binding in every respect.
Pigs will grow wings and fly.
-----From: Barry Tannenbaum
Actually, this is a collision when the DLL is loaded into memory. It has
nothing to do with the contents of the DLLs.
NT has the ability to specify where in memory a DLL is loaded. If that
memory range is available, the DLL is loaded into memory and the image
activator is done. If there's something already there, the image activator
has to relocate every jump and every reference within the DLL. Obviously
this is time consuming, so MSVC++ is warning you that you've got a major
startup time consumer.
- Barry
----------------------------------------------------------------------------
----
3DV Technology, Inc Phone: (603) 595-2200 X228
410 Amherst St., Suite 150 Fax: (603) 595-2228
Nashua, NH 03063 Net: barry@dddv.com
-----From: "Jeff Lomax"
Doesn't this have to do with REBASE?
-----From: Dave Kolb
I used both the Stingray Objective Grid MFC class extension dll
(gx1140d.dll) and the VS FlexArray OCX. Both are nice though I finally
settled on the Stingray MFC code as it came with source code and was more
fully featured and was supported from VC++ whereas at the time the VS Flex
folks would support VB only (though it worked in VC++).
The loader errors are from default loader fixup addresses and not class or
EP conflicts. No big deal it just means you took a performance hit loading
the DLL as it had to be relocated into a different memory address than what
it was built at for default loading. Also some of the previous mentioned
errors were from mixing code that referenced debug and release versions of
the same dll that seemed to be at the same addresses and so conflicted. If
you are building the dll that conflicts then just move it's default loader
address.
I also noticed that VS FlexArray got DISP_E_MEMBERNOTFOUND calls on two
calls from the default CWnd support for OCX's when I used them and again no
big deal as they were optional properties (or were they methods - I forget)
that the CWnd code looked for but were not really needed. I think the OCX
could but did not need to support the two calls.
Dave Kolb
Dave Kolb Compuserve: 72410,407@compuserve.com
SAS Institute, Inc. EMAIL: sasdxk@unx.sas.com
SAS Campus Drive - R3282 Phone: (919) 677-8000 x6827
Cary, NC 27513-2414 USA FAX: (919) 677-8123
Stew: Rob Stewart -- stew@msmail.datalytics.com
Friday, June 28, 1996
[Mini-digest: 2 responses]
> From: Michael Dickson
> To: stew; mfc-l@netcom.com
> Subject: RE: MCF DLL collision error ?????
> Date: Friday, June 28, 1996 6:24AM
>
> Yes, the problem is in the default load address assigned to the DLL's.
> I have the code and make file for one of the DLL's in my project that was
> causing the collision
> and I changed the default load address and viola, no more collision.
>
> This kind-a brings up a issue in my mind. It seems that there are DLL's
> being produced and distributed that
> don't get 'rebased' ( as mentioned below ), meaning that there are some
> DLL's be distributed around
> that just use the default load address. Otherwise we would not be on this
> topic.(?)
> In my case I have a third party DLL and a DLL from Microsoft that where
both
> using the default load address.
> I was lucky that I have the code and make file from the third party so I
> could change the load address.
> But I could see that it might happen that one might not be so lucky, or
what
> if there are more than
> two DLL's using the default load address?
The loader patches them one at a time to a non-colliding address. This is,
of course, slower than not having to do it. The problem is, you can tune
your DLLs, and select 3rd party DLLs (for which you have the source), so the
load addresses don't overlap. However, if just one of your DLLs grows
(including an upgrade from a 3rd party), it could bump the next one in the
load sequence which could bump the next one, etc.
There is no way to predetermine good load addresses other than to hand tune
the load addresses with each release. Even then, you'll have DLLs over which
you have no control, which complicates matters. There is no good solution to
this short of the loader rewriting the binary after some number of loads so
it can get a good idea of a less conflicting address. I don't think I'd like
Windows rewriting my DLLs though.
-----From: Steve Lunsford
There is a Rebase utility that comes with Win32 SDK that can be run on any DLL. Using
this tool you are not required to have the source code to "rebase" a DLL.
Steve Lunsford
| Вернуться в корень Архива
|