Include Function Names

Probably the dumbest question ever… Sorry for this.

I check “Include Function Names” and build for Windows. When the app crashes, how do I get a stack crawl? Windows 2008.

The stack at the last call to Raise is available from RuntimeException.Stack. The function names are mangled, but here’s someone else’s cleanup code.

Not what I was asking. I need the stack crawl from the crash report, like we get in Crash Reporter on the Mac.

There’s currently no way to do this with applications built with Xojo.

Sorry. I assumed you wanted a stack trace. I’ve never heard of a stack “crawl” before.

Really? I might have been imagining things, but couldn’t we do this with Dr. Watson and Real Studio built apps in the XP days? What about Linux? Is it possible there now? I don’t even mind if the names are mangled beyond mortal comprehension. Somewhere to start on a crash…

I don’t believe it was ever possible to get a stack trace that included RB symbols on Windows or Linux. Even with ‘Include Function Names’ turned on, a minidump just doesn’t have enough information to recover the names. The Xojo compiler doesn’t have a true PE32 linker that outputs symbol information into the executable itself.

OK, thanks Joe.

I wrote a How-To on this years ago on the NUG - here’s my repost from Feb 26, 2010:

[Note: I’m not sure this gives you all the symbols you are looking for, but it’s better than nothing…]

OSX gives you a stack trace on crashes by default; win32 does not. A stack trace shows clearly what method the crash happened in, what method called that method, and so on.

It is however relatively easy to get a stack trace on win32 using WinDbg

This should probably be in a FAQ somewhere:

  1. Build your realbasic app’s EXE as usual (make sure “App.IncludeFunctionNames” is enabled in the IDE)

  2. Install WinDbg, a free tool from microsoft:

  3. Launch WinDbg

  4. Use WinDbg to launch your realbasic app:
    File/Open Executable… then choose your realbasic app’s EXE.

  5. run your app normally until it crashes
    Note that winDbg may stop at a few places – just hit F5 key (“Debug/Go” menu) to keep going. Watch the log and you’ll see the crash. WinDbg may complain about “missing symbols” which you can ignore typically. (you can download more symbols which lets you debug crashes inside Win32 API itself, but that’s usually not necessary).

  6. For more debugging goodness, insert calls to
    System.DebugLog currentMethodName
    in your realbasic code

These debug statements will be included in the WinDbg log, which can help you figure out what’s going wrong.

Using WinDbg is invaluable – I’ve been able to determine, for example, that certain crashes are happening within QuickTime rather than within my code.

And I wrote a FR for this way back then too:

Thanks Michael. This is really close to what I remember. A sprinkle of System.DebugLog calls is gonna have to be workable. Heh.