In the red corner, EXCEPTION_INT_DIVIDE_BY_ZERO and STATUS_INTEGER_DIVIDE_BY_ZERO; and in the blue corner, EXCEPTION_INT_OVERFLOW and STATUS_INTEGER_OVERFLOW
The exception code
EXCEPTION_INT_DIVIDE_BY_ZERO (and its doppelgänger
STATUS_INTEGER_DIVIDE_BY_ZERO) is raised, naturally enough, when the denominator of an integer division is zero.
The x86 and x64 processors also raise this exception when you divide
-1, or more generally, when the result of a division does not fit in the destination. The division instructions for those processors take a 2N-bit dividend and an N-bit divisor, and they produce N-bit quotient and remainder. Values of N can be 8, 16, and 32; the 64-bit processors also support 64. And the division can be signed or unsigned. Therefore, you can get this exception if you try to divide, say, 2³² by 1, using a 64-bit dividend and 32-bit divisor. The quotient is 2³², which does not fit in a 32-bit divisor.
The Windows 95 kernel does not attempt to distinguish between division overflow and division by zero. It just converts the processor exception to
EXCEPTION_INT_DIVIDE_BY_ZERO and calls it a day.
The Windows NT kernel realizes that the underlying processor exception is ambiguous and tries to figure out why the division operation failed. If the divisor is zero, then the exception is reported as
EXCEPTION_INT_DIVIDE_BY_ZERO. If the divisor is nonzero, then the exception is reported as
Another place that
EXCEPTION_INT_OVERFLOW can arise from a processor exception is if an application issues the
INTO instruction and the overflow flag is set.
IDIV instructions support a divisor in memory. What happens if the memory becomes inaccessible after the processor raises the exception but before the kernel can read the value in order to check whether it is zero? What other things could go wrong?