Shame on me! In only one day, I have received 15 bug reports related to the v2.0 pre-alpha code! Most of them concentrate around the protection violation at address 477AC3 (a more or less obvious bug), but there are also other crashes reported. What should I say? Thank you! Without your steady help, OllyDbg 1.10 would never reach its actual quality. Hopefully, in some time second version will reach at least the same standards... Anyway, in the couple of weeks there will be update here. And - thank you again! Please keep it this way!
The child is big enough to show it to the public, so download this and have a look. Is this version functional? Yes. Is it better than 1.10? Definitely not. Is it better than v1.00? In some aspects - maybe, but in general - no. Can you use it for debugging? Yes, but you will miss many, many features... So please don't be too critical and send me no emails - this version is not even a full-featured alpha, and will change dramatically in the next several weeks or monthes. But in the case that OllyDbg will crash and generate errorlog.txt, be kind and do send me this file - I will need it for debugging. And now - enjoy!
Now OllyDbg 2 can save analysis data to the .udd files. Comparing to the previous version, they are very big - two to three times larger, mainly due to the register predictions. For almost every command I keep ESP and EBP relative to the entry point. Many modern compilers don't use standard stack frames; instead, they address all arguments and local data over ESP. Predictions allow to decode the meanings of ESP-related offsets. They are also very helpful when tracing the call stack.
It takes significant time to load such a huge amounts of data. First version took between 0.1 and 0.7 seconds per module. With full analysis of all modules requested (and this will be the default option), startup took several seconds on my Athlon 4000+. Now, after several days of deep optimizations, this time got three times shorter.
