none
CLR Crashes with exception code Exception code: 0xc0000409 while performing DoStackSnapshot RRS feed

  • Question

  • We develop a .NET application profiling tool and use the Profiling API heavily.

    We perform stackwalks using DoStackSnapshot API as described in https://msdn.microsoft.com/en-us/library/bb264782.aspx

    We have a 2 separate crash dump instances which show that the CLR crashes while executing the DoStackSnapshot() API.

    The crash dump shows the following frames.
     clr.dll!__report_gsfailure() Unknown
      clr.dll!CrawlFrame::CheckGSCookies(void) Unknown
      clr.dll!StackFrameIterator::PreProcessingForManagedFrames() Unknown
      clr.dll!StackFrameIterator::NextRaw(void) Unknown
      clr.dll!Thread::StackWalkFramesEx() Unknown
      clr.dll!Thread::StackWalkFrames() Unknown
      clr.dll!ProfToEEInterfaceImpl::DoStackSnapshotHelper(class Thread *,struct _PROFILER_STACK_WALK_DATA *,unsigned int,struct _CONTEXT *) Unknown
      clr.dll!ProfToEEInterfaceImpl::DoStackSnapshot(unsigned __int64,long (*)(unsigned __int64,unsigned __int64,unsigned __int64,unsigned int,unsigned char * const,void *),unsigned int,void *,unsigned char *,unsigned int) Unknown
      HP.Profiler.dll!0000000180034f33() Unknown
      HP.Profiler.dll!000000018003446b() Unknown
      HP.Profiler.dll!000000018000d3a4() Unknown
      HP.Profiler.dll!000000018000a8f8() Unknown
      kernel32.dll!BaseThreadInitThunk() Unknown
      ntdll.dll!RtlUserThreadStart() Unknown

    Brief snippet of the code

    CONTEXT context;
    memset(&context, 0, sizeof(context));
    context.ContextFlags = CONTEXT_FULL;
    
    if(GetThreadContext(threadHandle, &context))
    {
    
    swClientDataStruct clientData;
    hr = pProfilerInfo->DoStackSnapshot(tId, StackWalkCallback, COR_PRF_SNAPSHOT_REGISTER_CONTEXT, (void *)&clientData, (BYTE*)&context, sizeof(context));
    }
    This code path is used in many other scenarios and works just fine. We just have some instances where we see this problem.

    Can anybody from the Microsoft CLR profiler API team help in trying to explain the cause of the crash and how this can be avoided ?

    From my research on the web(http://dotnetbeyond.blogspot.com/2010_02_01_archive.html), it seems to indicate that the GSCookie gets corrupted when the called native code may overrun the buffer. Why does this get evaluated during a stackwalk ? Does it mean this thread would have crashed as it unwound the stack on execution ?

    Regards and thanks for any responses

    Sanjay


    Sanjay Mehta

    Thursday, June 18, 2015 10:33 PM

All replies

  • I see this comment in the source code posted on GitHub. I am not sure I fully understand it without additional context but sounds like it may be relevant.

    Any insight may be helpful.

    //******************************************************************************

    // For asynchronous stackwalks, the thread being walked may not be suspended.

    // It could cause a buffer-overrun while the stack-walk is in progress.

    // To detect this, we can only use data that is guarded by a GSCookie

    // that has been recently checked.

    // This function should be called after doing any time-consuming activity

    // during stack-walking to reduce the window in which a buffer-overrun

    // could cause an problems.

    //

    // To keep things simple, we do this checking even for synchronous stack-walks.

    void CrawlFrame::CheckGSCookies()


    Sanjay Mehta

    Thursday, June 18, 2015 11:53 PM
  • Hello Sanjay,

    For this issue, I am trying to invoke someone experienced help look into it, it may take some time and as soon as we get any result, we would post it to the forum.

    Thanks for your understanding and support.

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Friday, June 19, 2015 5:22 AM
    Moderator