What is an Interrupt Vector Table?

Learn what an interrupt vector table is — direct handler dispatch, the x86 IDT, and fallback faults — with OS interview questions answered.

mediumQ182 of 224 in Operating Systems Est. time: 5 minsLast updated: July 2026

Open Code Lab

Expected Interview Answer

An interrupt vector table (IVT) is an array of handler addresses indexed by interrupt or exception number, used by the CPU to jump directly to the correct handler routine the instant an interrupt or trap occurs, without any software lookup.

Each entry in the table corresponds to a specific interrupt number — for example, entry 0 might be the divide-by-zero handler, entry 0x20 a timer interrupt, and entry 0x80 the system-call entry point — and the CPU hardware reads the interrupt number presented by the interrupting device or instruction, multiplies it by the entry size, and jumps straight to the address stored at that offset. On architectures like x86, this table is called the Interrupt Descriptor Table (IDT) and can live anywhere in memory pointed to by a dedicated register (IDTR); the OS populates it once during boot, registering a handler function pointer for every interrupt number it cares about. Because the lookup is a direct array index rather than a search, dispatch is extremely fast and has constant, predictable latency, which matters for real-time responsiveness. If an interrupt number arrives that has no properly initialized entry, or if a fault occurs while already handling another fault, the CPU raises a special fallback such as a double fault or general protection fault to avoid running through garbage memory.

Explains constant-time O(1) interrupt dispatch versus a lookup search
Clarifies why the OS must initialize every vector during boot
Connects to real hardware structures like x86 IDT and the IDTR register
Explains double faults as the fallback for missing/corrupt vector entries

AI Mentor Explanation

An interrupt vector table is like a numbered pigeonhole board at the pavilion where each incident type has a pre-assigned slot: slot 1 always holds the physio's phone number, slot 2 the groundskeeper's, slot 3 the umpire's. When an incident number is announced over the tannoy, staff go straight to that exact pigeonhole rather than searching a directory, giving instant, predictable response every time. If a slot is ever left empty, the club has a fallback emergency contact posted at the entrance, just like a CPU falling back to a double fault handler.

Step-by-Step Explanation

Step 1
Table initialization
During boot, the OS populates every entry it cares about with a handler function pointer, indexed by interrupt/exception number.
Step 2
Register the base
The CPU is told where the table lives, e.g. via the IDTR register on x86 pointing to the Interrupt Descriptor Table.
Step 3
Interrupt occurs
The CPU or a device presents an interrupt number; hardware multiplies it by entry size and indexes directly into the table.
Step 4
Direct jump
Control transfers straight to the address stored at that index — O(1), no software search — or a fallback fault fires if the entry is missing.

What Interviewer Expects

Clear definition: array of handler addresses indexed by interrupt number
Understanding that dispatch is O(1) direct indexing, not a search
Knowledge of a real example, e.g. x86 IDT and the IDTR register
Awareness of the double-fault/fallback path for missing entries

Common Mistakes

Thinking the OS searches a list to find the right handler at runtime
Confusing the interrupt vector table with the page table
Not knowing the OS must initialize the table at boot before interrupts are enabled
Forgetting what happens when an interrupt number has no valid handler entry

Best Answer (HR Friendly)

“An interrupt vector table is essentially a lookup array the operating system fills in ahead of time, one slot per type of interrupt, holding the address of the code that should run for that interrupt. When something happens, the hardware uses the interrupt’s number to jump straight to the right slot instantly, instead of searching for the right code, which keeps response times fast and predictable.”

Code Example

Populating an interrupt vector table at boot

#define NUM_VECTORS 256

typedef void (*isr_handler_t)(void);
isr_handler_t interrupt_vector_table[NUM_VECTORS];

void divide_by_zero_handler(void) { /* handle CPU exception 0 */ }
void timer_handler(void)          { /* handle IRQ0 / vector 0x20 */ }
void syscall_entry(void)          { /* handle software trap 0x80 */ }
void default_fault_handler(void) { /* fallback: unmapped vector */ }

void init_vector_table(void) {
    for (int i = 0; i < NUM_VECTORS; i++)
        interrupt_vector_table[i] = default_fault_handler;

    interrupt_vector_table[0x00] = divide_by_zero_handler;
    interrupt_vector_table[0x20] = timer_handler;
    interrupt_vector_table[0x80] = syscall_entry;

    load_idtr(interrupt_vector_table);   /* tell CPU where table lives */
}

/* Hardware dispatch: O(1) direct index, no search */
void cpu_dispatch(int vector_num) {
    interrupt_vector_table[vector_num]();
}

Follow-up Questions

What is the x86 Interrupt Descriptor Table (IDT) and what does the IDTR register hold?
What happens if an interrupt fires with no handler registered for its vector number?
What is a double fault, and how does it relate to the vector table?
How does the vector table differ from a page table or a system call table?

MCQ Practice

1. What does an interrupt vector table primarily store?

2. Why is dispatch via the interrupt vector table fast?

3. On x86, what CPU register points to the Interrupt Descriptor Table?

Flash Cards

1 / 4

What is an Interrupt Vector Table?

Expected Interview Answer

AI Mentor Explanation

Step-by-Step Explanation

Table initialization

Register the base

Interrupt occurs

Direct jump