Approach to debugging wine issues

Fabian Maurer dark.shadow4 at web.de
Wed Jun 14 19:13:58 CDT 2017


Hello Wine Devs,

I'm currently trying to investigate an crash with an old game called 
KnightOfKnights (See Bug 43180).

I already know which dll is responsible for the crash, and the native dll fixes 
it. The crash appears in native code of the game though.

Now my approach would be to open the program with a debugger (x64dbg works 
nice under wine) and then step through the program, finding where the null-
pointer comes from until I reach the wine function that returned something 
wrong.
After all, I can compare the control flow using the native d3dxof dll and the 
builtin d3dxof dll to see where the game gets the value(s) that lead to crash, 
the goal here would be to find one or more functions from d3dxof that return a 
different value, like a nullpointer.
Then I could begin hacking wine code to find out why it returns something wrong 
and try to fix that,  without looking at the native code of course.

Now my question, is this an accepted solution to fixing bugs? I read in the 
wiki that disassembling a program to diagnose bugs is discouraged due to legal 
issues and difficulty, though I don't really see another way to track it down.

Any insights from you guys and girls who are used to fixing bugs? Just figured I 
should ask, before I try to create a solution by ways you won't accept.

Regards,
Fabian Maurer



More information about the wine-devel mailing list