That does seem like the bug fixed quite a while ago in WiX v3.6. On Thu, Jun 28, 2012 at 9:16 AM, Darwin Baines <da...@microsoft.com> wrote:
> I am having a problem with an uninstall that rolls back and crashes on 64 > bit Wix 3.5 setups. > > We get the following error message in the Event logs: > > 00 ntdll!RtlReportCriticalFailure(long StatusCode = 0n2, void * > FailureInfo = 0x000007fe`00000023)+0x62 > [d:\win7sp1_gdr\minkernel\ntos\rtl\rtlutil.c @ 178] > 01 ntdll!RtlpReportHeapFailure(long ErrorLevel = 0n0)+0x26 > [d:\win7sp1_gdr\minkernel\ntos\rtl\heaplog.c @ 159] > 02 ntdll!RtlpHeapHandleError(long ErrorLevel = 0n2883584)+0x12 > [d:\win7sp1_gdr\minkernel\ntos\rtl\heaplog.c @ 381] > 03 ntdll!RtlpLogHeapFailure(_HEAP_FAILURE_TYPE FailureType = 0n3441876 (No > matching enumerant), void * HeapAddress = 0x00000000`002c0000, void * > Address = 0x00000000`003484d4, void * Param1 = 0x00000000`00000000, void * > Param2 = 0x00000000`00000000, void * Param3 = 0x00000000`00000000)+0xa4 > [d:\win7sp1_gdr\minkernel\ntos\rtl\heaplog.c @ 679] > 04 ntdll!RtlFreeHeap+0x1aab7 > 05 KERNELBASE!LocalFree(void * hMem = 0x00000000`003484d4)+0x2e > [d:\win7sp1_gdr\minkernel\kernelbase\lmem.c @ 439] > 06 MSIF262!ExecSecureObjectsRollback(unsigned long hInstall = 0xcf)+0x31c > [c:\delivery\dev\wix35\src\ca\wixca\dll\secureobj.cpp @ 913] > 07 msi!CallCustomDllEntrypoint(<function> * pfEntry = 0x00000000`00000000, > bool fDebugBreak = true, unsigned long hInstall = 0, wchar_t * szAction = > 0x00000000`00000000 "")+0x26 [d:\w7rtm\admin\darwin\src\engine\action.cpp @ > 5293] > 08 msi!CMsiCustomAction::CustomActionThread(class CustomActionData * pData > = 0x00000000`00000000)+0x2cf [d:\w7rtm\admin\darwin\src\engine\icust.cpp @ > 894] > 09 kernel32!BaseThreadInitThunk(unsigned long RunProcessInit = 0, > <function> * StartAddress = 0x00000000`00000000, void * Argument = > 0x00000000`00000000)+0xd [d:\win7sp1_gdr\base\win32\client\thread.c @ 65] > 0a ntdll!RtlUserThreadStart(<function> * StartAddress = > 0x00000000`00000000, void * Argument = 0x00000000`00000000)+0x1d > [d:\win7sp1_gdr\minkernel\ntos\rtl\rtlexec.c @ 3185] > > So it looks like ExecSecureObjectsRollback is the culprit and we are > guessing that it is trying to free memory that is already free. We do have > one entry in the SecureObject Table that is created by adding a > util:PermissionEx element. > > I do see that this bug may have been addressed in 3.6 > > > http://wix.codeplex.com/SourceControl/network/forks/tedshroyer/tedwix/changeset/changes/839be4dc5f1e > > CAraman: Fix heap corruption in ExecSecureObjectsRollback. > > Is there a work around in 3.5 that would prevent this heap corruption? Did > this Changeset make it into the 3.6 trunk? > > Any insight would be appreciated. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
