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