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
Le jeudi 15 juin 2017 à 02:13 +0200, Fabian Maurer a écrit :
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
DISCLAIMER: This is my opinion and is no way to be taken as a legal advice or anything.
The debugger uses a disassembler internally, but the user doesn't have direct access the disassembler functionality. He's limited to the debugger functionality. Thus, debugging is not disassembling and somewhat limits the responsibility of the user.
Regards
Hi,
You already found the one ironclad rule: Don't study Microsoft code, disassembled or leaked C code.
Disassembling the game code is generally OK because we do not reimplement the game.
Wrt your suggestion of comparing the control flow in the game with builtin and native d3dxof: This is getting awfully close to disassembling of the native DLL. A cleaner approach would be to replicate the d3dxof calls the game makes in your own program and see where your program starts to receive different results. The good side effect of this is that you can use this code as a test case to submit along with your fix :-). See dlls/d3dxof/tests for existing tests.
Cheers, Stefan
On 15/06/17 02:13, Fabian Maurer wrote:
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
Hi,
You already found the one ironclad rule: Don't study Microsoft code, disassembled or leaked C code.
Disassembling the game code is generally OK because we do not reimplement the game.
Wrt your suggestion of comparing the control flow in the game with builtin and native d3dxof: This is getting awfully close to disassembling of the native DLL. A cleaner approach would be to replicate the d3dxof calls the game makes in your own program and see where your program starts to receive different results. The good side effect of this is that you can use this code as a test case to submit along with your fix :-). See dlls/d3dxof/tests for existing tests.
Cheers, Stefan
Thank you, I'll try my best.
Regards, Fabian Maurer
-
Fabian Maurer -
Olivier F. R. Dierick -
Stefan Dösinger