ansaurus

Question

How to Log Stack Frames with Windows x64

Answer 1

A:

The trick is to stop calling StackWalk64 when it returns 0 in stk.AddrReturn.Offset. This means there are no more frames on the stack. If stk.AddrReturn.Offset is non-zero, you can use that value as the return address.

If you continue calling StackWalk64 after this, my guess is that it will try to interpret whatever is in the memory locations as being a stack and will return unpredictable data.

staffan 2009-02-26 11:59:27

staffan, i added a sample for you above. If you compile and run this it results in the logfile that i also included. The Logfile has 2833 stack entries. It should have only a hand full of. Do you use different parameters? What am i doing wrong?

RED SOFT ADAIR 2009-02-27 12:23:48

Updated my answer after trying out your source.

staffan 2009-02-27 12:49:00

No, the Return adresses are not in the first few frames returned from StackWalk64. Look at the last column of the logfile: It prints out stk.AddrReturn.Offset. The third value is "1"!, the #4 Value is equal to #2 although teher is no recoursion in the sample.

RED SOFT ADAIR 2009-02-27 16:49:06

And if you look at stk.AddrStack.Offset (Second column) you clearly see that the whole content of the stack is returned.

RED SOFT ADAIR 2009-02-27 16:51:23

Answer 2

A:

Watch this, I do not know if it is relevant:
...
Working with Assembly Code Assembly code is straightforward to port to AMD64 and 64-bit Windows—and is worth the effort for performance reasons! For example, you can take advantage of the new 64-bit general-purpose registers (r8-r15), and new floating point and 128-bit SSE/SSE2/floating point registers (xmm8-xmm15). However, there are new 64-bit stack frames and calling conventions you should learn about in the ABI (application binary interface) specifications.
...

lsalamon 2009-02-26 12:16:45

Answer 3

+1 A:

We use minidumps exclusively here. You can generate a stripped down one that just includes stack information and dump out a stack trace from a decent debugger later.

It doesn't solve your problem directly, but I think it will provide you a much better postmortem reporting mechanism.

MSN 2009-02-26 17:30:57

Answer 4

A:

StackWalk64 is the right choice, the first call will give you the caller's address.

Your problem might be that in release you have a lot of inlining going on. The return address may not be what you expect.

edit : you only need to set AddrPC and AddrFrame. Just make sure that your rbp and rip are the ones corresponding to your callee context.

Edouard A. 2009-02-27 13:23:42

Inlining is not the problem. Inline code just doesnt show up with a own stack frame. Only really "called" functions do. I use this since years with 32 Bit.

RED SOFT ADAIR 2009-03-02 11:00:02

Answer 5

A:

Regarding the first issue: disable "Omit stack frames" in thre release version, and the "trivial" stack tracing code will work.

c2j2 2009-06-08 12:57:25

I added /Oy- to the compiler options, which should keep Frame pointers even with Optimization. Sadly it does not work. When using Trial 1 (pointer arithmetic) the release version still crashes.

RED SOFT ADAIR 2009-06-09 09:26:05

Answer 6

A:

Regarding RtlCaptureStackBackTrace, one thing I've noticed on 32-bit Windows is that it fails if you pass too large a number into it for FramesToCapture. Experimentally I've identified 61 as the maximum value, for no reason that I can fathom!

Not sure if it's the same in x64, but that might explain why you're getting no info out.

Sam Deane 2009-07-02 12:32:44

Answer 7

+3 A:

I finally found a reliable way to log the stack frames in x64, using the Windows function CaptureStackBackTrace(). As i did not want to update my SDK, i call it via GetProcAddress(LoadLibrary());

   typedef USHORT (WINAPI *CaptureStackBackTraceType)(__in ULONG, __in ULONG, __out PVOID*, __out_opt PULONG);
   CaptureStackBackTraceType func = (CaptureStackBackTraceType)(GetProcAddress(LoadLibrary("kernel32.dll"), "RtlCaptureStackBackTrace"));

   if(func == NULL)
       return; // WOE 29.SEP.2010

   // Quote from Microsoft Documentation:
   // ## Windows Server 2003 and Windows XP:  
   // ## The sum of the FramesToSkip and FramesToCapture parameters must be less than 63.
   const int kMaxCallers = 62; 

   void* callers[kMaxCallers];
   int count = (func)(0, kMaxCallers, callers, NULL);
   for(i = 0; i < count; i++)
      printf(TraceFile, "*** %d called from %016I64LX\n", i, callers[i]);

This works without problems.

RED SOFT ADAIR 2009-08-26 13:12:28

I'm not sure why you directly load Kernal32.dll, when you can simply include a header file. Also usually kernal32.dll is always loaded anyways for a process... but if you want to minimize include files, then your solution works.

C Johnson 2010-09-28 19:28:16

If you look at http://msdn.microsoft.com/en-us/library/ff552119%28VS.85%29.aspx, you see that RtlCaptureStackBackTrace did not exist before Windows XP. If i would include the headerfile, our application would simply not run on Win2000. Using that approach it does - although (as i just have noticed) it will crash on calling the StackDump as i did not check func for NULL (FIXED that).

RED SOFT ADAIR 2010-09-29 08:38:35

Answer 8

A:

Disassembling RtlCaptureStackBackTrace() I noticed that maximum value passed to RtlCaptureStackBackTrace() should be: framesToSkip+framesToCapture+1 should be less than 64. otherwise it returns 0 and there is no other error codes.

KeRneL 2010-04-01 14:35:45

ansaurus

tags:

views:

answers:

How to Log Stack Frames with Windows x64

related questions