MASM64 problem with if macro

[hutch--]

 

> Debugger is useless. Just search and read

I have to agree with that comment, long ago there was CodeView in the MASM version 6.0 package and it was a joy to use if you wrote code like the debugger output but over time Microsoft have kept crippling the capacity to use debuggers, mainly for security reasons, and they have become harder to use and more or less toothless in their capacity.

The absolute "bees knees, walk on water" debugger was SoftIce and the crackers truly loved it so NuMega eventually pulled it and Microsoft kept adding more and more security measures to cripple high powered debuggers.

Now a disassembler is another matter, if you have the right toys, you can find you way around a compiled binary reasonably easily but Microsoft have an approach for that as well, the Microsoft Store where anything that you install on your computer gets buried so deep in the quagmire that you cant find it.

[NoCforMe]

But ... you didn't mention Olly Debug. What do you think of that?

I have a few problems with it, the main one being the difficulty of examining local & stack variables, but overall I find it to be a pretty damn useful tool. (But then I've got nothing to compare it to.)

[jj2007]

But ... you didn't mention Olly Debug. What do you think of that?

The alternatives are worse.
- WinDbg is a line-oriented debugger, you never know where you are. It's just plain horrible.
- x64Dbg: https://lifeinhex.com/x64dbg-2-years-later/ (it looks like an OllyDbg clone, but has many problems)

I use OllyDbg 2.0 a lot, but then, I use the deb macro ten times more. Any debugger is a last resort when you really have tried all the other options.

[HSE]

I have to agree with that comment, long ago there was ...

  That is a piece of the problem, because to see what is executed from a 32 bit program you have to debug the WoW, and M$ don't like that. Other piece is that WoW can split the 32 bit program into multiple threads. And finally, look like WoW is very integrated with the system, then you have to see what OS is making to obtain the full picture  (debuggers run in OS, then can't see the OS)

A lot of complications to test if a limited program can be faster than a more complete program, I think 

[hutch--]

Back in the XP days, you could set it up in DrWatson so that a crash would tell you exactly where it crashed down to a listing of instructions. I found it incredibly useful but it disappeared in later Windows versions so my current technique (apart from message Boxes) is a memory mapped file tool called Livedb that you send any data you like to and if the app crashes, LiveDB displays the last line before it crashed.

I don't like current debuggers. I have used Arkdasm and you can get it to step through code but its main use was as a disassembler. I find current debuggers slow and painful.

[jj2007]

Back in the XP days, you could set it up in DrWatson so that a crash would tell you exactly where it crashed down to a listing of instructions ... I find current debuggers slow and painful.

I've set Olly as JIT debugger for 32-bit code, and x64Dbg for 64 bits. That works just fine for the occasional crash.

[daydreamer]

First I write asm proc and use vc debugger to single-step if necessary to get it to work properly, don't know what it's called
To get the right Shuffle or unpack or pack or new right avx2 mnemonics
I tried one disasm once to retrieve my lost source code invain, found out it didn't support SSE

[TimoVJL]

I tried one disasm once to retrieve my lost source code invain, found out it didn't support SSE

Zydis follow time
https://github.com/zyantific/zydis

EDIT:
Online hex code disasm
https://zydis.re/

[jj2007]

I tried one disasm once to retrieve my lost source code invain, found out it didn't support SSE

Olly supports at least SSE 4.2:

Code Select Expand

pcmpistri xmm2, [eax], 0C
pcmpistrm xmm3, xmm1, 58
pcmpeqb xmm0, [edx]
pmovmskb eax, xmm0