User-Mode Drivers Registry Settings
On Windows Embedded CE 6.0, you can run multiple user-mode drivers in a single host process or have multiple host processes enabled on the system. Drivers grouped in a single Udevice.exe instance share the same process space, which is particularly useful for drivers that depend on each other. However, drivers in the same process space can affect each other's stability. For example, if a user-mode driver causes the host process to fail, all drivers in that host process fail. The system continues to function except for the affected drivers and applications accessing these drivers, yet it is possible to recover from this situation by reloading the drivers, if the applications support it. If you isolate a critical driver in a separate user mode driver host process, you can increase the overall system stability. By using the registry entries listed in Table 6-5, you can define individual host process groups.
Table 6-5 Registry entries for user-mode driver host processes
| Registry Entry | Type | Description |
|---|---|---|
| HKEY_LOCAL_MACHINEDriversProcGroup_### | REG_KEY | Defines a three-digit group ID (###) for a user-mode driver host process, such as ProcGroup_003, which you can then specify in the UserProcGroup entry in a driver's registry key, such as UserProcGroup=3. |
| ProcName | REG_SZ | The process that the Reflector service starts to host the user-mode driver, such as ProcName=Udevice.exe. |
| ProcVolPrefix | REG_SZ | Specifies the file system volume that the Reflector service mounts for the user-mode driver host process, such as ProcVolPrefix=$udevice. The specified ProcVolPrefix replaces the $device volume in driver device names. |
Having defined the desired host process groups, you can associate each user-mode driver with a particular group by adding the UserProcGroup registry entry to the device driver's registry subkey (see Table 6-3 earlier in this lesson). By default, the UserProcGroup registry entry does not exist, which corresponds to a configuration in which Device Manager loads every user-mode driver into a separate host process instance.
Binary Image Builder Configuration
As explained in Chapter 2, 'Building and Deploying a Run-Time Image,' the Windows Embedded CE build process relies on binary image builder (.bib) files to generate the content of the run-time image and to define the final memory layout of the device. Among other things, you can specify a combination of flags for a driver's module definition. Issues can arise if .bib file settings and registry entries do not match for a device driver. For example, if you specify the K flag for a device driver module in a .bib file and also set the DEVFLAGS_LOAD_AS_USERPROC flag in the driver's registry subkey to load the driver into the user-mode driver host process, the driver fails to load because the K flag instructs Romimage.exe to load the module in kernel space above the memory address 0x80000000. To load a driver in user mode, be sure to load the module into user space below 0x80000000, such as into the NK memory region defined in the Config.bib file for the BSP.The following .bib file entry demonstrates how to load a user-mode driver into the NK memory region:
driver.dll $(_FLATRELEASEDIR)driver.dll NK SHQ
The S and H flags indicate that Driver.dll is both a system file and a hidden file, located in the flat release directory. The Q flag specifies that the system can load this module concurrently into both kernel and user space. It adds two copies of the DLL to the run-time image, one with and one without the K flag, and doubles in this way ROM and RAM space requirements for the driver. Use the Q flag sparingly.
Extending the above example, the Q flag is equivalent to the following:
driver.dll $(_FLATRELEASEDIR)driver.dll NK SH
driver.dll $(_FLATRELEASEDIR)driver.dll NK SHK
Lesson Summary
Windows Embedded CE can load drivers into kernel space or user space. Drivers running in kernel space have access to system APIs and kernel memory and can affect the stability of the system if failures occur. However, properly implemented kernel- mode drivers exhibit better performance than user-mode drivers, due to reduced context switching between kernel and user mode. On the other hand, the advantage of user-mode drivers is that failures primarily affect the current user-mode process. User-mode drivers are also less privileged, which can be an important aspect in respect to non-trusted drivers from third-party vendors.
To integrate a driver running in user mode with Device Manager running in kernel mode, Device Manager uses a Reflector service that loads the driver in a user-mode driver host process and forwards the stream function calls and return values between the driver and Device Manager. In this way, applications can continue to use familiar file system APIs to access the driver, and the driver does not need code changes regarding the stream interface API to remain compatible with Device Manager. By default, user-mode drivers run in separate host processes, but you can also configure host process groups and associate drivers with these groups by adding a corresponding UserProcGroup registry entry to a driver's registry subkey. Driver subkeys can reside in any registry location, yet if you want to load the drivers at boot time automatically, you must place the subkeys into Device Manager's RootKey, which by default is HKEY_LOCAL_MACHINEDriversBuiltIn. Drivers that have their subkeys in different locations can be loaded on demand by calling the ActivateDeviceEx function.
Lesson 4: Implementing an Interrupt Mechanism in a Device Driver
Interrupts are notifications generated either in hardware or software to inform the CPU that an event has
