Hi,
I have been using Reg-Free COM to load a .NET assembly using a CPP client
using manifest files. Recently I deployed my .NET assembly, and the loading
of my .NET assembly was leading to heap corruption and eventually the
crashing my application. I was able to develop a sample project that modeled
my deployed client and .NET assembly. The problem happens with my sample
project also.

I developed a sample client called cppclient.exe. Using the gflags.exe
window debugging utility, I enabled the page heap for my cppclient. I ran my
client in Debug mode in Visual Studio, and at the line where the client
loads my .NET assembly using COM, the program crashes. The stack trace
indicates that the call was made from sxs.dll. The stack trace is below:

ntdll.dll!_RtlpDphReportCorruptedBlock@16() + 0x186
ntdll.dll!_RtlpDphNormalHeapFree@12() + 0x2e
ntdll.dll!_RtlpDebugPageHeapFree@12() + 0x79
ntdll.dll!_RtlDebugFreeHeap@12() + 0x2c
ntdll.dll!_RtlFreeHeapSlowly@12() + 0x23d19
ntdll.dll!_RtlFreeHeap@12() + 0x16470
sxs.dll!operator delete() + 0x1c
sxs.dll!FusionFreeArray<CFusionFilePathAndSize *>() + 0x13
sxs.dll!CFusionArray<CFusionFilePathAndSize *,CFusionFilePathAndSize
*,0,0,1>::~CFusionArray<CFusionFilePathAndSize *,CFusionFilePathAndSize
*,0,0,1>() + 0x10
sxs.dll!SxsLookupClrGuid() + 0x3a4
mscorwks.dll!79f86e9d()

This is exactly the problem with my deployed .NET assembly.

My question is - Is this a known problem with manifest files and Reg-Free
COM? Is there a patch for it or something I can set so that this Heap
corruption does not happen.
If I can't find a solution I will have scrap my deployment with Reg-Free COM
and go back to registering my .NET assembly, which is not preferable.

Any inputs for this issue will be greatly appreciated.

Regards,
Suds

Hi Suds,

By searching in the internal database, I find one reported known issue by
fusion team. This is confirmed as a bug of Sxs.dll and the heap corruption
is caused by a buffer overrun in SxsFindClrClassInformation.

The fusion team has filed this issue and made a proposed fix for it.

Based on the bug description, if type="win32" is not present in the
component manifest, there is no heap corruption. You may give it a try and
tell me whether this will workaround this issue.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Jeff,
Thanks for you email and suggestion.

1) I tried you suggested work around. I had the same exception again. So I
did not work in my case.
2) The fix you said they were trying make, is that released / will be
released as a part of patch or service pack. Is this available for .NET
users. Please let me know if is a fix available.
3) If it is of any use I can attach below, the a zipped my of the project
that I created

Thanks
Suds


""Jeffrey Tan[MSFT]"" <jetan (AT) online (DOT) microsoft.com> wrote

Hi Suds,

Thank you for confirming the status.

It is strange that the workaround does not work. Based on the information
in the record(given by Sxs developer Jun Feng Zhang), it will resolve the
problem.

Giving a second search for this issue, I found more records for reg-free
COM interop with the same stack traces. However, they are closed as won't
fix for some reason, while the first record I found was closed as fixed.
Actually, I am also a bit confused about if this issue is fixed in lastest
Windows update SP or not.

Anyway, I have found one CSS support engineer has opened a hotfix request
to the fusion team for this issue recently(7/30/2007). This hotfix request
is still not closed yet. Since based on the newsgroup support policy, we
can not request hotfix from product team directly. I would recommend you to
contact the Microsoft Customer Support Service for the further support. The
CSS engineer can help you to request a hotfix from the product team. Note:
once this problem is confirmed as a known issue by the CSS engineer, the
support case will be free.

You can contact Microsoft Customer Support at 1-(800)936-5800 or by
choosing one of the options listed at
http://www.microsoft.com/services/mi...v_support.mspx.

Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.