Fix the exception address in WriteMinidump.

This is a speculative fix for some call stacks not showing up properly(when
uploaded without an actual crash) using the function
ExceptionHandler::WriteMinidump.

Siggi debugged it and mentioned that the call stacks are actually there but the
CONTEXT is wrong.

I downloaded the dump for the incorrect call stack and a normal dump. Then in
windbg after doing an .ecxr, I did an .exr -1.

In the normal call stack's dump it listed ExceptionAddress which was non NULL.
In the the incorrect call stack's dump the exception address was NULL. But all
the other data like exception code, numberparameters etc were actually OK. (It
would be interesting to know if Siggi had the similar observation as well)

Initial thought was this was getting stomped. But after combing through the code
it looks like this exception address is never set. (In normal cases there would
be a crash and we would call the GetExceptionInformation fn which  would return
us a struct with all those information).

So when we fake the exception I made the ExceptionAddress equal to
_ReturnAddress. Then in my build I enabled breakpad and generated a dump. When I
did exr -1 I was able to see the right exception address and the call stack
looked right too. But I am not sure how this will behave in the crash server and
if we will get the right stack. So this is a speculative fix. will verify it in
the next canary.

If you find anything wrong with the logic let me know. Also this fix should NOT
have any impact on regular call stack generation due to crashes as they follow a
different code path. This fix should only affect call stack generation without
crash(for which sync is the only 'working' consumer as of today)

[lipalani]

Whoever has the time please review.

[Siggi]

lgtm - but I doubt this will fix the problems you reported. In the stack traces
I looked at, the CONTEXT record had been mangled such that e.g. the captured EBP
value was zero. Come to think of it, this could be due to MiniDumpFilterMemory
[http://msdn.microsoft.com/en-us/library/windows/desktop/ms680519(v=vs.85).aspx]
being set on minidump capture. This, combined with the fact that the CONTEXT
record is in the middle of the captured stack, coupled with FPO, could be
causing the crash unwinding problems.

[Mark Mentovai]

LGTM to try it.

http://breakpad.appspot.com/347003/diff/1/src/client/windows/handler/exceptio...
File src/client/windows/handler/exception_handler.cc (right):

http://breakpad.appspot.com/347003/diff/1/src/client/windows/handler/exceptio...
src/client/windows/handler/exception_handler.cc:35: #include <intrin.h>
Style nit: C system headers come before C++ system headers. This belongs in the
block above, with <ObjBase.h>.