Hi,
I am running into an issue where a reg-free COM usage where we have a COM object A that is CoCreateInstance'ing object B. Object B is a managed class that is decorated with the GuidAttribute -- that guid is supplied in the CoCreateInstance call that A makes.
In normal execution, there are no issues noticed. However, when using App Verifier to turn on full pageheap verification, AV detects heap corruption. The stack trace seems to point to CFusionArray as the place where a buffer overrun seems to be taking place.
Note that this is an NDP 3.5 app. I ran it on a machine with 3.5 SP1 installed.
The following is what I see in WinDbg when this happens:
=======================================
VERIFIER STOP 00000008: pid 0x1948: Corrupted heap block.
00161000 : Heap handle used in the call.
38226E30 : Heap block involved in the operation.
000001CC : Size of the heap block.
00000000 : Reserved
=======================================
This verifier stop is not continuable. Process will be terminated
when you use the `go' debugger command.
=======================================
(1948.1fcc): Break instruction exception - code 80000003 (first chance)
eax=1000e848 ebx=1000cd44 ecx=00000001 edx=0012c151 esi=00000000 edi=1000e848
eip=7c90120e esp=0012c1e4 ebp=0012c3e8 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
Then, I run the following commands in WinDbg to get the stack:
0:000> dt _DPH_BLOCK_INFORMATION 38226E30-0x20
vfbasics!_DPH_BLOCK_INFORMATION
+0x000 StartStamp : 0xabcdbbbb
+0x004 Heap : 0x00161000
+0x008 RequestedSize : 0x1cc
+0x00c ActualSize : 0x1000
+0x010 DelayQueueEntry : _DPH_DELAY_FREE_QUEUE_ENTRY
+0x010 BusyListEntry : _LIST_ENTRY [ 0xe297 - 0x0 ]
+0x010 Block : 0x0000e297 _DPH_HEAP_BLOCK
+0x018 StackTrace : 0x3808604c
+0x01c EndStamp : 0xdcbabbbb
0:000> dds 0x3808604c
3808604c abcdaaaa
38086050 00000001 <Unloaded_Ed20.dll>
38086054 00000010 <Unloaded_Ed20.dll>+0xf
38086058 00000000
3808605c 00000000
38086060 00000000
38086064 2da5ef10 <Unloaded_Ed20.dll>+0x2da5ef0f
38086068 3808606c <Unloaded_Ed20.dll>+0x3808606b
3808606c 7c94b394 ntdll!RtlAllocateHeapSlowly+0x44
38086070 7c918f21 ntdll!RtlAllocateHeap+0xe64
38086074 0038fd2c vfbasics!AVrfpRtlAllocateHeap+0xb1 [d:\avrf\source\base\avrf\vrfcommon\heap.c @ 234]
38086078 7e721f7a sxs!operator new+0x16
3808607c 7e768bb8 sxs!FusionWin32AllocateArray<unsigned char>+0x46
38086080 7e768e74 sxs!FusionWin32ResizeArray<unsigned char>+0x83
38086084 7e769028 sxs!CFusionArray<unsigned char,unsigned char,0,0,1>::Win32SetSize+0x55
38086088 7e76a018 sxs!SxsLookupClrGuid+0x293
3808608c 79f0ce6b mscorwks!FindShimInfoFromWin32+0x10f
38086090 79f0d330 mscorwks!AppDomain::LoadCOMClass+0xaa
38086094 79f0d45c mscorwks!GetTypeForCLSID+0x35
38086098 7a009449 mscorwks!EEDllGetClassObject+0x2ef
3808609c 7a001882 mscorwks!InternalDllGetClassObject+0xc6
380860a0 79f27dc3 mscorwks!DllGetClassObjectInternal+0x5c
380860a4 79016f69 mscoree!DllGetClassObject+0x12c
380860a8 775022e2 ole32!CClassCache::CDllPathEntry::DllGetClassObject+0x2d
380860ac abcdaaaa
380860b0 00000001 <Unloaded_Ed20.dll>
380860b4 00000010 <Unloaded_Ed20.dll>+0xf
380860b8 00000000
380860bc 00000000
380860c0 00161000 <Unloaded_Ed20.dll>+0x160fff
380860c4 37f7fbb4 <Unloaded_Ed20.dll>+0x37f7fbb3
380860c8 380860cc <Unloaded_Ed20.dll>+0x380860cb
0:000> kP 200
ChildEBP RetAddr
0012c1e0 10003b68 ntdll!DbgBreakPoint
0012c3e8 100078c9 vrfcore!VerifierStopMessageEx(
struct _AVRF_LAYER_DESCRIPTOR * LayerDescriptor = 0x1000c540,
unsigned long StopCode = 8,
unsigned long Param1 = 0x161000,
unsigned long Param2 = 0x38226e30,
unsigned long Param3 = 0x1cc,
unsigned long Param4 = 0,
struct _AVRF_STOP_EXTRA * StopExtra = 0x00000000)+0x4d1 [d:\avrf\source\base\avrf\avrf30\vrfcore\sdk.cpp @ 551]
0012c40c 7c96b376 vrfcore!VfCoreRedirectedStopMessage(
unsigned long Code = 8,
char * Message = 0x7c96b61c "corrupted suffix pattern",
unsigned long Param1 = 0x161000,
char * Description1 = 0x7c96b610 "Heap handle",
unsigned long Param2 = 0x38226e30,
char * Description2 = 0x7c96b604 "Heap block",
unsigned long Param3 = 0x1cc,
char * Description3 = 0x7c96b5f8 "Block size",
unsigned long Param4 = 0,
char * Description4 = 0x7c96b5f7 "")+0x81 [d:\avrf\source\base\avrf\avrf30\vrfcore\stopredirect.cpp @ 103]
0012c488 7c96c6a0 ntdll!RtlpDphReportCorruptedBlock+0x17c
0012c4dc 7c96f6f3 ntdll!RtlpDebugPageHeapFree+0xc7
0012c550 7c94bc4c ntdll!RtlDebugFreeHeap+0x2c
0012c638 7c927573 ntdll!RtlFreeHeapSlowly+0x37
0012c708 0038fe9c ntdll!RtlFreeHeap+0xf9
0012c750 7e728993 vfbasics!AVrfpRtlFreeHeap(
void * HeapHandle = 0x00160000,
unsigned long Flags = 0,
void * BaseAddress = 0x000001cc)+0xf8 [d:\avrf\source\base\avrf\vrfcommon\heap.c @ 385]
0012c764 7e79d674 sxs!operator delete+0x1c
0012c770 7e768fc1 sxs!FusionFreeArray<CFusionFilePathAndSize *>+0x13
0012c780 7e76a129 sxs!CFusionArray<unsigned char,unsigned char,0,0,1>::~CFusionArray<unsigned char,unsigned char,0,0,1>+0x10
0012c7d0 79f0ce6b sxs!SxsLookupClrGuid+0x3a4
0012ca44 79f0d330 mscorwks!FindShimInfoFromWin32+0x10f
0012cb3c 79f0d45c mscorwks!AppDomain::LoadCOMClass+0xaa
0012cb68 7a009449 mscorwks!GetTypeForCLSID+0x35
0012cc10 7a001882 mscorwks!EEDllGetClassObject+0x2ef
0012cc4c 79f27dc3 mscorwks!InternalDllGetClassObject+0xc6
0012cc88 79016f69 mscorwks!DllGetClassObjectInternal+0x5c
0012ccd0 775022e2 mscoree!DllGetClassObject+0x12c
0012ccec 775119a0 ole32!CClassCache::CDllPathEntry::DllGetClassObject+0x2d
0012cd04 775116ba ole32!CClassCache::CDllFnPtrMoniker::BindToObjectNoSwitch+0x1f
0012cd30 7751120f ole32!CClassCache::GetClassObject+0x38
0012cdac 775110b3 ole32!CServerContextActivator::CreateInstance+0x106
0012cdec 77511302 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
0012ce40 77511279 ole32!CApartmentActivator::CreateInstance+0x110
0012ce60 775120c8 ole32!CProcessActivator::CCICallback+0x6d
0012ce80 7751207f ole32!CProcessActivator::AttemptActivation+0x2c
0012ceb8 77511363 ole32!CProcessActivator::ActivateByContext+0x42
0012cee0 775110b3 ole32!CProcessActivator::CreateInstance+0x49
0012cf20 7751104e ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
0012d170 775110b3 ole32!CClientContextActivator::CreateInstance+0x8f
0012d1b0 77510ef8 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
0012d960 77500575 ole32!ICoCreateInstanceEx+0x3c9
0012d988 77500544 ole32!CComActivator::DoCreateInstance+0x28
0012d9ac 775005b2 ole32!CoCreateInstanceEx+0x1e
0012d9dc 3809e4e7 ole32!CoCreateInstance+0x37
0012da90 38091e28 MyCode!CMyCode::CMycode(void)+0x187 [c:\...\mycode.cpp @ 123]
Searching the web, I have only seen one reference to this issue:
http://www.eggheadcafe.com/software/aspnet/30413116/heap-corruption-issue-usi.aspx
It had an almost identical stack trace, but that was from 2007.
Is this a common or a known issue? Is there a hotfix or at least a workaround. Even though this issue does not cause any problems and execution continues on, we do notice, intermittently, some access violation crashes with heap corruption. So, I am not sure whether the heap corruption that the CFusionArray seems to introduce might be inducing the AVs later on when that location on the heap is being accessed...
Any help will be really appreciated.
[Edit: FWIW, this is happening on an XP SP3 machine with 3 GB RAM]