Heap corruption with DCOM? 
Author Message
 Heap corruption with DCOM?

I'm encountering an apparent problem with DCOM, and while I've observed this
with a variety of configurations, I'll just describe just one here.  I have
a local DCOM server exposing an uncontroversial object (type). My client
loads a conventional DLL to access the remote service (the client
subsequently exhibits ling-term stability problems) and calls the DLL to
spawn a new thread, initialize COM, Create an object, make (one or more)
method calls, release the object, CoUninitialize() COM and exist the thread.
The platform for this example is XP pro, compiled with VC7 with all
 "updates" applied, and using the November 2001 platform SDK (in case that

I've tried compiling with _MCBS and _UNICODE, to no avail.  I've noticed
that the behaviour changes if I call CoSetProxyBlanket() immediately after
creating the object.  Without explicitly setting the proxy blanket, the
following error is detected (by Rational purify) for the (first) method call
on the out-of-process object - whereas, with the proxy blanket set
explicitly, I get a similar error reported by purify when CoUninitialise()
is called (or conversely when the thread exists if the CoUninitialise() call
is omitted.

Purify report:


[E] ABW: Array bounds write in LookupAccountNameW {1 occurrence}
        Writing 1024 bytes to 0x000ecca0 (512 bytes at 0x000ecea0 illegal)
        Address 0x000ecca0 is argument #5 of LookupAccountNameW
        Address 0x000ecca0 is at the beginning of a 512 byte block
        Address 0x000ecca0 points to a HeapAlloc'd block in the default heap
        Thread ID: 0xff0
        Error location
            LookupAccountNameW [ADVAPI32.dll]
            ThreadFn(void *) [threadmgr.cpp:90]
        Allocation location
            HeapAlloc      [KERNEL32.dll]
            ThreadFn(void *) [threadmgr.cpp:90]


** threadmgr.cpp:90 represents the first DCOM method call on the created

ADVAPI32.dll reports

file version : 5.1.2600.1106 (xpsp1.020828-1920)

product version : 5.1.2600.1106

I am inclined to believe that this is a real problem (as opposed to a
phantom purify warning) as I am experiencing long-term client process
instability when these calls are made.  Is this a known problem with the
DCOM runtime (I can't find any references to this in the MSDN)?  Does anyone
know of a patch or workaround? Am I the only one who has this problem?

Sat, 16 Apr 2005 21:12:22 GMT  
 [ 1 post ] 

 Relevant Pages 

1. Memory heap corruption after free()

2. Heap Corruption

3. Heap Corruption

4. CException-derived class causes heap corruption

5. heap corruption issues with VC++.NET and STL

6. STL string heap corruption bug

7. CE Emulator Heap Corruption

8. HEAP[dllhost.exe]: HEAP: Free Heap block 1e32c28 modified at 1e32dc4 after it was freed

9. Binomial heaps / Fibonacci heaps

10. (ATL) COM dll heap vs CRT heap

11. HEAP error: Free heap block xxx mdofied at xxx

12. Invalid heap signature for heap


Powered by phpBB® Forum Software