Major Function Table

What a major function table does

The major function table is the dispatch map inside a Windows driver object. Each entry corresponds to an IRP major function code, so the operating system can route a request, such as create, read, write, or device control, to the correct driver routine. It is a core part of how kernel-mode I/O gets organised and processed.

This table is not a policy layer or a user-facing interface. It is an execution map that determines which routine runs when the I/O manager presents a particular request class to the driver.

Why it matters in driver architecture

The table defines the driver’s request-handling surface. If a major function code points to the wrong routine, a request may be rejected, mishandled, or processed in an unintended way. In practice, this means the table is central to correctness, stability, and the driver’s ability to behave consistently across different I/O paths.

Because the operating system consults this array on every relevant request, it also helps define what the driver can actually do. A driver that leaves a handler unimplemented, or routes a function to a generic fallback, may still load but will not necessarily support the full set of I/O operations that callers expect.

How request dispatch works

When an I/O request packet arrives, the kernel checks the major function code and uses it as an index into the driver object’s table. The entry found there is the routine that receives the request for processing. That design keeps dispatch fast and explicit, rather than forcing the driver to inspect every request in a single monolithic handler.

In Windows driver development, this mechanism is closely tied to the driver’s contract with the I/O manager. Each handler is responsible for one class of operation, and the table is how those responsibilities are registered. This makes the major function table a structural part of the driver object, not just an implementation detail.

Common implementation implications

For developers, the main practical issue is coverage. A driver should populate the entries for the request types it supports and decide deliberately how to handle the rest. Unhandled paths should be treated as an explicit design choice, not an accidental omission, because missing dispatch entries can create compatibility problems or unexpected failure modes.

The table also matters for maintainability. When a driver grows to support more I/O classes, the dispatch map becomes the place where that growth is reflected. Keeping it accurate helps make the driver’s behaviour easier to reason about during debugging, testing, and code review.

Risk and Threat Considerations

Misconfigured dispatch tables can create reliability and security exposure in kernel code. If the wrong routine is mapped, or if a request path reaches code that was not written to handle it safely, the result can be denial of service, incorrect device behaviour, or in the worst case a memory-safety failure in a privileged execution context.

Failure mechanism: An attacker or buggy caller may trigger an I/O path that exercises an unexpected handler, or a missing validation branch, causing the driver to process input in an unsafe state or fail in a way that disrupts the system.

Impact: The outcome can include crashes, device malfunction, privilege-relevant bugs in kernel mode, or a larger attack surface if the driver exposes sensitive operations through an unintended dispatch path.

Practitioner Guidance

What to watch for: Treat each major function entry as an explicit security-relevant decision, not just a wiring task. Review whether the routine assigned to each supported IRP class actually enforces the checks, state transitions, and error handling that that request type requires.

Practitioner takeaway: A small dispatch table can have outsized consequences, because every kernel I/O path depends on it being accurate, complete, and aligned with the driver’s real behaviour.

Related resources from NHI Mgmt Group

• When does a leaked secret become a major business risk?
• Should IAM teams re-evaluate their NHI tooling choices after a major acquisition?
• When does a compromised developer package become a major security risk?
• What is the difference between function calling and MCP for enterprise security?