Debugging wine and finding the cause of a crash

[Andrew Eikum]

On Mon, Nov 14, 2016 at 11:58:43PM +0100, Fabian Maurer wrote:
> I'm currently trying to get a program to work that doesn't work with wine, 
> causing an access-violation at some unreadable address.
> 
> The "+seh" output shows that it's the first crash, and "+relay" doesn't help 
> much, since the last calls are "user32.GetKeyState" and similar.
> I already tried debugging the program, but at the place of the crash there 
> aren't any wine functions called, so I assume it's some earlier parts (e.g. 
> during loading) causing the issue.
> 
> How do I go about finding which wine functions are the culprit? Any tips for 
> that, how do you investigate such issues? It would be easy if it crashed 
> directly after calling a WinApi function, but since it seems to crash much 
> later in a completely different part of the code, I don't really know how to 
> proceed.
> 

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