CFusionArray(SxS)中的堆损坏 [英] Heap corruption in CFusionArray (SxS)

问题描述

您好，
我遇到了一个问题，即无规COM用法，其中我们有一个COM对象Object A，它是CoCreateInstance的对象B.对象B是一个托管类，用GuidAttribute装饰-guid在A进行的CoCreateInstance调用中提供.
在正常执行中，没有发现任何问题.但是，当使用App Verifier打开完整的页面堆验证时，AV会检测到堆损坏.堆栈跟踪似乎指向CFusionArray，这似乎是发生缓冲区溢出的地方.

请注意，这是一个NDP 3.5应用程序.我在装有3.5 SP1的计算机上运行它.

以下是发生这种情况时在WinDbg中看到的内容:

========== =============================
验证器停止00000008:pid 0x1948:损坏的堆块.

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:调用中使用的堆句柄.
38226E30:操作中涉及的堆块.
000001CC:堆块的大小.
> 00000000 :保留

 00161000 : Heap handle used in the call.
 38226E30 : Heap block involved in the operation.
 000001CC : Size of the heap block.
 00000000 : Reserved

=====================================
该验证程序停止无法持续.
当您使用"go"调试器命令时，进程将终止.

=======================================
This verifier stop is not continuable. Process will be terminated
when you use the `go' debugger command.

=====================================

=======================================

(1948.1fcc):中断指令异常-代码80000003(第一次机会)
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:

然后，我在WinDbg中运行以下命令以获取堆栈:

0:000> dt _DPH_BLOCK_INFORMATION 38226E30-0x20
vfbasics！_DPH_BLOCK_INFORMATION
                 + 0x000 StartStamp      :0xabcdbbbb
  + 0x004堆           :0x00161000
  + 0x008 RequestedSize :0x1cc
  + 0x00c ActualSize      :0x1000
  + 0x010 DelayQueueEntry  :_DPH_DELAY_FREE_QUEUE_ENTRY
  + 0x010 BusyListEntry   :_LIST_ENTRY [0xe297-0x0]
+ 0x010阻止: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！运算符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(
  结构_AVRF_LAYER_DESCRIPTOR * LayerDescriptor = 0x1000c540，nb&n ;; 8，
无符号长Param1 = 0x161000，
无符号长Param2 = 0x38226e30，
无符号长Param3 = 0x1cc，
无符号长Param4 = 0，
_AVRF_STOP_EXTRA * StopExtra = 0x00000000)+ 0x4d1 [d:\ avrf \ source \ base \ avrf \ avrf30 \ vrfcore \ sdk.cpp @ 551]
0012c40c 7c96b376 vrfcore！VfCoreRedirectedStopMessage(
         char *消息= 0x7c96b61c损坏的后缀模式"，
，无符号长Param1 = 0x161000，
，  char * Description1 = 0x7c96b610堆句柄"，
 无符号长Param2 = 0x38226e30，
   char * Description2 = 0x7c96b604堆块"，
无符号长Param3 = 0x1cc，
  char * Description3 = 0x7c96b5f8块大小"，
  无符号长参数4 = 0，
   char *说明4 = 0x7c96b5f7")+ 0x81 [d:\ avrf \ source \ base \ avrf \ avrf30 \ vrfcore \ stopredirect.cpp @ 103]
0012c488 7c96c6a0 ntdll！RtlpDphReportCorruptedBlock + 0x17c
0012c4dc 7c96f6f3 ntdll！RtlpDebugPageHeapFree + 0xc7
0012c550 7c94bc4cHeapdll
xx0xx0lyx3x3x0xx0lyx0lyx3x3x0x3x0x3ly0x3x0x3ly0x3x0x3x0x3x0x3x0x3x0x3x0x3x03x0x3x0x3x0x3x03x3e00c0c3aps3&dll <0>
0012c708 0038fe9c ntdll！RtlFreeHeap + 0xf9
0012c750 7e728993 vfbasics！AVrfpRtlFreeHeap(<* * HeapHandle = 0x00160000，
= 0，
   void * BaseAddress = 0x000001cc)+ 0xf8 [d:\ avrf \ source \ base \ avrf \ vrfcommon \ heap.c @ 385]
0012c764 7e79d674 sxs！operator删除+ 0x1c
0012c770 7e768fc1 sxs！FusionFreeArray< CFusionFil ePathAndSize *> + 0x13
0012c780 7e76a129 sxs！CFusionArray< unsigned char，unsigned char，0,0,1> ::〜CFusionArray< unsigned char，unsigned char，0,0,1> + 0x10
0012c7d0 79f0ce6b sxs！ mscorwks！EEDllGetClassObject + 0x2ef
0012cc4c 79f27dc3 mscorwks！InternalDllGetClassObject + 0xc6
0012cc88 79016f69 mscorwks！DllGetClassObjectInternal + 0x5c
0012ccd0 775022e2 mscoree！ :: DllGetClassObject + 0x2d
0012cd04 775116ba ole32！CClassCache :: CDllFnPtrMoniker :: BindToObjectNoSwitch + 0x1f
0012cd30 7751120f ole32！CClassCache :: GetClassObject + 0x38
0012cdac 775110b3 olex！
0012cdec 77511302 ole32！ActivationPropertiesIn :: DelegateCreateInstance + 0xf7 0012ce40 77511279 ole32！CApartmentActivator :: CreateInstance + 0x110
0012ce60 775120c8 ole32！CProcessActivator :: CCICallback + 0x6d
0012ce80 7751207f ole32！CProcessActivator :: AttemptActivation + 0x2c
0012ceb8ator 77363 :: ActivateByContext + 0x42
0012cee0 775110b3 ole32！CProcessActivator :: CreateInstance + 0x49
0012cf20 7751104e ole32！ActivationPropertiesIn :: DelegateCreateInstance + 0xf7
0012d170 775110b3 ole32！CClientContextActivx8 <创建实例> 0012d1b0 77510ef8 ole32！ActivationPropertiesIn :: DelegateCreateInstance + 0xf7
0012d960 77500575 ole32！ICoCreateInstanceEx + 0x3c9
0012d988 77500544 ole32！CComActivator :: DoCreateInstance + 0x28
0012d9ac 775b > 0012d9dc 3809e4e7 ole32！CoCreateInstance + 0x37
0012da90 38091e28 MyCode！CMyCode :: CMycode(void)+ 0x187 [c:\ ... \ mycode.cpp @ 123]

搜索网络，我只看到对此问题的一种参考:
http://www.eggheadcafe.com/software/aspnet/30413116/heap-corruption-issue-usi.aspx

它具有几乎相同的堆栈跟踪，但这是从2007年开始的.

这是常见问题还是已知问题?是否有修补程序或至少一种解决方法.即使此问题不会导致任何问题并且继续执行，我们也会间歇地注意到，某些访问冲突会由于堆损坏而崩溃.因此，我不确定CFusionArray似乎引入的堆损坏是否可能在以后访问堆上的该位置时引起AV....

任何帮助将不胜感激.

(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.

推荐答案

有机会破坏内存吗? (例如您的本机代码或您正在使用的本机库)
是否可以通过简单的复制方式重现此代码，而在sxs.dll中出现此PageHeap问题之前，没有本机代码运行? (如果是，那么这是sxs.dll或CLR中的错误)

-Karel

Is there any chance that something else is corrupting memory? (e.g. your native code, or native library you are using)
Can you reproduce this with a simple repro where no native code runs before this PageHeap issue in sxs.dll? (If yes, then it is a bug in sxs.dll or in CLR)

-Karel

这篇关于CFusionArray(SxS)中的堆损坏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！