Somehow it seems Olly (version 2 (http://www.ollydbg.de/version2.html)) gets slower and slower when loading an executable. The reason: it loads an awful lot of udd files, and that takes about 3-5 seconds.
Has Windows become more bloated? I have a dedicated udd folder, and it holds 27 files with a total of 55MB.
Is there any trick to speed up the loading of an executable?
... and in a related question, just what is a .udd file anyhow? I do notice dozens of them being loaded when I use Olly.
OLLYDBG.HLP:
QuoteOllyDbg 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!
Quote from: jj2007 on October 15, 2022, 10:56:46 AM
Is there any trick to speed up the loading of an executable?
Use ollydbg 1.10 :tongue: I've tried v.2, but would rather use v1.10 myself.
In fact ollydbg 1.10 is one of the few programs I keep in my OS backup. Masm32 of course, resed, opera browser, and a handful of others. Anything else, I install as needed. :biggrin:
Also olly v2 analyses all the .dlls called from the program being debugged, and stores a udd file for each one. And yes if you are running Windows 10/11 those OSs are becoming more bloated.
Have you tried xdbg32/64?
Hi Jochen,
QuoteIs there any trick to speed up the loading of an executable?
Maybe not a very practical solution but could you try to use a Ramdisk like Imdisk?
http://www.ltr-data.se/opencode.html/#ImDisk
Quote from: jj2007 on October 15, 2022, 10:56:46 AM
Somehow it seems Olly (version 2 (http://www.ollydbg.de/version2.html)) gets slower and slower when loading an executable. The reason: it loads an awful lot of udd files, and that takes about 3-5 seconds.
Has Windows become more bloated? I have a dedicated udd folder, and it holds 27 files with a total of 55MB.
Is there any trick to speed up the loading of an executable?
Not sure which version of Windows you are using, but windows has always been bloated. Have you tried Chris Titus Debloater (https://christitus.com/windows-tool/) for Windows 10?Honestly, sometimes I think Jabba the Hut has decided to live on my Win 10 install.
Quote from: Shintaro on October 16, 2022, 01:15:42 AMHave you tried Chris Titus Debloater (https://christitus.com/windows-tool/) for Windows 10?
Looks interesting, thanks. Right now I am still on Win7...
OllyDbg ver 1 has dozens of proven bugs
so ver 2 is the last stable fixed version that worth attention, IMHO
you could use the test app made by Oleh to validate this all..
https://prnt.sc/E440Nv58gywT (https://prnt.sc/E440Nv58gywT)
Use x64dbg, olly is dead
Quote from: morgot on October 30, 2022, 08:51:32 AM
Use x64dbg, olly is dead
If you can show me how to convince x32Dbg to show me the symbols in the attached exe, I may give it another try (there are no pdb or ilk files - no problem for Olly)
I use the https://github.com/ThunderCls/xAnalyzer plugin
(https://i.postimg.cc/L5JyydjL/screenshot-143.png)
Is there also a 64 bit version of that plug-in, fearless?
:biggrin:
JJ,
> Is there any trick to speed up the loading of an executable?
Yes but you won't like it, get yourself a great big ugly fast desktop full of CPU hoot, lots of memory, many cores and some decent large storage and many of the things you complain about will magically disappear.
For my DEV box, I am using legacy hardware, a 6 core i7 clocked up to 4 gig, 64 gig of memory and about 30tb of storage and most things load in a "blink". Keep your laptop for travelling in the train, sitting in the park or drinking cappucino at a cafe.
Quote from: fearless on October 30, 2022, 12:48:26 PM
I use the https://github.com/ThunderCls/xAnalyzer plugin
And that's better because...?
(http://www.jj2007.eu/pics/OllyVsX32.png)
Quote from: hutch-- on October 30, 2022, 05:43:43 PM> Is there any trick to speed up the loading of an executable?
Yes but you won't like it
I can confirm that, I don't like it :thumbsup:
I do keep an eye on later hardware and both AMD and Intel very latest CPUs are starting to show some real performance gains but they run like furnaces which turns me off a lot as I do a reasonable amount of work that runs at near 100% for extended periods. My old i7, the dev box will heat up to about 65 - 70 c but the 12 and 14 core Xeons struggle to get over 50c being thrashed at near 100%.
14 core running at about 2.9 gig for hours will do a massive amount of work and I doubt the new ones will take a hiding like this. They have some impressive low thread count speeds but with all cores loaded, I doubt they will maintain the speed or reasonable temperatures.
Quote from: zedd151 on October 30, 2022, 12:50:38 PMIs there also a 64 bit version of that plug-in, fearless?
Yes in the releases in that plugins repo on github https://github.com/ThunderCls/xAnalyzer/releases (http://github%20https://github.com/ThunderCls/xAnalyzer/releases) there is:
- xAnalyzer.dp32 - x86 32bit plugin.
- xAnalyzer.dp64 - x64 64bit plugin.
- apis_def.zip - the defintion files.
Place the .dp32 plugin into the \x64dbg\x32\plugins folder and the .dp64 plugin into the \x64dbg\x64\plugins folder.
And the apis_def.zip which is extracted into a \x64dbg\x32\plugins\apis_def folder and extracted into a \x64dbg\x64\plugins\apis_def folder (create the apis_def folders manually and extract to them) - the *.api files and header\*.h.api in those folders have most win32 sdk api calls.
Plus its possibly to create and add your own for your own sources. I did a few for SDL and Lua functions, and for a couple of my ModernUI controls - which reminds me I should do a pull request to add the SDL and Lua ones to the xAnalyzer repo.
Hi fearless,
I would like to see my own symbols, see below. From judging your screenshot, that seems not possible, or am I wrong?
Quote from: jj2007 on October 30, 2022, 08:14:36 PM
(http://www.jj2007.eu/pics/OllyVsX32.png)
Its possible to name the labels to whatever you want, the xAnalyzer plugin does similar to olly, but places them in the comments instead of renaming the labels. Im sure that as its open source it could be adapted to rename the labels instead and have an option in the plugin menu to do that instead of outputting into the comments.
Here is an example of renaming the labels just for completeness and for others, in case they weren't aware of it.
(https://i.postimg.cc/zX2LZV4n/Labelx64dbg.gif)
Wait, JJ: those screenshots you posted: is the top one really OllyDbg? Version 2, I presume?
So how come I don't see any of those variable names (and the comments in the right column), even when I assemble and link with the debug options? I've never seen Olly look like this. Is there some trick I'm missing? If it only did what you show here I'd be as happy as a pig in shit.
Quote from: fearless on October 31, 2022, 06:23:03 AM
Its possible to name the labels to whatever you want
I've named the labels already - in my source. Olly recognises them.
.While 1
inc ebx
deb 4, "loop URLs", ebx
.Break .if !Instr_(ebx, esi, offset txUrlA, 0)
mov ebx, edx
add edx, selStart
dec edx
mov txrg.chrg.cpMin, edx
.Break .if !Instr_(ebx, esi, offset txUrlB, 0)004078B8 |. CC int3
004078B9 |> 43 /inc ebx
004078BA |. 6A 00 |push 0 ; /Arg4 = 0
004078BC |. 68 C45B4200 |push offset txUrlA ; |Arg3 = ASCII "[url="
004078C1 |. 56 |push esi ; |Arg2
004078C2 |. 53 |push ebx ; |Arg1
004078C3 |. E8 22700100 |call InstrCi ; \ReTest.InstrCi
004078C8 |. 85D2 |test edx, edx
004078CA |. 74 75 |jz short 00407941
004078CC |. 8BDA |mov ebx, edx
004078CE |. 0355 EC |add edx, [ebp-14]
004078D1 |. 4A |dec edx
004078D2 |. 8955 E0 |mov [ebp-20], edx
004078D5 |. 6A 00 |push 0 ; /Arg4 = 0
004078D7 |. 68 CA5B4200 |push offset txUrlB ; |Arg3 = ReTest.txUrlB
004078DC |. 56 |push esi ; |Arg2
004078DD |. 53 |push ebx ; |Arg1
004078DE |. E8 07700100 |call InstrCi ; \ReTest.InstrCiQuote from: NoCforMe on October 31, 2022, 07:39:32 AMI've never seen Olly look like this. Is there some trick I'm missing? If it only did what you show here I'd be as happy as a pig in shit.
Options/Options/Analysis/Show recognized...
Options/Options/Debugging/Use debugging data
The latter requires a restart of Olly 2.0 to take effect.
Quote from: jj2007 on October 16, 2022, 01:51:19 AM
Quote from: Shintaro on October 16, 2022, 01:15:42 AMHave you tried Chris Titus Debloater (https://christitus.com/windows-tool/) for Windows 10?
Looks interesting, thanks. Right now I am still on Win7...
JJ what happened to the new computer you got?
@Shintaro that's what lea is for
Princess: Lea strangle jabba the hutt :greenclp: