If you've seen INT_DIVIDE_BY_ZERO in a crash report, or watched your app vanish with an "integer division by zero" error, you've hit one of the more abrupt failures in native code. There's no graceful exception to catch, no warning. The CPU is asked to do something mathematically impossible, and the operating system kills the process on the spot.

Here's what's actually happening, how to find the line responsible, and one wrinkle that trips up a lot of people: sometimes the bug isn't in your code at all.

What a divide by zero crash actually is

Dividing a number by zero is undefined. Not "returns a weird value," but genuinely undefined, so the hardware has no answer to give. When an integer division instruction hits a zero divisor, the CPU raises an exception, and on most systems the OS responds by terminating the program immediately. On Windows you'll see it surface as EXCEPTION_INT_DIVIDE_BY_ZERO; in an Unreal crash it often shows up as INT_DIVIDE_BY_ZERO.

One thing worth knowing: integer and floating-point division behave differently here. Integer divide-by-zero crashes hard, as described. Floating-point division by zero usually doesn't crash at all, it produces special values like infinity or NaN, which then quietly poison your math downstream and cause a different, often weirder bug somewhere else. The hard crash you're chasing is almost always the integer kind.

How to identify the culprit

The crash is abrupt, but it's also one of the easier ones to pin down once you have the right data, because the cause is specific: some divisor was zero when it shouldn't have been.

The stack trace gets you to the function and line where the division happened. That's necessary but not sufficient, because the line result = total / count; doesn't tell you why count was zero. What you need is the value of the variables at the moment of the crash. If you can see that count was 0 right there in the report, you're done, that's your root cause. From there it's a matter of working backward: where does count come from, and what path let it reach the division as zero?

Common sources, in rough order of how often they bite:

  • A count or length that came back empty. You divided by the size of a collection that turned out to have no elements.
  • An uninitialized or default-zero value. A variable that was supposed to be set never got assigned, so it sat at zero.
  • A value from outside your control. Config, user input, a network response, or a file that supplied a zero you didn't expect.
  • A modulo operation. % is division too, so x % 0 crashes the same way and is easy to forget.

The fix is almost always a guard before the division: check for zero, and decide what should happen when it is, rather than letting the CPU decide for you.

The wrinkle: sometimes it's not your code

This is the part that sends developers in circles, and it's worth knowing before you spend a day blaming a division you can't find a fault in.

Starting in 2024, a wave of INT_DIVIDE_BY_ZERO and similar crashes turned out to be caused not by software at all, but by a hardware instability problem in certain Intel 13th and 14th generation desktop processors. Intel determined that elevated operating voltage is causing instability in some of those chips, stemming from a microcode issue, and the degradation it caused could be permanent. The symptom on the developer's side was maddening: crashes like divide-by-zero and memory-access errors firing in code that was provably correct, often only on a subset of users.

The practical lesson isn't the Intel specifics, which Intel has since addressed with microcode and BIOS updates. It's this: if you're seeing a divide-by-zero crash in code that genuinely cannot divide by zero, and it clusters on particular hardware, the bug may be under the chip, not in your source. That's only diagnosable if your crash reports tell you what hardware each crash came from.

How crash reporting makes this easy

Both halves of that, finding the zero divisor and spotting the hardware pattern, come down to having the right data attached to every crash.

A good crash reporter hands you the symbolicated stack trace so you land on the exact line, the local variables and function arguments so you can see which value was zero without reproducing anything, and the environment details (CPU, OS, driver versions) so a hardware-correlated pattern actually becomes visible instead of looking like random noise. It also groups identical crashes together, so "we have 4,000 crashes" becomes "we have one divide-by-zero defect hitting 4,000 users," which is the version you can actually act on.

Without that, you're stuck reproducing an intermittent crash locally and guessing which variable went wrong. With it, the report usually tells you on sight.

That's the kind of data BugSplat captures for native C++ crashes, divide-by-zero included: the stack, the variable values at the crash site, and the hardware each report came from. If you want to see it on your own crashes, you can start for free and submit a test crash to take a look.

Either way: when a divide-by-zero hits, don't guess. Find the zero, check whether it clusters on specific hardware, and add the guard. That's the whole job.