With OllyDbg, you can debug standalone DLLs. OS can't start DLL directly, so OllyDbg keeps, as a packed resource, small application that loads your library and allows you to call exported functions with up to 10 arguments.

通过OllyDbg，您可以调试单独的DLL文件。操作系统不能直接运行DLL文件，因此OllyDbg以压缩资源的方式保留着一个可以加载DLL的小程序，这个程序允许您调用至多10个参数的导出函数。

OllyDbg is strongly module-oriented. Module is the main executable file (usually with extension .EXE) or dynamic-link library (usually .DLL) loaded either on startup or dynamically on request. During debugging session you set breakpoints, define new labels and comment assembler commands. When some module unloads from the memory, Debugger saves this information to file with the same name as the debugged module and extension .UDD (stays for User-Defined Data). Next time when OllyDbg loads this module, it automatically restores all debugging information, no matter which program uses this module. Suppose you are debugging Myprog1 that uses Mydll and set some breakpoints in Mydll. Then you start debugging Myprog2 that also makes use of Mydll - and all breakpoints in Mydll are still here, even if Mydll loads on different location!

OllyDbg是高度面向模块[module-oriented]的。模块是在启动时装载的主要可执行文件（扩展名通常为.EXE）或者是依照需要动态装载上的动态链接库（扩展名通常为.DLL）。在调试阶段您可以设置断点、定义新的标签、注释汇编指令，当某个模块从内存中卸载[unload]时，调试器会把这些信息保存在文件中，文件名就是模块的名称，扩展名为.UDD（代表 用户自定义文件[User-Defined Data]）当OllyDbg下一次加载该模块时，它会自动恢复所有的调试信息，而不管是哪一个程序在使用这个模块。假设您正在调试程序Myprog1，这个程序使用了Mydll。您在Mydll中设置了一些断点，然后您开始调试Myprog2，这个程序同样使用了Mydll。这时您会发现，所有Mydll中的断点依然存在，即使Mydll装载在不同的位置！

Some debuggers treat memory of debugged process as a single (and mostly empty) arena 2**32 bytes in size. OllyDbg takes another approach. Here, memory consists of several independent blocks. Any operation on the memory contents is limited to the block. In most cases, this works fine and facilitates debugging. But if, for example, module contains several executable sections, you will be unable to see the whole code at once. Such cases, however, are seldom.

一些调试器把被调试进程的内存当作一个单一的（并且大部分是空的）大小为2**32字节的区域。OllyDbg采用了与之不同的技术：在这里，内存由许多独立的块组成，任何对内存内容的操作都被限制在各自的块内。在大多数情况下，这种方式工作得很好并且方便了调试。但是，如果模块包含好几个可执行区块，您将不能一次看到整体的代码。然而这种情况是非常少见的。

OllyDbg is a memory-hungry application. It allocates up to 3 MB of memory directly on startup and another megabyte or two when you first load debugged program. Each analysis, backup, trace or file dump take their own pieces, so please don't panic when you are debugging larger project and Program Manages shows 40 or 60 allocated megabytes.

OllyDbg是一个很占用内存[memory-hungry]的程序。它在启动时就需要 3 MB，并且当您第一次装载被调试的程序时还需要一两兆内存。每一次的分析、备份、跟踪或者文件提取[Dump]都需要占用一定的内存。因此当您调试一个很大的项目，发现程序管理器显示有40或60兆内存被占用时，请不要惊慌。

To effectively debug some program without source code, you must first understand how it works. OllyDbg contains plenty of features that facilitate this understanding.

想有效地调试一些不带源码的程序，您必须首先理解它是如何工作的。OllyDbg包含大量的特性可以使这种理解变得容易。

First of all, it contains built-in code analyzer. Analyzer walks through the code, separates commands from data, recognizes different data types, procedures, decodes arguments of standard API functions (about 1900 most frequently used) and attempts to guess number of arguments of unknown functions. You can add your own function descriptions, too. It marks entry points and jump destinations, recognizes table-driven switches and pointers to strings, adds some comments and even shows the direction of jumps. Basing on the results of analysis, call tree shows which functions given procedure calls (directly or indirectly) and recognizes recursive, system and leaf procedures. If necessary, you may set decoding hints that help analyzer to decode ambiguous pieces of code or data.

首先，它包含一个内置的代码分析器。分析器遍历程序代码，分出指令和数据，识别出不同的数据类型和过程，分析出标准API函数（大约1900个最常用的）的参数并且试着猜出未知函数的参数数目。您也可以加入自己的函数说明。它标记出程序入口点和跳转目的地，识别出跳转表和指向字符串的指针，加入一些注释，甚至标示出跳转的方向等等。在分析结果的基础上，调用树[CALL TREE]显示哪些函数被指定过程调用（直接或间接）并且识别出递归调用、系统调用和叶子[leaf]过程。如果需要的话，您可以设置解码提示[decoding hints]来帮助分析器解析那些不明确的代码或数据。

OllyDbg also includes Object Scanner. If you possess libraries or object files, Scanner will locate library functions in the debugged application. Calls to standard functions take significant part of all function calls (up to 70%, according to my estimations). If you know which function is being called, it will not distract your attention and you can simply step over the call. Analyzer knows by name more than 400 standard C functions, like fopen or memcpy. I must admit however that OllyDbg in actual version is unable to locate short (consisting of hardly more than return) or similar functions (which differ only in relocations).

OllyDbg还包含目标扫描器[Object Scanner]。如果您有库文件[libraries]或目标文件[object files]，扫描器会在被调试的程序中定位这些库函数。在程序的所有函数调用中对标准函数的调用占很重要的一部分（据我估计可达70%）。如果您知道正要被调用的函数的功能，您就不必把注意力集中在这个函数上，可以简单地步过[step over]这个CALL。分析器知道400多个标准C函数，比如fopen和memcpy。然而我必须承认当前版本的OllyDbg不能定位很短的函数（比一个return命令多不了多少的）或相似的函数（只在重定位上有不同）

Object scanner also understands import libraries. If some DLL exports functions by ordinals, you will see meaningless cryptical numbers instead of function names. Developers of such DLLs usually supply import libraries that set correspondence between symbols and ordinals. Tell OllyDbg to use import library, and it will restore original names.

目标扫描器[Object scanner]也能够识别输入库[import libraries]。如果某个DLL是按序号导出的，您不会看到函数名，只会发现一堆无意义的神秘数字。这种DLL的开发者通常会提供一个输入库来设置符号名和序号间的对应。告诉OllyDbg使用这个输入库，它就会恢复原始的符号名。

Object-oriented languages, like C++, use technique called name mangling that adds information on types and arguments to symbol. OllyDbg can demangle such names, making program more readable.

面向对象的语言（如C++），使用一种叫做name mangling（译注：经查该术语尚无明确译文）的技术，把函数类型和参数都加入函数名中。OllyDbg可以demagle这种函数名，使程序更易读。

OllyDbg fully supports UNICODE. Almost everything you can do with ASCII string is possible with UNICODE, too.

OllyDbg完全支持UNICODE，几乎所有对ASCII字符串的操作都可以同样应用于UNICODE。

Assembler commands are all very similar. It often happens that you don't know whether you've already traced this branch of code or not. In OllyDbg you can add own labels and write comments. This greatly facilitates debugging. Notice that once you commented some DLL, comments and labels will be available each time DLL is loaded - even if you debug different application.

汇编指令都是很相似的。您经常会搞不清自己是不是已经跟踪过某一段代码。在OllyDbg中您可以加入自己的标签和注释。这些极大地方便了调试。注意一旦您注释了某个DLL，以后每次这个DLL被装载时注释和标签都有效――尽管您在调试不同的程序。

OllyDbg traces standard stack frames (those created by PUSH EBP; MOV EBP,ESP). Modern compilers have option that disables generation of stack frames, in this case stack walk is not possible. When execution reaches call of known funbction, stack window decodes its arguments. Call stack window displays sequence of calls leading to the actual point of execution.

OllyDbg可以跟踪标准的堆栈帧（被PUSH EBP; MOV EBP,ESP所创建的）。现代编译器有禁止产生标准堆栈帧的选项，在这种情况下堆栈WALK（译注：行走？）是不可能的。当程序运行到已知的函数时，堆栈窗口[stack window]解析它的参数，调用堆栈[call stack]窗口显示经过怎样的调用序列来到当前位置。

Modern OO applications extensively use structured exception handling (SEH). SEH window displays chain of exception handlers.

现代的面向对象应用程序广泛地应用结构化异常处理（Structured Exception Handling,SEH）技术。SEH窗口可以显示异常处理链。

Many different search options allow you to find binary code or data, command or a sequence of commands, constant or string, symbolic name or a record in a run trace.

多种不同的搜索选项可以让您找到二进制代码或数据、指令及一串指令、常量或字符串、符号名或在一次RUN跟踪中的一个记录。

For any address or constant, OllyDbg can prepare the complete list of commands referencing this address or constant. You then walk this list and decide whether given reference is of any importance for you. For example, some function may be called explicitly, or optimizing compiler can load its address in register and then call function indirectly, or push address into the stack as a parameter - not a problem, OllyDbg will find all such places. It will even find and list all relative jumps and switches to the specified location (Really? Oh dear!..)

对于任何地址或常量，OllyDbg可以准备出参考到该地址或常量的全部命令的列表。然后您可以在这个列表中WALK，找出对您来说是重要的参考。举例来说，某个函数可能被明确地调用，或者经过编译器优化后把地址放入寄存器间接调用，或者把地址压入堆栈作为一个参数――没问题，OllyDbg会找出所有这样的地方。它甚至能找到并列出所有和某个指定的位置有关的跳转（真的？哦天哪！...）

OllyDbg supports all standard kinds of breakpoints - unconditional and conditional, memory (on write or access), hardware or on access to the whole memory block (the last two work only under Windows ME, NT, 2000 or XP). Conditional expressions can be very complex (?reak when bit 2 in [ESP+8] is set and word at location 123456 is less than 10 or EAX points to UNICODE string that begins with 'ABC', but skip first 10 breaks"). You may specify one or several commands that OllyDbg passes to plugins when application pauses. Instead of pausing, you can request logging the value of another expression (with brief explanation) or logging the arguments of function known to OllyDbg. On Athlon 2600+ running under Windows 2000, OllyDbg can process up to 25000 conditional breaks per second.

OllyDbg支持所有标准类型的断点――非条件和条件断点、内存断点（写入或访问）、硬件断点或在整个内存块上下断（后两项功能只在Window ME,NT,2000,XP中有效）。条件表达式可以非常复杂（“当[ESP+8]的第2位被设置并且123456位置处的字[word]小于10或者EAX指向一个以“ABC”开头的UNICODE字串，跳过前10次断点在第11次时中断”）。您可以设定一条或多条指令，当程序暂停时由OllyDbg传递给插件。除了暂停，您还可以要求记录某个表达式的值（用简短的说明）或者记录OllyDbg己知的函数的参数。在Athlon 2600+、Windows2000环境下，OllyDbg可以每秒处理多达25000个条件断点。

Another useful feature is tracing. OllyDbg supports two kinds of tracing: hit and run. In the first case, it sets breakpoint on every command in specified range (for example, in the whole executable code). After command is reached, it removes breakpoint and marks command as hit. This allows to check at a glance whether some branch of code was executed or not. Hit tracing is astoundingly fast, after short startup application reaches almost full speed. As INT3 breakpoint may have disastrous effect when set on data, I recommend that you don't use fuzzy recognition of procedures. Hit tracing is not available at all when code is not analyzed.

另一个有用的特性是跟踪。OllyDbg支持两种方式的跟踪：Hit和Run。在第一种情况下，它在指定范围内的每条指令上设置断点（比如在全部可执行代码中）。当到达设断的指令后，OllyDbg删除断点并且把该指令标记为hit。这种方法可以用来检测某段代码是否被执行。Hit跟踪速度惊人的快，在一个很短时间的启动后程序几乎达到了全速。（译注：这应该是与不进行调试时速度相比而言）因为INT3断点可能对数据有灾难性的影响，我建议不要使用模糊识别过程。当代码没有被分析时Hit跟踪是完全不可用的。

Run trace executes program step by step and records exact execution history together with contents of all registers, known arguments and optionally commands (this helps when code is self-modified). Of course, this requires plenty of memory (depending on the mode, from 15 to 50 bytes per command) but allows for precise backtracing and analysis. You can run trace only selected pieces of code, or even single commands, or you can skip quasi-linear pieces that are of no special interest. For each address, OllyDbg calculates number of times this address appears in run trace log, implementing slow but comprehensive profiling. For example, special command lets you set run trace breakpoint on every entry to recognized procedure, then profile gives you notion how frequently each routine is called. Run trace may automatically pause on command, address range or counter.

Run跟踪一步一步地执行程序同时记录精确的运行历史和所有寄存器的内容、已知的参数和可选的指令（当代码是自修改时会有帮助）。当然，这需要大量的内存（每个指令需要15至50个字节，取决于调试的模式）但是可以精确地回溯和分析。您可以只在选定的一段代码甚至是一条指令中进行Run跟踪，或者您可以跳过无关紧要的代码。对于每个地址，OllyDbg计算这个地址在Run跟踪日志中出现的次数，实现缓慢但是全面的profiling。比如说，某命令让您在每个已识别的过程入口处进行Run跟踪，那么profile就会给您一个每个过程被调用的频率。在到达某条指令、某个地址范围或指令计数器达到某一数值时Run跟踪可以自动地停止。

OllyDbg automatically manages threads in multithread applications. If you step or trace your program, it automatically resumes current thread and suspends all others. If you run it, OllyDbg restores previous thread state.

在多线程程序里OllyDbg可以自动管理线程，如果您步进或跟踪您的程序，它会自动恢复当前线程而挂起其它线程。如果您运行它，OllyDbg会恢复先前的线程状态。

You can make momentary snapshot (called backup) of the memory block. OllyDbg then highlights all changes. You can save backup to file and read back, thus locating the differences between two runs. You can view backup, search for next modified piece, or undo all or selected changes. Patch manager remembers all patches applied to debugged application in previous sessions and can apply them again.

您可以为内存块建立快照（叫做备份）。OllyDbg会高亮显示所有的改动。您可以把备份保存到文件或从文件中读取出来，从而发现两次运行的不同之处。您可以查看备份，搜索下一处改动，恢复全部或选定的改动。补丁管理器[Patch manager]记录了上次应用到程序中的所有补丁，在下次调试时可以再次应用它们。

You can easily transfer your patches back to the executable file. OllyDbg will automatically correct fixups.

您可以很容易地把您的补丁加在可执行文件上。OllyDbg会自动进行修正。

You can? use OllyDbg on 16-bit Windows with Win32s. This 32-bit extender does not implement all necessary debugging functions.

您不能在带有Win32s的16位Windows下使用OllyDbg.这种32位的扩展有一些必需的调试功能无法实现。

You can debug neither DOS nor 16-bit NE (New Executable) files, and I have no plans to support this in the future. R.I.P., old good command prompt!

您既不能调试DOS程序也不能调试16位NE（New Executable）格式文件，我也没有打算在未来的版本中支持这些。安息吧，古老而美好的命令提示符！