title: Fast capture stack trace on windows / 64-bit / mixed mode
body: <p>Like most of you probably know there exists plenty of different mechanisms to walk stack traces, starting from windows api, and continuing further into depth of magical assembly world - let me list here some of links I've already studied.</p>
  
  <p>For of all let me mention that I want to have mechanism of memory leak analysis of mixed mode (managed and unmanaged) / 64-bit + AnyCPU application and from all windows api's CaptureStackBackTrace is most suitable for my needs, but as I have analyzed - it does not support managed code stack walking. 
  But that function API is closest to what I need (Since it also calculates back trace hash - unique identifier of particular call stack).</p>
  
  <p>I've excluded different approaches of locating memory leaks -
  most of software which I have tried is either crashing or does not work unreliably, or gives bad results. </p>
  
  <p>Also I don't want to recompile existing software and override malloc / new other mechanism - because it's heavy task (we have huge code base with a lot of dll's). Also I suspect this is not one time job which I need to perform - issue comes back with 1-2 year cycle, depending of who and what was coding, so I would prefer to have built-in memory leaks detection in application itself (memory api hooking) instead of fighting with this problem over and over again.</p>
  
  <p><a href="http://www.codeproject.com/Articles/11132/Walking-the-callstack">http://www.codeproject.com/Articles/11132/Walking-the-callstack</a></p>
  
  <p>Uses StackWalk64 windows API function, but does not work with managed code. Also 64 bit support is not fully clear to me - I have seen some walkaround for 64 bit problem - I suspect that this code does not fully work when stack walk is done within same thread.</p>
  
  <p>Then there exists process hacker:
  <a href="http://processhacker.sourceforge.net/">http://processhacker.sourceforge.net/</a></p>
  
  <p>Which also use StackWalk64, but extends it's call back function (7th and 8-th parameters) to support mixed mode stack walking.
  After a lot of complexities with 7/8 call back functions I've managed to reach also support of StackWalk64 with mixed mode support (Catching stack trace as vector - where each pointer refers to assembly / dll location where call went by).
  But as you may guess - the performance of StackWalk64 is insufficient for my needs - even with simple Message box from C# side, application simply "hangs" for a while until it starts up correctly.</p>
  
  <p>I haven't seen such heavy delays with CaptureStackBackTrace function call, so I assume that performance of StackWalk64 is insufficient for my needs.</p>
  
  <p>There exists also COM based approach of stack trace determination - like this:
  <a href="http://www.codeproject.com/Articles/371137/A-Mixed-Mode-Stackwalk-with-the-IDebugClient-Inter">http://www.codeproject.com/Articles/371137/A-Mixed-Mode-Stackwalk-with-the-IDebugClient-Inter</a></p>
  
  <p><a href="http://blog.steveniemitz.com/building-a-mixed-mode-stack-walker-part-1/">http://blog.steveniemitz.com/building-a-mixed-mode-stack-walker-part-1/</a></p>
  
  <p>but what I'm afraid of - it requires COM , and thread needs to be com initialized, and due to memory api hooking I should not touch com state within any thread, because it can results in heavier problems (e.g. incorrect apartment initialization, other glitches)</p>
  
  <p>Now I've reached the point when windows API becomes insufficient for my own needs, and I need to walk through call stack manually.
  Such examples can be found for example:</p>
  
  <p><a href="http://www.codeproject.com/Articles/11221/Easy-Detection-of-Memory-Leaks">http://www.codeproject.com/Articles/11221/Easy-Detection-of-Memory-Leaks</a>
  See function FillStackInfo / 32 bit only, does not support managed code.</p>
  
  <p>There are couple of mentions about reversing stack trace - for example on following links:</p>
  
  <ol>
  <li><a href="http://blog.airesoft.co.uk/2009/02/grabbing-kernel-thread-contexts-the-process-explorer-way/">http://blog.airesoft.co.uk/2009/02/grabbing-kernel-thread-contexts-the-process-explorer-way/</a></li>
  <li><a href="http://cbloomrants.blogspot.fi/2009/01/01-30-09-stack-tracing-on-windows.html">http://cbloomrants.blogspot.fi/2009/01/01-30-09-stack-tracing-on-windows.html</a></li>
  <li><a href="http://www.gamedev.net/topic/364861-stack-dump-on-win32-how-to-get-api-addresses/">http://www.gamedev.net/topic/364861-stack-dump-on-win32-how-to-get-api-addresses/</a></li>
  <li><a href="http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/">http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/</a></li>
  </ol>
  
  <p>Especially 1, 3, 4 links give some interesting night reading. :-)</p>
  
  <p>But even thus they are rather interesting mechanisms, there is no fully working demo example on any of them.</p>
  
  <p>I guess one of examples is Wine's dbghelp implementation (Windows "emulator" for linux), which also shows how exactly StackWalk64 works at the end, but I suspect that it's heavily bound to DWARF2 file format executable, so it's not identical to current windows PE executable file format.</p>
  
  <p>Can someone pintpoint me to good implementation of stack walking, working on 64-bit architecture, with mixed mode support (can track native and managed memory allocations), which is bound purely in register / call stack / code analysis.
  (Combined implementations of 1, 3, 4)</p>
  
  <p>Does someone has any good contact from Microsoft development team, who could potentially answer to this question ?</p>