Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Access Violation calling funcs in VC6 DLL from VC7 binary!?!?

1 view
Skip to first unread message

Marc Elliott

unread,
Jun 18, 2003, 9:19:16 AM6/18/03
to
Hi, I am dealing with a puzzling (and frustrating) problem. I have a
release-build DLL built in VC6 that I am trying to use from a project
I am building in VC7. Everything appears normal at build time, but
when I run the program (a trivial test program) I get a read or write
access violation when calling DLL functions. This occurs even when I
call a func that takes void and returns void, so it is not the usual
"cannot pass STL types across DLL boundaries" problem or anything
related to passing types back and forth.

Since I cannot get a debug version of the DLL (it is proprietary code
that I am writing an engine for), I asked for the usual conflicting
project settings and changed mine accordingly:

RTTI enabled/disabled (disabled)
Runtime library (MT DLL)
Struct mem alignment (default - 8 bytes)
no _DEBUG flag enabled

...It doesn't matter whether I build in Debug or Release, I still get
the same problem. Stepping through the disassembly in the DLL doesn't
tell me much; the code is trying to copy a register value to a bad
address (like "59") or vice versa.

The ONLY other thing I can think of is getting the same version of
MSVCP60.DLL and MSVCRT.DLL sent to me that is used by the DLL builders
and placing it in my runtime path so it is picked up instead of the
one in my WINNT/System32. Depends.exe doesn't show any other
dependencies except for NTDLL.DLL, which I cannot imagine I need. I've
only experienced needing to ship MSVCP60.DLL with a program to avoid
problems such as this.

Does this sound like it could be the cause of the problem? I've been
struggling with this for days now and am running out of ideas, not to
mention I've lost a bit of time chasing this. I've been unable to find
any information speaking of this particular problem.

Many thanks,
Marc

Ivan Brugiolo [MSFT]

unread,
Jun 18, 2003, 11:34:26 AM6/18/03
to
Despite your attempts to isolate the dependencies between
your project and the VC6 binary, still the first suspicion is heap
contamination.

Could you please enable full page-heap on your project,
to see if it breaks on the spot ?

to enable full pageheap:

HKLM\Software\microsoft\windows NT\currentversion\Image file execution
options\YourApp.exe
GlobalFalg = REG_DWORD 0x2000000
PageHeapFlags = REG_DWORD 0x3

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Marc Elliott" <marc...@hotmail.com> wrote in message
news:f867e9d7.0306...@posting.google.com...

Marc Elliott

unread,
Jun 18, 2003, 11:46:16 PM6/18/03
to
Hi Ivan,

I tried this, but it didn't give me any further information. The
message I get is still:

Unhandled exception at 0x10003c3a in AnalyzerTestSimple.exe:
0xC0000005: Access violation reading location 0x00000048.

...and the break point is still in the DLL, presumably as it is
returning from the call.

I should probably provide some more info here:

1) This is the only call which takes void and returns void. It appears
to perform OK, but crashes on it's way out of the method. There is a
call which returns a double, which (I presume) does OK (the void/void
method dumps to screen which is why I know it works) but also crashes
on its way out of the method.

2) The other calls pass and return STL strings as arguments. I am
aware of the binary incompatibility between VC6 and VC7 STL types, and
am waiting on a new version of the DLL that uses char* instead, but I
assume that these methods, if uncalled, will have no effect on others
such as the void/void??

Please let me know if I am missing anything. (and thanks for the rapid
response)

Marc


"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<OdpHa8aN...@TK2MSFTNGP12.phx.gbl>...

Ivan Brugiolo [MSFT]

unread,
Jun 19, 2003, 3:13:25 AM6/19/03
to
Could you post the output of the 'r;kb' command
issued in one of the system debuggers installable from here

http://www.microsoft.com/whdc/ddk/debugging/default.mspx

with good symbols as instructed here
http://www.microsoft.com/whdc/ddk/debugging/symbols.mspx ?

that line is pretty meaningless without some more information.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Marc Elliott" <marc...@hotmail.com> wrote in message

news:f867e9d7.03061...@posting.google.com...

Marc Elliott

unread,
Jun 19, 2003, 11:22:16 PM6/19/03
to
Ivan,

Here is the output you requested. Thanks for looking.

M

--------------------------------------------------------------

C:\Program Files\Debugging Tools for Windows>cdb -g -G
AnalyzerTestSimple.exe

Microsoft (R) Windows Debugger Version 6.1.0017.2
Copyright (c) Microsoft Corporation. All rights reserved.

CommandLine: AnalyzerTestSimple.exe
Symbol search path is: *** Invalid *** : Verify _NT_SYMBOL_PATH
setting
Executable search path is:
ModLoad: 00400000 00419000 AnalyzerTestSimple.exe
ModLoad: 77f80000 77ffa000 ntdll.dll
ModLoad: 10000000 1008f000 C:\blahblah\bin\exchdll.dll
ModLoad: 780c0000 78121000 C:\WINNT\System32\MSVCP60.dll
ModLoad: 78000000 78046000 C:\WINNT\system32\MSVCRT.dll
ModLoad: 77e80000 77f31000 C:\WINNT\system32\KERNEL32.dll
ModLoad: 10480000 10535000 C:\WINNT\System32\MSVCP70D.dll
ModLoad: 10200000 10285000 C:\WINNT\System32\MSVCR70D.dll
ModLoad: 7c000000 7c054000 C:\WINNT\System32\MSVCR70.dll
analyzer test
invoking method
__________________________________________________________

Finished Processing
(4a4.6cc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0012fca4 ebx=7ffdf000 ecx=00000038 edx=0012fca4 esi=00000038
edi=00000000
eip=10003c3a esp=0012fc8c ebp=0012fde4 iopl=0 nv up ei pl nz
na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00010202
*** WARNING: Unable to verify checksum for C:\blahblah\bin\exchdll.dll
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for C:\blahblah\bin\exchdll.dll -
exchdll!SolonNm::Analyzer::operator=+f6a:
10003c3a 8b4610 mov eax,[esi+0x10]
ds:0023:00000048=????????
0:000> .sympath SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Symbol search path is:
SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
0:000> .reload /f
Reloading current modules
.*** WARNING: Unable to verify checksum for AnalyzerTestSimple.exe
.*** WARNING: Unable to verify checksum for
C:\blahblah\bin\exchdll.dll
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for C:\blahblah\bin\exchdll.dll -
.......
0:000> r
eax=0012fca4 ebx=7ffdf000 ecx=00000038 edx=0012fca4 esi=00000038
edi=00000000
eip=10003c3a esp=0012fc8c ebp=0012fde4 iopl=0 nv up ei pl nz
na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000
efl=00010202
exchdll!SolonNm::Analyzer::operator=+f6a:
10003c3a 8b4610 mov eax,[esi+0x10]
ds:0023:00000048=????????
0:000> kb
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may
be wrong.
0012fde4 0041141b 00000000 77f83100 7ffdf000
exchdll!SolonNm::Analyzer::operator=+0xf6a
0012ff60 00411963 00000001 006a0fe0 0065ef80
AnalyzerTestSimple!main+0x14b
0012ffc0 77ea847c 77fb64f4 77f83100 7ffdf000
AnalyzerTestSimple!mainCRTStartup+0x143
0012fff0 00000000 004110e6 00000000 eeeeeeee
KERNEL32!BaseProcessStart+0x3d
0:000>


"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<uVP0HJjN...@TK2MSFTNGP12.phx.gbl>...

Ivan Brugiolo [MSFT]

unread,
Jun 20, 2003, 12:05:38 AM6/20/03
to
This looks like a NULL parameter passed to the += operator,
or, if this is optimized code, it can be that the stack storage has been
reused for a temporary.
it's fishy also that ESI si such a low number as well.
Normally ESI holds a "copy" of the 'this' pointer.

if you set '.sympath' to the path of the DLL you've built,
and you do a '.lines' the dubugger should tell you where exactly you
crashed.

0:000> r
eax=0012fca4 ebx=7ffdf000 ecx=00000038 edx=0012fca4 esi=00000038
edi=00000000
eip=10003c3a esp=0012fc8c ebp=0012fde4 iopl=0 nv up ei pl nz na pe
nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010202
exchdll!SolonNm::Analyzer::operator=+f6a:
10003c3a 8b4610 mov eax,[esi+0x10]
ds:0023:00000048=????????
0:000> kb
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may
be wrong.
0012fde4 0041141b 00000000 77f83100 7ffdf000
exchdll!SolonNm::Analyzer::operator=+0xf6a

^^^^^^^^------------------------------------------------- NULL


0012ff60 00411963 00000001 006a0fe0 0065ef80 AnalyzerTestSimple!main+0x14b
0012ffc0 77ea847c 77fb64f4 77f83100 7ffdf000
AnalyzerTestSimple!mainCRTStartup+0x143
0012fff0 00000000 004110e6 00000000 eeeeeeee
KERNEL32!BaseProcessStart+0x3d
0:000>

--

0 new messages