Hi all.
While trying to run a crashing application I used a debugger and found out the crash is inside wined3d, I then started looking for ways to convert that address back into what function it should be so I can breakpoint it and check.
At first I got into http://www.nirsoft.net/utils/dll_export_viewer.html and it looked like what I needed but the program does not seem to work in Wine DLLs.
Adding +d3d,+relay and checking the calls is awfully verbose, but I'm still trying it.
Part of the function showing the addresses, last line crashes:
wined3d.dll:7EBCEF19 mov eax, [ebp+8] wined3d.dll:7EBCEF1C mov eax, [eax+0EC54h] wined3d.dll:7EBCEF22 mov edx, [ebp-0Ch] wined3d.dll:7EBCEF25 shl edx, 2 wined3d.dll:7EBCEF28 add eax, edx wined3d.dll:7EBCEF2A mov eax, [eax]
Is there anyway to find out where is this function in the source code?
Best regards, Bruno
Am 30.08.2016 um 21:03 schrieb Bruno Jesus:
wined3d.dll:7EBCEF19 mov eax, [ebp+8] wined3d.dll:7EBCEF1C mov eax, [eax+0EC54h] wined3d.dll:7EBCEF22 mov edx, [ebp-0Ch] wined3d.dll:7EBCEF25 shl edx, 2 wined3d.dll:7EBCEF28 add eax, edx wined3d.dll:7EBCEF2A mov eax, [eax]
Is there anyway to find out where is this function in the source code?
Hello Bruno, probably you can run your test program with the gdb debugger:
$ wine winedbg --gdb d3d8_test.exe.so ... 0025:0026: loads DLL C:\windows\system32\wined3d.dll @0x7ec20000 (0<0>) ... Wine-gdb> info symbol 0x7ec2EF19 init_output_registers + 1172 in section .text of /.../dlls/wined3d/wined3d.dll.so
Hope this helps you.
Kind regards, Bernhard
Am 30.08.2016 um 22:09 schrieb Bernhard Übelacker:
$ wine winedbg --gdb d3d8_test.exe.so ... 0025:0026: loads DLL C:\windows\system32\wined3d.dll @0x7ec20000 (0<0>) ... Wine-gdb> info symbol 0x7ec2EF19 init_output_registers + 1172 in section .text of /.../dlls/wined3d/wined3d.dll.so
This does not work in case wined3d got relocated. You can either use addr2line or winedbg directly on the target process. For addr2line you need to know the base address of wined3d in the crashed process and then use something like:
addr2line -e wined3d.dll.so -j .text 0xdeadbeef
where 0xdeadbeef is the address of the crash minus the base address of the ELF section as shown in the crash dump. I think using winedbg is easier. Either directly start the process using winedbg or in case the process detects debuggers, you can also SHIFT + right click on the crash dialog to start winedbg. Then you can just use bt to display the backtrace including the source code lines (although the output should be identical to the crash dialog). For arbitrary addresses, you can just disassemble some instructions, it should also display the filename and line number using x/10i 0xdeadbeef. You can also use registers this way (for example x/10i $eip).
If the application sets up its own crash handler, you can either attach to the process when it displays an error by starting winedbg as standalone program and then use "info process" and "attach 0x...". This way you won't get a correct backtrace though, so you might want to edit dlls/ntdll/signal_i386.c instead. I attached a hack to prevent 32 bit applications from catching access violations. In case they call SetUnhandledExceptionFilter, you also need to make this a noop as it replaces the handler to start the debugger.
Regards, Michael
On Tue, Aug 30, 2016 at 5:40 PM, Michael Müller michael@fds-team.de wrote:
Am 30.08.2016 um 22:09 schrieb Bernhard Übelacker:
$ wine winedbg --gdb d3d8_test.exe.so ... 0025:0026: loads DLL C:\windows\system32\wined3d.dll @0x7ec20000 (0<0>) ... Wine-gdb> info symbol 0x7ec2EF19 init_output_registers + 1172 in section .text of /.../dlls/wined3d/wined3d.dll.so
This does not work in case wined3d got relocated. You can either use addr2line or winedbg directly on the target process. For addr2line you need to know the base address of wined3d in the crashed process and then use something like:
addr2line -e wined3d.dll.so -j .text 0xdeadbeef
where 0xdeadbeef is the address of the crash minus the base address of the ELF section as shown in the crash dump. I think using winedbg is easier. Either directly start the process using winedbg or in case the process detects debuggers, you can also SHIFT + right click on the crash dialog to start winedbg. Then you can just use bt to display the backtrace including the source code lines (although the output should be identical to the crash dialog). For arbitrary addresses, you can just disassemble some instructions, it should also display the filename and line number using x/10i 0xdeadbeef. You can also use registers this way (for example x/10i $eip).
If the application sets up its own crash handler, you can either attach to the process when it displays an error by starting winedbg as standalone program and then use "info process" and "attach 0x...". This way you won't get a correct backtrace though, so you might want to edit dlls/ntdll/signal_i386.c instead. I attached a hack to prevent 32 bit applications from catching access violations. In case they call SetUnhandledExceptionFilter, you also need to make this a noop as it replaces the handler to start the debugger.
Thanks to you both, I'll try both methods and find out what works best.
Best regards, Bruno
-
Bernhard Übelacker -
Bruno Jesus -
Michael Müller