Drivers and Process Address Spaces
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/28/2008
Windows Embedded CE–based device drivers run in one of the system process address spaces. This architecture affects your device driver development whenever you want to share chained data structures between an application and a device driver.
You should run drivers in user mode and use the VirtualAlloc and VirtualCopy functions instead of kernel mode addresses when mapping hardware registers.
In Windows Embedded CE 6.0, each process occupies the lower 2 gigabytes (GB) of the 4 GB of virtual memory address space. The lower 2 GB of virtual memory address space is unique to each process. There is a limit of about 32,000 processes due to the number of handles that can be created. When compared to earlier versions of Windows Embedded CE, the memory for each process in CE 6.0 is not limited to 32 megabytes (MB), and the number of processes is not limited to 32. For more information, see Processes.
Threads migrate between process slots during system calls. For example, if a thread calls ExtEscape, the thread's context is switched into nk.exe. Then, if the display driver's ExtEscape implementation calls DeviceIoControl, the same thread migrates into Device Manager. When the thread is executing in the driver's IOCTL code, the application is the owner process, nk.exe is the caller process, and Device Manager is the current process. For more information, see GetCurrentProcessId, GetCallerProcess, and GetOwnerProcess.
Windows Embedded CE defines the 0x80000000 to 0x9FFFFFFF statically mapped virtual address range as cached and the 0xA0000000 to 0xBFFFFFFF statically mapped virtual address range as uncached. These addresses are only valid in kernel mode. Drivers should not use these addresses, and drivers should not allow applications to pass in kernel mode addresses. For more information, see OEMAddressTable.
Use the IsBadReadPtr, IsBadWritePtr, and IsBadCodePtr functions with caution in driver entry points. These functions tell you only if your thread can access a particular address while executing in the context of Device Manager. Because the IOControl entry point executes in kernel mode, kernel mode addresses are valid, as well as addresses in other processes with threads executing code in Device Manager. For example, if another application was blocked waiting on data in the serial port, and a malicious program passed a virtual address into the application's address space, these functions would not catch the security violation. To prevent this, Device Manager implicitly calls MapCallerPtr.
Even if you do not load a driver in kernel mode, and the driver does not directly use kernel mode addresses, the OS executes the driver's entry points in kernel mode because they are an implementation of system calls.
See Also
Concepts
Accessing Memory from a Driver