while debugging, how do you locate a specific set of instructions within the code? let's say there are some 1000 lines of code we have written.. in that i want to debug only code from 600 .. 610 .. one option is to introduce int3 at 599 ... but is there any other better way?

my challenge is how do we identify these 600 .. 610 when we debug our code in a debugger (for example x64dbg) ... because, the moment I open the code in debugger, it's difficult to locate the section of code i want to debug ...

int3 works fine for me.

If you just want to "identify" the code section you can add some dummy "markers" you can search for in debugger, like:

I also find an infinite loop useful when I just want to attach a debugger later to a complicated app that, say, loads your plugin:

in case if we want to find out the values of all the registers (eax, ebx, ecx, edx, esi, edi) ... what kind of tricks you use to find out the values to debug?

i use " invoke, printf "%x", eax

is there a better way?

It depends what you want to achive..
Think about:

If your debugger supports it you could view general registers in ymm0 in format you want.. 64/32 bit floats, dword /word integers..
Of course I assume in this case - you hold integers in general registers...

I think the debugger is a better way to find out the register values.
Just use INT3 opcode at some point and the debugger will 'break' there and show you the values.

Some programmers like to create their own instrumentation like this with the printf(), or creation of log files to initially narrow down a problem scope. There are cases where a debugger is not available, and the printf() techniques are quite valuable.

My personal strategy is to jump into a good debugger. I like looking at instructions - something similar to the code I'm writing. Modern debuggers offer so many features to accelerate navigation, restart a line of discovery, document research, and automate strategies.

The best approach often depends on the complexity of the code, the tools available, and the nature of the bug. Some issues might be more easily solved by looking at log files, while others require the detailed inspection capabilities of a debugger.

In fasmg we have some super simple debug techniques: ... because fasm[g] interprets 0x80+ bytes as symbol characters, I just pick a single UTF-8 character -- checkmark, box, etc. -- and make a simple macro to pepper around where I think the error is happening, or to see which way the code is flowing. Then I can just run it and look at the debugger log - "Oh, that's the direction it went before it crashed." fasmg works particularly well for this because of how it processes the source - there are less conflicts between different parts of the process. Regardless of whatever abstractions I'm using it just works. I'm sure a comparable fasm macro is possible. It's just a lazy way to catch strange typos or API misuse.

Of course, it's possible to prepend __FILE__, __LINE__ to the debug message of this macro.