Each kernel-mode driver is constructed around a set of system-defined, standard driver routines. Kernel-mode drivers process I\/O request packets<\/em>\u00a0(IRPs) within these standard routines by calling system-supplied driver support routines.<\/p>\n

All drivers, regardless of their level in a chain of attached drivers, must have a basic set of standard routines in order to process IRPs. Whether a driver must implement additional standard routines depends on whether the driver controls a physical device or is layered over a physical device driver, as well as on the nature of the underlying physical device. Lowest-level drivers that control physical devices have more required routines than higher-level drivers, which typically pass IRPs to a lower driver for processing.<\/p>\n

Standard driver routines can be divided into two groups: those that each kernel-mode driver must have, and those that are optional, depending on the driver type and location in the\u00a0device stack<\/em>.<\/p>\n

The following table lists required standard routines.<\/p>\n\n\n\n\n\n\n\n\n

Required routines<\/th>\n	Purpose<\/th>\n	Where described<\/th>\n<\/tr>\n<\/thead>\n
DriverEntry<\/strong><\/td>\n	Initializes the driver and its driver object.<\/td>\n	Writing a DriverEntry Routine<\/td>\n<\/tr>\n
AddDevice<\/em><\/td>\n	Initializes devices and creates device objects.<\/td>\n	Writing an AddDevice Routine<\/td>\n<\/tr>\n
Dispatch Routines<\/td>\n	Receive and process IRPs.<\/td>\n	Writing Dispatch Routines<\/td>\n<\/tr>\n
Unload<\/em><\/td>\n	Release system resources acquired by the driver.<\/td>\n	Writing an Unload Routine<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Each driver must have a\u00a0DriverEntry<\/strong><\/a>\u00a0routine, which initializes driver-wide data structures and resources. The I\/O manager calls the\u00a0DriverEntry<\/strong> routine when it loads the driver. A\u00a0DriverEntry<\/strong>\u00a0routine returns an\u00a0NTSTATUS value<\/a>, either STATUS_SUCCESS or an appropriate error status.<\/p>\n The current IRP and target device object are input parameters to many standard routines. Every driver processes each IRP in stages through its set of standard routines.<\/p>\n By convention, the system-supplied drivers prepend an identifying, driver-specific or device-specific prefix to the name of every standard routine except DriverEntry. As an example, this documentation uses “DD”, as shown in the illustration in Introduction to Driver Objects. Following this convention makes it easier to debug and maintain drivers.<\/p>\n","protected":false},"excerpt":{"rendered":" Each kernel-mode driver is constructed around a set of system-defined, standard driver routines. Kernel-mode drivers process I\/O request packets\u00a0(IRPs) within these standard routines by calling system-supplied driver support routines. All drivers, regardless of their level in a chain of attached… Continue Reading →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-537","page","type-page","status-publish","hentry"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/efmsoft.com\/wp-json\/wp\/v2\/pages\/537","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/efmsoft.com\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/efmsoft.com\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/efmsoft.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/efmsoft.com\/wp-json\/wp\/v2\/comments?post=537"}],"version-history":[{"count":4,"href":"https:\/\/efmsoft.com\/wp-json\/wp\/v2\/pages\/537\/revisions"}],"predecessor-version":[{"id":571,"href":"https:\/\/efmsoft.com\/wp-json\/wp\/v2\/pages\/537\/revisions\/571"}],"wp:attachment":[{"href":"https:\/\/efmsoft.com\/wp-json\/wp\/v2\/media?parent=537"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}