OllyDbg is a 32-bit assembler level analysing debugger for Microsoft Windows. Emphasis on binary code analysis makes it particularly useful in cases where source is unavailable.
Old test results
The test results for this version are very old, and as such they may not represent the current state of Wine. Please consider submitting a new test report.
Selected Test Results (selected in 'Test Results' table below)
What works
Debugging multithreaded applications
Attaching to running programs
Sets conditional, logging, memory and hardware breakpoints
Dynamically traces stack frames
Searches whole allocated memory
Finds references to constant or address range
Examines and modifies memory, sets breakpoints and pauses program
on-the-fly
Assembles commands into the shortest binary form
Properly decodes Wine API when Wine was compiled with debugging symbols (-g)
What does not
Some dlls are reported as "unkown format" upon load event.
Error: Unable to open or read executable file 'foo'
When applications are first loaded in to debugger, you might get message boxes with following errors:
Unable to open or read executable file 'foo.dll'
or
Bad or unknown format 'foo.dll'
This is expected (and annoying) behaviour. The debugger tried to physically read the dll by looking into "system32" directory of the WINEPREFIX. Most Wine builtins don't have a fake placeholder by default hence the error.
Just dismiss the message boxes with 'OK'.
You can work around this problem by adding the dll in question to "[FakeDllsSection]" of "tools/wine.inf" (wine source tree) and then rerun 'wineboot --update' to have it installed in WINEPREFIX.
Disassembly (CPU Window) goes blank while stepping/pausing
When the disassembly window goes blank (after pausing, single stepping into wine, etc.) you probably hit a code location which the debugger can't properly handle due to design of Wine/Linux.
The debugger hits ELF code in wine builtins outside of win32 API virtual mapping range which leads to empty code/disassembly window (debugger needs to read memory in order to disassemble it). Look at registers window while you step, you can see EIP still changing but no code is actually displayed. Just hit a few times run until return until the code reaches PE/win32 memory range again. Then the code/disassembly will reappear.
This is expected behaviour and by design.
Debugging/Tracing is slow
Depending on situation, the debugger reads large memory chunks from target process (debuggee). The transfer of large memory chunks between wineserver and debugger process leads to performance loss.
Technically, wineserver uses Linux ptrace facility to read remote process memory. Only 32-bit integers can be read/written at a time which causes extreme overhead for large blocks.
This performance problem has been solved in Ollydbg v2 which optimized the needed memory reads (for disassembly, memory view) to much smaller chunks.
