WineHQ

OllyDbg

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.

Application Details:

Version: 1.10
License: Shareware
URL: http://www.ollydbg.de/
Votes: 0
Latest Rating: Gold
Latest Wine Version Tested: 1.3.20

Maintainers: About Maintainership

No maintainers. Volunteer today!

Test Results

Old test results
The test results you have selected are very old and may not represent the current state of Wine.
Selected Test Results

What works

Debugging of complex programs

Disassembly, attaching to a running process; detaching, running, pausing, restarting and closing a process; breakpoints; stepping in to and over modules; animating in to and animating over modules; execute 'till user code. Jumping to various parts of the code. Searching for all referenced text strings, and through those strings. Searching for labels, assembling new code over existing code, patching the resulting executable. Viewing all of the following: the call stack, the log, executable modules, memory, breakpoints, and references. Changing all of the folowing: fonts, UDD and plugin paths, color schemes, code highlighting. The following plugins: Analyze This!, GODUP. Minimizing, maximizing, resizing, and moving Olly's own internal windows. Custom DLL loader.Nothing


What does not

Parts which involve stepping into wine builtin dll code outside of PE sections.
Main CPU windows goes blank then.

Some dlls are reported as "unkown format" upon load event. Annoying but harmless, message box can't unfortunately be automagically dismissed by program option (needs manual confirm).

Some Plugins which rely/peek into internal windows data structures don't work (expected).

Workarounds

What was not tested

1% of remaining functionality

Hardware tested

Graphics:

  • GPU:
  • Driver:

Additional Comments

selected in Test Results table below
Operating systemTest dateWine versionInstalls?Runs?Used
Workaround?
RatingSubmitter
ShowUbuntu 10.10 "Maverick" i386 (+ variants like Kubuntu)May 20 20111.3.20Yes Yes GoldAnastasius Focht 
ShowFedora 12 x86_64Jul 22 20101.2Yes Yes GoldAnastasius Focht 
ShowGentoo Linux x86_64Dec 22 20081.1.11Yes Yes Goldan anonymous user 
ShowUbuntu 7.04 "Feisty" amd64 (+ variants like Kubuntu)Feb 27 20080.9.56.N/A Yes GoldJeffZ 
CurrentFedora 8Jan 25 20080.9.54.Yes Yes GoldAnastasius Focht 

Known Bugs

Bug # Description Status Resolution Other apps affected
7560 ollydbg fails to debug multithreaded apps CLOSED INVALID View
7635 OllyDbg 1.10 blanks on pause or attach CLOSED WONTFIX View
10249 ollydbg complains about unexpected debug events from child processes after attaching to the debuggee CLOSED FIXED View

Show open bugs

HowTo / Notes

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 o­pen 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.

With commit 1a79912a10a6cded54d1f1de5f746bbffec3ffee (Wine post-1.2) the s­ituation somewhat improved. WIneserver now uses /proc/pid/mem to read process memory since it should be faster.

Comments

Comments Disabled

Comments for this application have been disabled because there are no maintainers.
Back