Statistics crashing updating resource allocation
Another way in which an errant driver may crash the system is when a driver frees pooled memory allocated thereto, but then later writes to it after the memory has been reallocated to another component, corrupting the other component's information.
This may lead to a crash in which the other component appears responsible.
Other kernel component errors involve lists of resources maintained by the kernel to facilitate driver operations, and the failure of the driver to properly delete its listed information when no longer needed.
For example, a driver may request that the kernel keep timers for regularly generating events therefor, or create lookaside lists, which are fixed-sized blocks of pooled memory that can be used by a driver without the overhead of searching the pool for a matching size block, and thus are fast and efficient for repeated use.
For example, if two related components are relying on each other to deallocate the space, but neither component actually does deallocate it, a memory leak results.
Memory leaks can be difficult to detect, as they slowly degrade machine performance until an out-of-memory error occurs.
For example, one way in which a kernel component can cause a system crash is related to the way in which pooled memory is arranged and used.
The driver verifier may also provide extreme memory pressure on a specific driver, or randomly fail requests for pool memory.
The driver verifier also checks call parameters for violations, performs checks to ensure a driver cleans up timers when deallocating memory and cleans up memory and other resources when unloaded.
A driver may also fail to delete pending deferred procedure calls (DPCs), worker threads, queues and other resources that will cause problems when the driver unloads.
Moreover, even when still loaded, the driver should delete items when no longer needed, e.g., a timer maintained by the kernel for a driver may cause a write to a block of memory no longer allocated to the driver.