On Windows, how would you decide whether new functionality — say, intercepting or instrumenting file I/O — belongs in a kernel-mode driver or a user-mode component, and what does choosing kernel mode commit you to?

## Frame the decision as "what is impossible in user mode?" The answer that impresses is not a preference for one mode; it is a disciplined elimination. Kernel mode is the place with no isolation, no second chances and the heaviest deployment obligations, so it should be entered only for capabilities that genuinely do not exist above the line. Capabilities that usually *do* exist in user mode: - **Observation.** Event Tracing for Windows exposes process, thread, image-load, registry and file activity to a consuming service, with the kernel doing the collection. If you only need to know what happened, you rarely need to be a driver. - **Policy at an API boundary.** Many controls can be applied where the operation is requested rather than where it is serviced. - **Hardware access through an existing stack.** If a class driver already exposes the device, a user-mode component talking to it is enough. Capabilities that require kernel mode: - **Being in the path, synchronously, with authority to fail or transform an operation.** A file system filter driver sees the request before the file system does, may modify or block it, and does so for every process on the machine including ones that started before you did. No user-mode hook has that reach or that authority — a user-mode hook is per-process, evadable and racy. - **Servicing new hardware or a new bus** for which no stack exists. - **Work at raised IRQL** — the timing-critical part of interrupt handling. ## What kernel mode commits you to **No fault isolation.** There is one kernel address space. A stray write does not raise an access violation inside your component; it corrupts someone else's data structures and the machine bugchecks, possibly minutes later and somewhere unrelated. Diagnosis is crash-dump analysis, not a stack trace in your log. **IRQL and pool discipline.** Kernel code runs at an interrupt request level, and the rules at raised IRQL are strict: at `DISPATCH_LEVEL` you may not touch pageable memory and you may not block on a dispatcher object, because the scheduler itself is unavailable to you. Allocations must come from the right pool — non-paged memory for anything touched at raised IRQL — and a pool leak in a driver is a machine-wide resource leak that survives every process restart. None of this has an equivalent in user-mode programming, and it is where most first-time driver bugs live. **Loading is a privilege granted by signing.** A kernel-mode driver must be signed to load on modern 64-bit Windows, so you take on certificate management and a submission process, and you must remain compatible with hypervisor-enforced code integrity where it is enabled. "Just ship a hotfix" is not available the way it is for a user-mode service. **Servicing coupling.** You now live inside the OS's release cadence. Kernel structures and driver interfaces evolve, and each feature update is a compatibility test event. A user-mode service consuming documented APIs simply does not carry that risk at the same magnitude. **Blast radius owns your support cost.** When your driver is on a fleet and a bugcheck spike appears after an update, you are the prime suspect regardless of fault, because kernel code is what stops machines. ## The middle grounds A good senior answer stops at "driver or service"; a good principal answer names the hybrids: - **User-mode driver framework components.** For many device classes a driver can run in user mode, gaining crash isolation and easier debugging at the cost of some performance and some capability. Where the class supports it, that is often the right default. - **Thin kernel collector, thick user-mode brain.** Put the smallest possible amount of logic in the kernel — only the part that must be in the path — and ship everything analytical, updatable and risky to a user-mode service. Your parsing, your policy language, your network client and your update mechanism have no business in kernel memory, and keeping them out means a bug in them cannot bugcheck a customer. - **Supported filtering frameworks rather than bespoke hooking.** Where the platform offers an extensibility point — a file system filter framework with managed ordering, or the network filtering platform — use it. The framework handles ordering, teardown and unload semantics that hand-rolled interception gets wrong. ## How to state the decision Say what capability forces kernel mode, say how little of the system will live there, and say how you will contain the risk: staged rollout gated on crash telemetry, verifier-driven testing before shipping, a kill switch that disables enforcement without a driver update, and a boundary drawn so that most of your change velocity happens in user-mode code you can roll back without a reboot.