Debugging wine and finding the cause of a crash

[Fabian Maurer]

On Tuesday, November 15, 2016 1:16:06 PM CET Andrew Eikum wrote:
> That's a pretty broad question. You can grep a +relay log for the
> crashing pointer, it may show where that pointer was allocated which
> can help you identify useful debug channels. You could also search
> around for other pointers that appear nearby in the +relay log.  You
> can try searching backwards from the crash for err: or warn: or
> fixme:, which may give a hint as to what's going wrong.
> 
> Do you get a useful backtrace? If not, I wrote a tool to indent +relay
> logs which can help you find what part of Wine is in use during the
> crash: https://gitlab.com/mywinetools/mywinetools/raw/master/nest.py
> 
> Andrew

Thanks for the reply,
unfortunately it's a very broad question, since I don't know too much about 
what's going on. I'm looking for tricks I might now know, for example, not too 
long ago I didn't even know about using "+seh" to find a crash that the 
application processed itself.

The problem is that the backtrace isn't very useful, since the crash occurs in 
a function that is called a few thousand times per second. When nopped out, it 
resolves the crash while breaking collision handling in the game. But since 
the pointer is calculated from a lot of different values and passed around a 
lot, I find it hard to pin down where it comes from.

I'm currently debugging it with x64dbg which fortunately works very well under 
wine, but tracking dozens of different pointers to find out where they come 
from doesn't sound very effective to me.