How big are your numbers?
"div" is tricky in that the operands you don't see depend on the one operand you provide. Dividing by a byte...
div bl
; or
div byte [somenumber]
divides ax by bl (or somenumber) and puts the quotient in al and the remainder in ah. If the quotient won't fit in al (if ah >= bl), it raises an exception. This exception is sometimes reported as "divide by zero error" or "floating point error". Very helpful! (not) Chances are, you want zero in ah before the "div". Some other sane value - less than bl - is okay, but remember that the CPU cares what's in ah, even if you don't. After the "div", the remainder is in ah. Check it any way you like - "cmp ah, 0", "test ah, ah", "or ah, ah"...
Dividing by a word is similar. "div" divides dx:ax (dx * 64k + ax) by bx (or whatever) and puts the quotient in ax and the remainder in dx. Again, if the quotient won't fit in ax - exception! Check dx for the remainder.
By a dword, "div" divides edx:eax (edx * 4G + eax) by ebx (or whatever) and puts the quotient in eax and the remainder in edx. As you're probably beginning to suspect, if it won't fit, go boom.
I ASSume it's the same deal dividing a 128-bit number by a 64-bit number, but I haven't tried it. Takes too long to check the result.
So the "trick" is to pay attention to what "div" is dividing by what. The registers you want to be zero (or some sane value) before the "div" are the same ones you'll be checking after the "div" for the remainder - ah, dx, edx... rdx? Depending on how big your numbers are...
Best,
Frank