Windows 8 new kernel

DispatchXxx routines beginning with "Dispatch" such as DispatchCreate. The other routines are optional, but you may need to implement them depending on your driver type and the location of your driver in the device stack. For more information about standard driver routines, see Introduction to Standard Driver Routines.

Driver support routines are routines that the Windows operating system provides for kernel-mode drivers to use. For the programming guide, see Windows kernel. This section summarizes kernel-mode support routines that can be called by drivers from their DriverEntry, AddDevice, Reinitialize, or Unload routines.

Windows performs resource balancing of PCI bus resources to open an address region for a plugged device. Therefore, a driver must not access the bus data directly.

Instead the driver must pass it down to the lower bus driver because it knows the location of the device. For more information, see Stopping a Device to Rebalance Resources.

Used for obtaining and reporting configuration information, and for registering interfaces in the registry. The Windows power management architecture provides a comprehensive approach to power management supported at the component subdevice level, in addition to the system level and the device level.

Kernel-mode drivers call the PoXxx routines to perform power management for the devices that they control. This section contains the reference pages for these routines. The PoXxx routines are declared in the Wdm. For more information about power management, see Power Management for Windows Drivers. Starting with Windows 8, drivers can divide their device hardware into multiple logical components to enable fine-grained power management. A component has a set of power states that can be managed independently of the power states of other components in the same device.

In the F0 state, the component is fully turned on. The component might support additional, low-power states F1, F2, and so on. The power policy owner for a device is typically the device's function driver.

To enable component-level power management, this driver registers the device with the power management framework PoFx. By registering the device, the driver assumes the responsibility for informing PoFx when a component is actively being used and when the component is idle.

PoFx makes intelligent idle state choices for the device based on information about the component activity, latency tolerance, expected idle durations, and wake requirements. By controlling power usage at the component level, PoFx can reduce power requirements while preserving system responsiveness. For more information, see Component-Level Power Management. This section describes the routines that are implemented by the power management framework PoFx to enable device power management.

These routines are called by the driver that is the power policy owner PPO for a device. Typically, the function driver for a device is the PPO for this device.

Device power management callbacks are the callback routines that are required by the power management framework PoFx to enable device power management. The driver that is the power policy owner for the device implements these callback routines. PoFx calls these routines to query and configure the power states of the components in the device. Device power management DPM notifications.

Processor power management PPM notifications. PPM power control codes. The callback routines are implemented by platform extension plug-ins, and are called by the Windows power management framework PoFx. Some miscellaneous PoFx routines and structures will most likely end up in the power-management section of the Kernel-Mode Driver Architecture doc set.

This section describes the executive library support routines. These routines use the ExXxx naming convention and are listed in alphabetical order. The following executive support routines are reserved for system use. Do not use them in your driver. An IRP is a data structure that contains specific information used to convey the status of an event. This section describes the silo DDIs. These DDIs offer the ability for kernel components to learn about the server silos that are created and destroyed on a machine.

Components register to receive notifications for these events and optionally store state that is associated with each silo. These DDIs provide the ability to assign and retrieve context structures on silo objects.

This allows drivers to attach per-silo information for each silo. These DDIs provide the ability for a driver to receive notifications about silo creation and termination events. The Windows memory manager provides a set of routines that kernel-mode drivers use to allocate and manage memory. These routines have names that begin with the prefix Mm. This section contains reference pages for the MmXxx routines and memory-management macros.

These reference pages are listed in alphabetical order. For an overview of the functionality of these routines and macros, see Memory Allocation and Buffer Management. For an introduction to memory management support for kernel-mode drivers, see Memory Management for Windows Drivers. For more information about memory allocation and buffer management, see Memory Management for Windows Drivers. The short-term buffer management routines are called by kernel-mode drivers to allocate and free temporary buffers.

The long-term buffer management routines are called by kernel-mode drivers to allocate long-term driver-internal buffers. The buffered-data and buffer-initialization routines are called by kernel-mode drivers to manage buffered data or initialize driver-allocated buffers. The address-mapping and MDL-management routines are called by kernel-mode drivers to manage address mappings and memory descriptor lists MDLs.

The buffer- and MDL-management macros are called by kernel-mode drivers to manage buffers and memory descriptor lists MDLs. The pageable-driver routines are called by kernel-mode drivers to lock and unlock a driver's pageable code or data sections, or make an entire driver pageable.

The section- and view-management routines are called by kernel-mode drivers to set up mapped sections and views of memory. These routines are used by drivers to implement Plug and Play PnP support.

For background and task-oriented information about supporting PnP in drivers, see Plug and Play. This section summarizes kernel-mode support routines that drivers can use to interact with Windows Management Instrumentation WMI. A driver's DpWmiXxx routines can have any names that the driver writer chooses. The ZwXxx routines provide a set of system entry points that parallel some of the executive's system services. Calling a ZwXxx routine from kernel-mode code results in a call to the corresponding system service.

Calling a ZwXxx routine from user mode is not supported; instead, native applications applications that bypass the Microsoft Win32 subsystem should call the NtXxx equivalent of the ZwXxx routine. For a call to a ZwXxx routine from a kernel-mode driver, the system does not check the caller's access rights, nor does it set the previous processor mode to UserMode. Before calling a ZwXxx routine, a kernel-mode driver must check all user-supplied parameters for validity.

Kernel-mode drivers should not call NtRenameTransactionManager. They should instead call TmRenameTransactionManager. The Auxiliary Kernel-Mode Library enables drivers to access some system capabilities that are not available from kernel-mode subsystems. Drivers that use this library must call AuxKlibInitialize before calling any of the library's other routines.

Support is available for kernel-mode drivers that use processor groups. The Processor Group ProcGrp compatibility library enables a kernel-mode driver that is written to use processor groups run on earlier versions of Windows, which do not support processor groups.

When this driver runs on, it can take advantage of multiple processor groups, if the hardware platform supports them. When this same driver runs on an earlier version of Windows, it is limited to a single processor group, regardless of the capabilities of the hardware platform. To use the ProcGrp library, the driver must call a library initialization routine.

Additionally, the driver must be compiled for the Windows 7 environment in the WDK, and must be linked with Procgrp. The ProcGrp library is designed to meet the compatibility requirements of drivers that call the following KeXxx routines but must also run on versions of Windows that do not implement these routines:. The ProcGrp library implements wrapper functions for the KeXxx routines in the preceding list.

If the library runs on Windows 7 or Windows Server R2, the wrapper functions simply call the corresponding KeXxx routines. The wrapper functions have the same names as these KeXxx routines, and their behavior is identical to that of the KeXxx routines that they replace. Earlier versions of Windows do not support processor groups and do not implement the KeXxx routines in the preceding list.

If the ProcGrp library is linked to a driver that runs on one of these earlier versions of Windows, the library initialization function, WdmlibProcgrpInitialize, detects that the operating system does not support processor groups. To deal with this case, each wrapper function contains a simplified implementation of the corresponding KeXxx routine. This implementation supports only one processor group, group number 0.

For example, the wrapper function for the KeQueryMaximumGroupCount routine always returns a count of one. KeGetCurrentProcessorNumber is similar to KeGetCurrentProcessorNumberEx, but lacks support for processor groups, which, in this case, has the same effect as supporting just one processor group.

The library functions are declared in the Procgrp. In addition to the KeXxx wrapper functions, the ProcGrp library implements the following function to initialize the library:.

The routines are accessed through pointers and cannot be called directly by name. Be considerate of best practices for kernel mode stack usage. For examples, see How do I keep my driver from running out of kernel-mode stack? For information about functions that copy, concatenate, and format strings in a manner that prevents buffer overrun errors, see Safe String Functions , below.

Other string manipulation functions include the following:. If you use the safe string functions instead of the string manipulation functions that are provided by C-language run-time libraries, you protect your code from buffer overrun errors that can make code untrustworthy.

For more information, see Using Safe String Functions. If you use the safe string functions instead of the string manipulation functions that C-language run-time libraries provide, you protect your code from buffer overrun errors that can make code untrustworthy. For more information about safe string functions, see Using Safe String Functions. This section describes the safe integer functions for drivers. These functions are defined as inline functions in the Ntintsafe.

The safe integer functions are designed to help drivers to avoid arithmetic overflow errors. These functions are divided into two sets; the first converts integer values from one type to another, and the second performs math functions.

For more information about these functions, see Using Safe Integer Functions. The Intsafe. For more information about this version of the safe integer functions, see Intsafe. Skip to main content. This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode. Please rate your experience Yes No. Any additional feedback? Submit and view feedback for This product This page. View all page feedback.

In this article. Obtaining and reporting hardware configuration information about a driver's devices and the current platform. Obtaining and reporting configuration information, and for registering interfaces in the registry. Setting up and freeing the objects and resources that drivers might use. See AllocateCommonBuffer instead.

See FreeCommonBuffer instead. See IoGetDmaAdapter instead. This query request returns a function pointer to GetBusData, which can be used to read from the configuration space of a given device. This query request returns a function pointer to SetBusData, which can be used to write to the configuration space of a given device. Consequently, in most cases there is no need to translate bus addresses.

The query request returns a function pointer to TranslateBusAddress, which can be used to translates addresses on the parent bus to logical addresses. Retrieves device setup information from the registry. Use this routine, rather than accessing the registry directly, to insulate a driver from differences across platforms and from possible changes in the registry structure. Returns a handle to a device-specific or a driver-specific registry key for a particular device instance.

Registers device functionality a device interface that a driver will enable for use by applications or other system components. Enables or disables a previously registered device interface. Applications and other system components can open only interfaces that are enabled. Gives a driver-supplied callback read-only access to the entries for a specified value name, along a specified relative path, in the registry, after the callback routine is given control.

Writes caller-supplied data into the registry along the specified relative path at the given value name. Removes the specified value name and the associated value entries from the registry along the given relative path. Creates a new key in the registry with the given object's attributes, allowed access, and creation options such as whether the key is created again when the system is booted.

Alternatively, opens an existing key and returns a handle for the key object. Returns a handle for a key in the registry given the object's attributes which must include a name for the key and the desired access to the object.

Returns information about the class of a key, and the number and sizes of its subkeys. This information includes, for example, the length of subkey names and the size of value entries. Returns the specified information about the subkey, as selected by a zero-based index, of an opened key in the registry. Returns the specified information about the value entry of a subkey, as selected by a zero-based index, of an opened key in the registry. Releases the handle for an opened object, causing the handle to become invalid and decrementing the reference count of the object handle.

Initializes a device object, which represents a physical, virtual, or logical device for which the driver is being loaded into the system. Then it allocates space for the driver-defined device extension associated with the device object. Requests access to a named device object and returns a pointer to that device object if the requested access is granted.

Also returns a pointer to the file object referenced by the named device object. In effect, this routine establishes a connection between the caller and the next-lower-level driver. Attaches the caller's device object to the highest device object in a chain of drivers and returns a pointer to the previously highest device object. Returns a pointer to the highest level device object in a driver stack and increments the reference count on that object.

Sets the access allowed to a given file object that represents a device. Only highest-level drivers can call this routine. Registers a driver's interrupt-handling routine. Drivers should use IoConnectInterruptEx instead. Drivers can register either an InterruptService routine for line-based interrupts or an InterruptMessageService routine for message-signaled interrupts.

Writes partition tables for a disk, given the device object that represents the disk, the sector size, and a pointer to a buffer containing the drive layout structure. Initializes a controller object representing a physical device controller that is shared by two or more similar devices that have the same driver, and specifies the size of the controller extension.

Initializes a DPC object, setting up a driver-supplied CustomDpc routine that can be called with a given context. Initializes an event object as a synchronization single waiter or notification multiple waiters type event and sets up its initial state Signaled or Not-Signaled. Initializes a fast mutex variable that is used to synchronize mutually exclusive access to a shared resource by a set of threads. Initializes a named notification event to be used to synchronize access between two or more components.

Notification events are not automatically reset. Initializes a named synchronization event to be used to serialize access to hardware between two otherwise unrelated drivers. Creates a kernel-mode thread that is associated with a given process object or with the default system process.

Returns a handle for the thread. Terminates the current thread and satisfies as many waits as possible for the current thread object. Returns an estimate small, medium, or large of the amount of memory available on the current platform. Initializes a lookaside list of nonpaged memory. After a successful initialization, fixed-size blocks can be allocated from and freed to the lookaside list.

Initializes a lookaside list of paged memory. Initializes a resource, for which the caller provides the storage, to be used for synchronization by a set of threads.

Returns a pointer to the object body and handle information attributes and granted access rights , given the handle for an object, the object's type, and a mask. Specifies the desired access to the object and the preferred access mode. A successful call increments the reference count for the object. Increments the reference count for an object so the caller can ensure that the object is not removed from the system while the caller is using it. Releases a reference to an object decrements the reference count , given a pointer to the object body.

Creates or opens a directory object with a specified set of object attributes and requests one or more types of access for the caller. Returns a handle for the directory object. Creates or opens a file object that represents a physical, logical, or virtual device, a directory, a data file, or a volume. Returns a handle for the file object. Resets the "permanent" attribute of an opened object, so that the object and its name can be deleted when the reference count for the object becomes zero.

Releases the handle for an opened object, causing the handle to become invalid, and decrements the reference count of the object handle. An initialized spin lock is a required parameter to the ExXxxInterlockedList routines. Sets up a queue header for a driver's internal queue, given a pointer to driver-supplied storage for the queue header and queue. Initializes a device queue object to a Not Busy state, setting up an associated spin lock for multiprocessor-safe access to device queue entries.

The PoQueryWatchdogTime routine indicates whether the power manager has enabled a watchdog time-out counter for any power IRP that is currently assigned to the device stack. The PoRegisterDeviceForIdleDetection routine enables or cancels idle detection and sets idle time-out values for a device.

The PoRegisterPowerSettingCallback routine registers a power-setting callback routine to receive notifications of changes in the specified power setting. The PoSetDeviceBusyEx routine notifies the power manager that the device associated with the specified idle counter is busy.

The PoSetPowerState routine notifies the system of a change in the device power state for a device. The PoFxActivateComponent routine increments the activation reference count on the specified component. The PoFxCompleteIdleCondition routine informs the power management framework PoFx that the specified component has completed a pending change to the idle condition. The PoFxCompleteIdleState routine informs the power management framework PoFx that the specified component has completed a pending change to an Fx state.

The PoFxIdleComponent routine decrements the activation reference count on the specified component. The PoFxIssueComponentPerfStateChangeMultiple routine submits a request to change the performance states in multiple performance state sets simultaneously for a device component.

The PoFxNotifySurprisePowerOn routine notifies the power management framework PoFx that a device was turned on as a side effect of supplying power to some other device. The PoFxSetComponentLatency routine specifies the maximum latency that can be tolerated in the transition from the idle condition to the active condition in the specified component.

The PoFxSetComponentResidency routine sets the estimated time for how long a component is likely to remain idle after the component enters the idle condition. The PoFxSetComponentWake routine indicates whether the driver arms the specified component to wake whenever the component enters the idle condition. The PoFxSetDeviceIdleTimeout routine specifies the minimum time interval from when the last component of the device enters the idle condition to when the power management framework PoFx calls the driver's DevicePowerNotRequiredCallback routine.

This routine is called to notify the power manager of the device's target device power state for DRIPS. The PoFxStartDevicePowerManagement routine completes the registration of a device with the power management framework PoFx and starts device power management.

The ComponentActiveConditionCallback callback routine notifies the driver that the specified component completed a transition from the idle condition to the active condition. The ComponentIdleConditionCallback callback routine notifies the driver that the specified component completed a transition from the active condition to the idle condition.

The ComponentIdleStateCallback callback routine notifies the driver of a pending change to the Fx power state of the specified component. The ComponentPerfStateCallback callback routine notifies the driver that its request to change the performance state of a component is complete.

The DevicePowerNotRequiredCallback callback routine notifies the device driver that the device is not required to stay in the D0 power state. The DevicePowerRequiredCallback callback routine notifies the device driver that the device must enter and remain in the D0 power state. The PowerControlCallback callback routine performs a power control operation that is requested by the power management framework PoFx. An EnumerateInterruptSource callback routine supplies a platform extension plug-in PEP with information about an interrupt source.

The EnumerateUnmaskedInterrupts routine enumerates interrupt sources whose interrupts are unmasked and enabled. The PlatformIdleVeto routine increments or decrements the veto count for a veto code for a platform idle state. The ProcessorIdleVeto routine increments or decrements the veto count for a veto code for a processor idle state.

The RequestInterrupt routine requests that the operating system replay an edge-triggered interrupt that might have been lost while the hardware platform was in a low-power state. The RequestWorker routine is called by a platform extension plug-in PEP to inform the Windows power management framework PoFx that the platform extension plug-in PEP has a work request to submit on behalf of the specified device.

The UpdatePlatformIdleState routine is called by the platform extension plug-in PEP to update the properties of the specified platform idle state. The UpdateProcessorIdleState routine is called by the platform extension plug-in PEP to update the properties of the specified processor idle state. The ComponentCriticalTransitionCallback callback routine handles a transition of the specified component between the F0 fully on and low-power Fx component power states. The ClfsAlignReservedLog routine calculates the size of the space that must be reserved for a specified set of records.

The size calculation includes the space required for headers and the space required for sector alignment. The ClfsCloseAndResetLogFile routine releases all references to a specified log file object and marks its associated stream for reset. If necessary, ClfsCreateLogFile also creates the underlying physical log that holds the stream's records. The ClfsCreateMarshallingArea routine creates a marshalling area for a CLFS stream and returns a pointer to an opaque context that represents the new marshalling area.

The ClfsLsnCreate routine creates a log sequence number LSN , given a container identifier, a block offset, and a record sequence number. The two LSNs must be from the same stream.

The ClfsReadLogRecord routine reads a target record in a CLFS stream and returns a read context that the caller can use to read the records preceding or following it in the stream. The ClfsReadNextLogRecord routine reads the next record in a sequence, relative to the current record in a read context. The ClfsReadPreviousRestartArea routine reads the previous restart record relative to the current record in a read context. The ClfsReserveAndAppendLog routine reserves space in a marshalling area or appends a record to a marshalling area or does both atomically.

The ClfsReserveAndAppendLogAligned routine reserves space in a marshalling area or appends a record to a marshalling area or does both atomically. The record's data is aligned on specified boundaries. The ClfsSetLogFileInformation routine sets metadata and state information for a specified stream and its underlying physical log. The ClfsTerminateReadLog routine invalidates a specified read context after freeing resources associated with the context.

Registers a driver-supplied IoCompletion routine for an IRP, so the IoCompletion routine is called when the next-lower-level driver has completed the requested operation in one or more of the following ways: successfully, with an error, or by canceling the IRP.

Releases the cancel spin lock when the driver has changed the cancelable state of an IRP or releases the cancel spin lock from the driver's Cancel routine. Writes partition tables for a disk, given the device object representing the disk, the sector size, and a pointer to a buffer containing the drive geometry. Allocates and initializes an error log packet; returns a pointer so that the caller can supply error-log data and call IoWriteErrorLogEntry with the packet.

Queues a previously allocated and filled-in error log packet to the system error logging thread. Supplies the device object for which the given IRP was failed due to a user-induced error, such as supplying the incorrect media for the requested operation or changing the media before the requested operation was completed. A file system driver uses the associated device object to notify the user, who can then correct the error or retry the operation.

Notifies the user that the given IRP was failed on the given device object for an optional VPB, so that the user can correct the error or retry the operation. Raises an error status and causes a caller-supplied structured exception handler to be called. Useful only to highest-level drivers that supply exception handlers, in particular to file systems. Dequeues the next IRP for a device object according to a specified sort-key value, specifies whether the IRP is cancelable, and calls the driver's StartIo routine.

Returns the initial base address of the current thread's stack. Useful only to highest-level drivers. Returns the boundaries of the current thread's stack frame.

A buffer that will contain the data to be read or that contains the data to be written. The length of the buffer in bytes. The starting offset on the media.

Returns a pointer to the IRP so the caller can set any necessary minor function code and set up its IoCompletion routine before sending the IRP to the target driver. An event object to be set to the Signaled state when the requested operation completes.

The stack location must have been allocated by a preceding call to IoAllocateIrp that specified a stack-size argument large enough to give the caller its own stack location. All Comments. Collapse -. Did you check any Win 8 blog posts? Back to Windows Forum. Start or search. Start New Discussion. Create a new discussion If you're asking for technical help, please be sure to include all your system info, including operating system, model number, and any other specifics related to the problem.

Follow the prompted steps. Method 2: Scan the computer for computer viruses. I would suggest you to scan your computer with Microsoft Safety Scanner , which would help to get rid of viruses, spyware, and other malicious software. The Microsoft Safety Scanner is a free-to-download security tool that provides on-demand scanning and helps remove viruses, spyware, and other malicious software.

It works with your existing antivirus software. Note: The Microsoft Safety Scanner expires 10 days after being downloaded. To rerun a scan with the latest anti-malware definitions, download and run the Microsoft Safety Scanner again.

Important: While scanning the hard drive if any bad sectors are found, the scanner tries to repair that sector, any data available on that might be lost. Method 3: Check the hard disk for errors. Refer to the section: To Repair a Drive , in the following link:. Important : Data available on bad sectors might be lost when chkdsk tries to repair your hard disc. Please get back to us with the results and any other questions you might have regarding Windows operating systems.

We are here to assist. Was this reply helpful? Yes No. Sorry this didn't help. Thanks for your feedback.