Getting KCrash & DrKonqi on windows

[George Kiagiadakis]

Hi guys,

These days I have been working again on improving KCrash and I also
had a look again at its windows port that I had started some months
ago. My findings are encouraging, but there are issues that I need to
discuss with you.

First, I'll explain briefly how KCrash works, just to get an idea. The
KCrash API has a UNIX signal handler that is registered when
KApplication is constructed. This signal handler has 3 functions:
1) It calls an "emergency save function" that the application may
specify to attempt to save its data.
2) It restarts the application, if the application has set the
KCrash::AutoRestart flag with KCrash::setFlags().
3) It launches drkonqi to debug itself and sleeps until drkonqi exits.

On windows, UNIX signal handlers work (for compatibility) with the
SIGSEGV, SIGFPE, SIGILL, SIGABRT, SIGTERM and SIGINT signals, but
probably not on all windows versions (for example docs for VC .NET say
that SIGSEGV is never signaled on windows, but docs for VC9 say it is,
and it actually works here on windows 7, but I doubt we can rely on
it). So, I found another way of doing it, using the windows unhandled
exception filter (see SetUnhandledExceptionFilter), which looks like
the same thing as a unix signal handler, but with different arguments.
So, with a few modifications, the KCrash signal handler works fine.

Let's get to DrKonqi now. The code compiles as it is, but requires a
minor modification to start. It starts gdb to generate a backtrace,
but gdb fails to generate anything valid. The problems begin here...

I have been desperately trying to find a debugger that can produce a
valid backtrace of a crashed process. gdb fails, and so does windbg. I
looked into DrMingw, which has some interesting code that uses the
StackWalk api from dbghelp.dll (imagehlp.dll on other windows
versions) in combination with libbfd from binutils. I didn't manage to
compile it, but I am confident that with some hacking it should work.
I also found StackWalker [1], which is a class that also uses the
StackWalk api to generate backtraces. It's meant to be run from the
unhandled exception filter function, but I managed to make it work as
an external process that attaches to the crashed one with very little
effort. To my surprise, it generates a valid backtrace (on processes
that even windbg fails!), but only for applications built with msvc. I
guess that it needs some glue with libbfd to be able to read the
symbols from the gcc format.

That actually means that if we want drkonqi on windows, we need to
implement our own debugger...! That is not a very trivial task and
although we can reuse some code from StackWalker (BSD-licensed), I
believe it will be a quite bigger project than it seems it is. That
said, I am not really interested in developing such a debugger myself.

I would like to hear your opinion on this matter, or any other ideas
that you may have.