  ``` Here is the scoop on DIV (your definition is quite convoluted): Since we are dividing, you the computer expects that the operation will create a smaller value that what it started with, (there is some problems with this assumption, like divinde by 1).. but non the less, the cpu works this way... So.. if your dividing 16 bits by a 8 bit value, expect 8 bit answer, with an 8 bit remainer. In this case, AX is the 16 source, and the answer is then copied over the source with AL holding the answer, and AH holding the remainder. Likewise, if your dividing a 32 bit source by 16 bits, it will use DX as the upper 16 bit source, AX as the lower 16 bit source, and divide the equivelant 32bit number by a 16 value, producing a 16 bit answer in AX, and a 16 bit remainder in DX. The newer .386 intruction set provides for a 32 bit divisor as well, using EDX as the upper 32 bits, and EAX as the lower 32bits of a 64 bit source, and it is divided by 32 bits to produce a 32 answer in EAX and remainder in EDX. Hopefully this paints a better picture. The thing to remember about all this, is the CPU only realizes the type of source to consider by the size of the divisor. Your source has: div DelayMilli Where delaymilli is defined as a Double 32 bits, so this would imply that the upper 32bits to use is EDX and lower is EAX. Since GetTickCount will return a DWORD in eax, there is no guarentees that EDX will remain unchanged (M\$ lazyness). So odds are, the invoke you called will fill EDX with some random 32 bit number, compounded with the tick-count in EAX, will make a very big 64 number to be divided by a relatively small 32 bit number (1000).. If the divisor is too small, the answer will outgrow the size of the destination register (32 bits) and cause a divide overflow error (a fatal error which will cause the program to crash). If your still following all this, i would try adding this line: invoke GetTickCount mov edx, 0 ; format upper 32 bits of 64 bit source div DelayMilli ... Or... By the same logic, scale down your divsor data type.. 1000 out of 4 Gig is small. At least 16 bits are 0's, you can easily fit 1000 in a word (16 bits), however, DX will still be used, and thus you will still need to format it to ensure no errors (it may not cause a divide overflow in this case, but you could still have faulty answers if dx is allowed to hold a non zero value).. [Another Fix] DelayMilli dw 1000 invoke GetTickCount mov edx, 0 ; format DX div DelayMilli ... Well that was much longer than first intended... Hope it helps.. NaN ```