none
.Net CLR crashes on Windows 7 RRS feed

  • Question

  • Hello,

    I have a new computer 64bit computer running windows 7.

    All programs I can find that require .NET 3.5 will immediately hang . They just sit there after creating a window and after five seconds, the (Not Responding) message appears.

    If I start a new WPF application in Visual Studio 2008, it hangs Visual Studio. The XAML loads, but the designer doesn't. If I create a WPF application without XAML, then only the application hangs, but not visual studio.

    Aaron Stebner's Framework Verifier(http://blogs.msdn.com/astebner/pages/8999004.aspx ) returns no problems.

    .NET is turned on in the "Turn Windows features on or off" menu. The version is 3.5.1.

    I do not see any obvious errors in the Event Viewer.

    Any help or ideas are apreciated.

    • Edited by Andres0 Saturday, March 27, 2010 8:15 PM
    Saturday, March 27, 2010 12:55 AM

Answers

  • The callstack you have posted is unmanaged. You should probably get managed callstack.

    load the dump within windbg,

    issue the following commands

    • .loadby sos mscorwks
    • .symfix - .load symbols from MS
    • "~*e !clrstack - To get managed callstack from all the threads
    • !syncblk - this is to check if it is waiting on a lock

    Post this output , it might indicate the cause.

    And here is a simple demo and walk though of how to diagnose hang within windbg from Tess

     

     

     


    Thanks Naveen http://naveensrinivasan.com
    • Marked as answer by Figo Fei Thursday, April 1, 2010 3:04 AM
    Saturday, March 27, 2010 11:05 PM

All replies

  • One suggestion would be is to get a memory like using procdump

    Then can debug the dump using windbg.From there we can probably look at the manged call stack  and the native call stack.

    And you if you are not familiar with Windbg you can download this tool DebugDiag   , this will do most of the job of dumping the memory and running scripts which will help you figure out the cause for most of the issues.

    If you need any more help, please respond.

     

     

     


    Thanks Naveen http://naveensrinivasan.com
    Saturday, March 27, 2010 1:56 AM
  • FYI I forgot mention debug diag is available for 32bit as well as 64bit.
    "NaveenS" wrote in message news:9571b24b-3d1d-425c-a5c3-7294f2ebdf92...

    One suggestion would be is to get a memory like using procdump

    Then can debug the dump using windbg.From there we can probably look at the manged call stack  and the native call stack.

    And you if you are not familiar with Windbg you can download this tool DebugDiag   , this will do most of the job of dumping the memory and running scripts which will help you figure out the cause for most of the issues.

    If you need any more help, please respond.

     

     

     


    Thanks Naveen http://naveensrinivasan.com

    Thanks Naveen http://naveensrinivasan.com
    Saturday, March 27, 2010 2:24 AM
  • Ok, I ran DebugDiag on a handful of programs and I saw a recurring theme. Most threads were blocked waiting for something else, except a rendering thread that had a stacktrace that was always similar to this:

    PresentationCore_ni!`string' <PERF> (PresentationCore_ni+0x1bf387)   
    PresentationCore_ni!`string' <PERF> (PresentationCore_ni+0x1bf695)   
    PresentationCore_ni!`string' <PERF> (PresentationCore_ni+0x1bf4ca)   
    PresentationCore_ni!`string' <PERF> (PresentationCore_ni+0x1c7857)   
    PresentationCore_ni!`string' <PERF> (PresentationCore_ni+0x1c74d7)   
    PresentationCore_ni!`string' <PERF> (PresentationCore_ni+0x1c73b2)   
    PresentationCore_ni!`string' <PERF> (PresentationCore_ni+0x1c72b0)   
    PresentationCore_ni!`string' <PERF> (PresentationCore_ni+0x1c71b2)   
    mscorwks!CallDescrWorker+33   
    mscorwks!CallDescrWorkerWithHandler+a3   
    mscorwks!ForwardCallToManagedMethod+55   
    mscorwks!DoUMThunkCallWorker+1de   
    mscorwks!DoUMThunkCall+3c8   
    0x001e0ab5   
    wpfgfx_v0300!CMilSlaveGlyphCache::EnsureGlyphBitmapsArePresent+5d   
    wpfgfx_v0300!CGlyphRunResource::CreateRealization+1c9   
    wpfgfx_v0300!CGlyphRunResource::GetAvailableScale+1a4   
    wpfgfx_v0300!CBaseGlyphRunPainter::Init+1ad   
    wpfgfx_v0300!CSWGlyphRunPainter::Init+3e   
    wpfgfx_v0300!CSoftwareRasterizer::DrawGlyphRun+d3   
    wpfgfx_v0300!CSwRenderTargetSurface::DrawGlyphs+114   
    wpfgfx_v0300!CMetaRenderTarget::DrawGlyphs+b6   
    wpfgfx_v0300!CDrawingContext::DrawGlyphRun+1de   
    wpfgfx_v0300!CMilSlaveRenderData::Draw+4a4   
    wpfgfx_v0300!CMilVisual::RenderContent+2a   
    wpfgfx_v0300!CDrawingContext::PreSubgraph+485   
    wpfgfx_v0300!CGraphIterator::Walk+32   
    wpfgfx_v0300!CDrawingContext::DrawVisualTree+324   
    wpfgfx_v0300!CDrawingContext::Render+324   
    wpfgfx_v0300!CSlaveHWndRenderTarget::Render+209   
    wpfgfx_v0300!CRenderTargetManager::Render+2e   
    wpfgfx_v0300!CComposition::Render+21   
    wpfgfx_v0300!CComposition::ProcessComposition+f3   
    wpfgfx_v0300!CComposition::Compose+3e   
    wpfgfx_v0300!CPartitionThread::RenderPartition+1c   
    wpfgfx_v0300!CPartitionThread::Run+48   
    wpfgfx_v0300!CPartitionThread::ThreadMain+1e   
    kernel32!BaseThreadInitThunk+e   
    ntdll!__RtlUserThreadStart+70   
    ntdll!_RtlUserThreadStart+1b  

    I am still stumped on how to make any use of this information however.

    Maybe someone else can chime in.

    Saturday, March 27, 2010 7:39 PM
  • How did you use the DebugDiag? It has to be set on crash rule? Then load the dump within debugdiag and it is most likely to give you the reason for crash.
     
     

    Thanks Naveen http://naveensrinivasan.com
    Saturday, March 27, 2010 7:44 PM
  • I should have been more clear. The programs are hanging and not crashing. There is no dialog that reports an error, and no exception is ever thrown. I have to attach to the process to get any sort of stack trace.

    Sorry for the confusion. I have edited to original post with a few details.

    Saturday, March 27, 2010 8:12 PM
  • The callstack you have posted is unmanaged. You should probably get managed callstack.

    load the dump within windbg,

    issue the following commands

    • .loadby sos mscorwks
    • .symfix - .load symbols from MS
    • "~*e !clrstack - To get managed callstack from all the threads
    • !syncblk - this is to check if it is waiting on a lock

    Post this output , it might indicate the cause.

    And here is a simple demo and walk though of how to diagnose hang within windbg from Tess

     

     

     


    Thanks Naveen http://naveensrinivasan.com
    • Marked as answer by Figo Fei Thursday, April 1, 2010 3:04 AM
    Saturday, March 27, 2010 11:05 PM