OS kernels and systems components

Custom driver and system-filter development

Development, porting and stabilization of components below the application layer that determine the reliability of the whole product.

Problems addressed

When the problem reaches the OS kernel

The team lacks kernel expertise

The application team has reached a driver, block layer, file filter or systems API boundary.

Platform implementations diverge

Linux, Windows and macOS versions evolve independently and behave differently.

A defect is hard to reproduce

A crash, race or corruption appears only under load or in a customer environment.

Scope of responsibility

Scope I can take ownership of

  • Linux kernel modules, block devices, device mapper and file systems
  • Windows WDM/WDF/UMDF, storage and file-system filters
  • macOS Endpoint Security and system extensions
  • virtual devices, I/O paths, encryption and event interception
  • WinDbg, crash dumps, race analysis, memory corruption and porting

Diagnostics and stabilization

Driver defects are resolved from evidence, not guesswork

From bugcheck and memory-dump analysis to a reproducible stress test and regression validation.

01

Bugcheck and crash dump

Stack, stop code, faulting instruction, symbols, offsets and root-cause analysis even after system-data corruption.

02

IRQL and memory

Pageable memory at elevated IRQL, invalid pointers, DMA, use-after-free and pool corruption.

03

Resource leaks

Pool tags, PoolMon, uncompleted IRPs, synchronization objects and resources left allocated at unload.

04

Hangs and races

Recursive mutex/spinlock acquisition, lost request completion, interrupt handlers and SMP concurrency.

05

Intermittent defects

Load, low-memory conditions, CPU-speed sensitivity, release-only faults, structure alignment and optimizer differences.

06

Fix validation

Minimal reproducer, Driver Verifier/stress, negative tests and CI regression coverage.

Technical publicationThe article “Debugging Errors in Windows NT Drivers” examines bugchecks, IRQL, pool leaks, uncompleted IRPs, deadlocks and multiprocessor defects in detail.
Debugging Windows driver failures →

First engagement

A practical starting point

3–5 days

Technical assessment

Architecture, risks, bottlenecks and a validation plan.

1–2 weeks

Performance cycle

Baseline, profiling, changes and repeated measurement.

2–4 weeks

Hypothesis validation

A working critical-path prototype and full implementation estimate.

Minimum paid engagement: 3 business days, from RUB 200,000 or the equivalent in another currency. After a short introductory call, scope, deliverables, validation method and price are fixed.

Engagement model

KernelSoft is an independent expert practice

Maxim personally owns architecture, critical code, diagnostics and final technical review. Additional engineers or domain specialists are involved only by customer agreement, with roles and accountability defined in advance.

28+years
60+patents
14years at Acronis
2,400+citations

Discuss the project

Describe the problem, current implementation and target outcome

Include the platform, what already exists, where the problem occurs, the target load and the acceptance criterion. This is enough to choose a sensible first stage and validation method.

Target response time: one business dayNext: a short introduction → an NDA if needed → agreement on the first stage.