2

I'm working with native CLR hosting for some weeks now. In the beginning it worked pretty well. But later on I've noticed that something in my application causes heap corruption. I've figured out that this is caused by the CLR startup. (See following short version of the code.)

#pragma comment(lib, "mscoree.lib")
#include <mscoree.h>
#include <metahost.h>
#include <comdef.h>
#import "mscorlib.tlb" raw_interfaces_only          \
    high_property_prefixes("_get","_put","_putref")     \
    rename("ReportEvent", "InteropServices_ReportEvent")

using namespace mscorlib;

int _tmain(int argc, _TCHAR* argv[])
{
    HRESULT hr; // In fullversion used for error detection - but here unused.
    PCWSTR pszVersion = L"v4.0.30319";
    ICLRMetaHost* lpMetaHost = NULL;
    ICLRRuntimeInfo* lpRuntimeInfo = NULL;
    ICorRuntimeHost* lpRuntimeHost = NULL;
    _AppDomainPtr spAppDomain = NULL;
    BOOL bLoadable = false;
    IUnknownPtr spAppDomainThunk = NULL;

    CLRCreateInstance(CLSID_CLRMetaHost, IID_ICLRMetaHost, (LPVOID *)&lpMetaHost);
    // After this line i can "late detect" 6 array bound heap corruptions in process memory.

    lpMetaHost->GetRuntime(pszVersion, IID_ICLRRuntimeInfo, (LPVOID *)&lpRuntimeInfo);    
    lpRuntimeInfo->IsLoadable(&bLoadable);
    lpRuntimeInfo->GetInterface(CLSID_CorRuntimeHost, IID_PPV_ARGS(&lpRuntimeHost));
    lpRuntimeHost->Start();
    lpRuntimeHost->GetDefaultDomain(&spAppDomainThunk);
    spAppDomainThunk->QueryInterface(IID_PPV_ARGS(&spAppDomain));
    spAppDomainThunk->Release();
    // Now I can "late detect" up to 9 array bound heap corruptions in process memory.

    return 0;
}

Rational Purify Exception

Any ideas on how to avoid this? Currently in some cases it still works, but as my applications gets bigger the chance for an error increases exponentially.

Chris Smith
  • 18,244
  • 13
  • 59
  • 81
Christoph Meißner
  • 1,511
  • 2
  • 21
  • 40
  • You aren't checking for failures and you don't initialise your pointers to NULL - I take it that the full version of the code does check for errors? – Justin Aug 16 '11 at 08:40
  • yes therefore i use HRESULT which is defined but unused in my excerpt. There are no errors I just want to keep my question as short as possible. I will note that in my question thx. – Christoph Meißner Aug 16 '11 at 08:47
  • Seems there is nothing wrong in code here. Do you receive purify error if you return immediately after spAppDomainThunk->Release()? – elevener Aug 16 '11 at 10:38
  • As noted in code i already get !6! purify errors after the line: CLRCreateInstance .... And later by running the application i notice that due heap corruption exceptions. – Christoph Meißner Aug 16 '11 at 11:38
  • You haven't answered the question. ABWL is "late array bounds write". That means that Purify detects the error later, when the object is freed or when a leak scan is initiated. So if you have problems in your code that follows, especially in managed part - you have a very good chances to get ABWL in unrelated place. Make a project that only creates managed heap and quits and see if you see whose errors. – elevener Aug 16 '11 at 11:50
  • I've added the return to the end of the code of my question. If I compile this and test it I already get that errors. And I'm sure that by adding some nonsense memory filling code after that code I would get an application crash. – Christoph Meißner Aug 16 '11 at 12:06
  • At the moment I am asking myself: Could this be influenced by any compiler option? – Christoph Meißner Aug 16 '11 at 12:24
  • I've fixed the later occuring errors in application due reinstalling visual studio. At least my application seems to be stable now. But the purify errors still remain. And I've got no idea why they are there. – Christoph Meißner Aug 17 '11 at 17:00

1 Answers1

0

Although visually inspecting the code above does not reveal what might be causing heap corruption, try AppVerifier + Windbg to detect it. Here is some info on how to do it http://blogs.msdn.com/b/lagdas/archive/2008/06/24/debugging-heap-corruption-with-application-verifier-and-debugdiag.aspx. AppVerifier actually pinpoints where on the stack (frame, call) corrupts the heap.

user1234883
  • 1,675
  • 10
  • 18
  • What AppVerifier and windbg does is exactly the same as rational puritfy does, which shows me the error above. The conclusions of my research towards that is, that these errors seem to be hardcoded inside the CLR, and are may used to detect system specific variables or such things. In other words it seems as if microsoft did a little hack to solve a problem, that shows up in these 9 errors. BTW. the CLR Host works fine regardless these errors. – Christoph Meißner Feb 29 '12 at 10:08