How the system Finds and Loads Drivers
1. PnP device
It has an electronic signature that bus driver can detect the new hardware
2. Legacy device
Initiate the detection by invoking Add New Hardware Wizard.
In the end, in both PnP and Legacy Device situation, system uses the same automatic registry and INF file process to load the right driver.
Function driver:
It understands the details about how to make the HW work.
It's responsible for initiating IO operations, for handling interrupts, and for provding a way for end user to exersise control over the device.
Bus driver:
It's responsible for managing the connection between the HW and the computer.
Filter Driver:
to Modify the behavior of an existing function driver in some way.Upper filter driver sees IRPs before function driver. Lower filter can modify the stream of bus operations that the function driver is trying to perform.
PDO stands for physical device object. The bus driver uses it to represent the conncetion between the device and the bus.
FDO stands for function devive object. The function driver uses it to manage the functionality of the device.
Installing a PnP Device:
1.Bus driver detects the insertion or removal of hardware.
2.Bus driver calls IoInvalidateDeviceRelations to notify PnP manager that the bus's population of child devices has changed.
3.PnP manager sends IRP_MN_QUERY_DEVICE_RELATIONS to bus driver, to obtain an updated list of the PDOs for the child devices.
4.PnP manager sends IRP_MN_QUERY_ID to bus driver, to obtain Device ID
5.PnP manager locates INF install section and initialize driver. Memory Manager then calls DriverEntry routine.
6.PnP manager calls AddDevice, to inform driver that a new instance of the device hs been discovered
7.PnP manager sends IRP_MN_QUERY_RESOURCE_REQUIREMENTS to bus driver, to ask bus driver report resource requirements.
8.PnP manager configuire the hardware with as set of resource arbitrators to assign resources to the device.
8.PnP manager sends IRP_MN_START_DEVICE to your driver(the driver stack). Function driver handles thei IRP by configuring and connecting various kernel resources.
Order of AddDevice Calls (Driver Loading):
5. Class upper filters
4. Device upper filters
3. function driver
2. Class lower filters
1. Device lower filters
IRP Routing:
System sends an IRP to the topmost filter dirver in the stack, that driver can decide to process the IRP, to pass the IRP down to the next level, or to do both. Each driver that sees the IRP makes the same decision.
9/23/2010
MDL
http://www.osronline.com/article.cfm?id=423
An MDL is a structure that describes the fixed physical memory locations that comprise a contiguous data buffer in virtual memory.
Each MDL can only describe a single virtually contiguous data buffer.
The data buffer that the MDL describes can be in either a kernel virtual address space, user virtual address space, or both.
The MDL describes the data buffer at a fixed position in physical memory. In other words, the data buffer an MDL describes will always be paged in (resident), and its pages will be locked-down ("pinned"). This means the data buffer can neither be paged out nor moved. These pages will remain locked for the lifetime of the MDL.
The data buffer that the MDL describes does not need to be page aligned, nor does it need to be an integral number of pages in length.
//
// An MDL describes pages in a virtual buffer in terms
// of physical pages. The pages associated with the
// buffer are described in an array that is allocated
// just after the MDL header structure itself.
//
// One simply calculates the base of the array by
// adding one to the base MDL pointer:
//
// Pages = (PPFN_NUMBER) (Mdl + 1);
//
// Notice that while in the context of the subject
// thread, the base virtual address of a buffer mapped
// by an MDL may be referenced using the following:
//
// Mdl->StartVa | Mdl->ByteOffset
//
typedef struct _MDL {
struct _MDL *Next;
CSHORT Size;
CSHORT MdlFlags;
struct _EPROCESS *Process;
PVOID MappedSystemVa;
PVOID StartVa;
ULONG ByteCount;
ULONG ByteOffset;
} MDL, *PMDL;
From the comment you know the MDL is actually a variable length structure with an array that contains the underlying physical pages of the address range at the tail. Also you know that StartVa is the page aligned virtual address of the start of the range and ByteOffset is the starting offset into the first page.
Building and using MDLs.
Step1: Allocating the Structure -- use the IoAllocateMdl DDI
Step2:Probing and Locking --- MmProbeAndLockPages DDI
Step3: Mapping
your driver wants a new virtual address for accessing the underlying pages ---MmMapLockedPagesSpecifyCache
you want a kernel virtual address for this MDL---MmGetSystemAddressForMdlSafe macro
An MDL is a structure that describes the fixed physical memory locations that comprise a contiguous data buffer in virtual memory.
Each MDL can only describe a single virtually contiguous data buffer.
The data buffer that the MDL describes can be in either a kernel virtual address space, user virtual address space, or both.
The MDL describes the data buffer at a fixed position in physical memory. In other words, the data buffer an MDL describes will always be paged in (resident), and its pages will be locked-down ("pinned"). This means the data buffer can neither be paged out nor moved. These pages will remain locked for the lifetime of the MDL.
The data buffer that the MDL describes does not need to be page aligned, nor does it need to be an integral number of pages in length.
//
// An MDL describes pages in a virtual buffer in terms
// of physical pages. The pages associated with the
// buffer are described in an array that is allocated
// just after the MDL header structure itself.
//
// One simply calculates the base of the array by
// adding one to the base MDL pointer:
//
// Pages = (PPFN_NUMBER) (Mdl + 1);
//
// Notice that while in the context of the subject
// thread, the base virtual address of a buffer mapped
// by an MDL may be referenced using the following:
//
// Mdl->StartVa | Mdl->ByteOffset
//
typedef struct _MDL {
struct _MDL *Next;
CSHORT Size;
CSHORT MdlFlags;
struct _EPROCESS *Process;
PVOID MappedSystemVa;
PVOID StartVa;
ULONG ByteCount;
ULONG ByteOffset;
} MDL, *PMDL;
From the comment you know the MDL is actually a variable length structure with an array that contains the underlying physical pages of the address range at the tail. Also you know that StartVa is the page aligned virtual address of the start of the range and ByteOffset is the starting offset into the first page.
Building and using MDLs.
Step1: Allocating the Structure -- use the IoAllocateMdl DDI
Step2:Probing and Locking --- MmProbeAndLockPages DDI
Step3: Mapping
your driver wants a new virtual address for accessing the underlying pages ---MmMapLockedPagesSpecifyCache
you want a kernel virtual address for this MDL---MmGetSystemAddressForMdlSafe macro
Win7: Memory Dump
A kernel dump gets created every time a machine has a kernel fault. This dump gets stored in the %systemroot% folder as a memory.dmp file.
(Control Panel > System and Security > System > Advanced system settings > Advanced tab > Startup and Recovery Settings.)
(Control Panel > System and Security > System > Advanced system settings > Advanced tab > Startup and Recovery Settings.)
- No Full Memory Dumps option?
The I/O Manager originally limited the size of a complete memory dump to 2GB, now the fact is Windows support crash dumps larger than 2GB. To workaround this, set \HKLM\System\CCS\Control\CrashControl\CrashDumpEnabled DWORD value to 1 - No memory.dmp generated after crash?
Algorithm to decide whether to store/delete memory.dmp file generated after a system crash:
First report the kernel fault to the Online Crash Analysis Service.
Then, if machine has a registry setting AlwaysKeepMemoryDump set to 1, store the dump file on disk.
Else, if machine is a Windows Server SKU, store the dump file on disk.
Else, if the machine is joined to a domain (i.e. this is a corporate machine), store the dump file on disk.
Else, if machine is not on a domain (i.e. this is a home user’s machine),
If free disk space is >= 25GB, store the dump file on disk.
Else (free disk space is < 25 GB), delete the dump file.
The exact location of the AlwaysKeepMemoryDump setting in the registry is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl ! AlwaysKeepMemoryDump Type: REG_DWORD.
8/03/2010
Make a partition on a RAW USB flash disk.
Briefly, here are the steps:
1. Use CreateFile to open PhysicalDriveX, that is the USB Flash disk
2. IOCTL_DISK_GET_DRIVE_GEOMETRY_EX to get the physical disk's geometry ( we need some information in it to fill partition data)
3. IOCTL_DISK_CREATE_DISK to creates an empty partition.
4. IOCTL_DISK_SET_DRIVE_LAYOUT_EX to repartition a disk as specified.
Note: use IOCTL_DISK_UPDATE_PROPERTIES to synchronize system view after IOCTL_DISK_CREATE_DISK and IOCTL_DISK_SET_DRIVE_LAYOUT_EX.
e.g. a 1GB size flash disk,
pBuf->PartitionEntry[0].PartitionStyle = PARTITION_STYLE_MBR;
pBuf->PartitionEntry[0].StartingOffset.QuadPart = 0x10000;//64KB
pBuf->PartitionEntry[0].PartitionLength.QuadPart = 0x1e200000; //Donot exceed DiskGeo.DiskSize
pBuf->PartitionEntry[0].PartitionNumber = 1;
pBuf->PartitionEntry[0].RewritePartition = TRUE;
pBuf->PartitionEntry[0].Mbr.PartitionType = PARTITION_FAT32;
pBuf->PartitionEntry[0].Mbr.BootIndicator = TRUE;
pBuf->PartitionEntry[0].Mbr.RecognizedPartition = TRUE;
pBuf->PartitionEntry[0].Mbr.HiddenSectors = 0x80; //StartingOffset/(DiskGeo.BytesPerSector) = 0x10000/0x200
1. Use CreateFile to open PhysicalDriveX, that is the USB Flash disk
2. IOCTL_DISK_GET_DRIVE_GEOMETRY_EX to get the physical disk's geometry ( we need some information in it to fill partition data)
3. IOCTL_DISK_CREATE_DISK to creates an empty partition.
4. IOCTL_DISK_SET_DRIVE_LAYOUT_EX to repartition a disk as specified.
Note: use IOCTL_DISK_UPDATE_PROPERTIES to synchronize system view after IOCTL_DISK_CREATE_DISK and IOCTL_DISK_SET_DRIVE_LAYOUT_EX.
e.g. a 1GB size flash disk,
pBuf->PartitionEntry[0].PartitionStyle = PARTITION_STYLE_MBR;
pBuf->PartitionEntry[0].StartingOffset.QuadPart = 0x10000;//64KB
pBuf->PartitionEntry[0].PartitionLength.QuadPart = 0x1e200000; //Donot exceed DiskGeo.DiskSize
pBuf->PartitionEntry[0].PartitionNumber = 1;
pBuf->PartitionEntry[0].RewritePartition = TRUE;
pBuf->PartitionEntry[0].Mbr.PartitionType = PARTITION_FAT32;
pBuf->PartitionEntry[0].Mbr.BootIndicator = TRUE;
pBuf->PartitionEntry[0].Mbr.RecognizedPartition = TRUE;
pBuf->PartitionEntry[0].Mbr.HiddenSectors = 0x80; //StartingOffset/(DiskGeo.BytesPerSector) = 0x10000/0x200
Removal Policy for a Device
http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/Designing%20Hardware%20for%20Surprise%20Removal_v8.doc
http://msdn.microsoft.com/en-us/library/ff551967(VS.85).aspx
Removal Scenarios for Devices
1.Orderly-Removal Scenarios
2.Surprise-Removal Scenarios
Removal-related device capabilities that are relevant to this include SurpriseRemovalOK and Removable.
1.Removable. This capability is set by the bus driver for the bus on which a given device is installed.
2.SurpriseRemovalOK. This capability is set by the driver for the device. It specifies whether the device can be safely removed without using the Safely Remove Hardware applet.
3.If both Removable and SurpriseRemovalOK are set, the device can be removed without using the applet. If Removable is TRUE, the device is displayed in the Safely Remove Hardware applet unless SurpriseRemovalOK is also set to TRUE.
Windows XP has the following removal policy options:
1.ExpectNoRemoval.
2.ExpectOrderlyRemoval
3.ExpectSurpriseRemoval
The operating system uses the following algorithm to determine removal policy defaults:
1.The bus driver sets the Removable device capability according to the operating system default for the device. ACPI BIOS can override the Removable capability by using the _RMV method.
2.If the device is determined to be removable, the operating system checks to see if there is an INF override for removal policy.
3.If no INF override is provided, Windows checks IEEE 1394 devices for any override value in the configuration ROM.
4.In the absence of either an INF or hardware override, Windows bases the removal policy on the bus of the removable device. USB,IEEE1394,PCMCIA---ExpectSurpriseRemoval. Others---ExpectOrderlyRemoval
Override Removal Policy in a Device INF File
[DDInstall.NT] <-- Replace DDInstall with the name of the install section for the device ; Contains CopyFiles and other directives
http://msdn.microsoft.com/en-us/library/ff551967(VS.85).aspx
Removal Scenarios for Devices
1.Orderly-Removal Scenarios
2.Surprise-Removal Scenarios
Removal-related device capabilities that are relevant to this include SurpriseRemovalOK and Removable.
1.Removable. This capability is set by the bus driver for the bus on which a given device is installed.
2.SurpriseRemovalOK. This capability is set by the driver for the device. It specifies whether the device can be safely removed without using the Safely Remove Hardware applet.
3.If both Removable and SurpriseRemovalOK are set, the device can be removed without using the applet. If Removable is TRUE, the device is displayed in the Safely Remove Hardware applet unless SurpriseRemovalOK is also set to TRUE.
Windows XP has the following removal policy options:
1.ExpectNoRemoval.
2.ExpectOrderlyRemoval
3.ExpectSurpriseRemoval
The operating system uses the following algorithm to determine removal policy defaults:
1.The bus driver sets the Removable device capability according to the operating system default for the device. ACPI BIOS can override the Removable capability by using the _RMV method.
2.If the device is determined to be removable, the operating system checks to see if there is an INF override for removal policy.
3.If no INF override is provided, Windows checks IEEE 1394 devices for any override value in the configuration ROM.
4.In the absence of either an INF or hardware override, Windows bases the removal policy on the bus of the removable device. USB,IEEE1394,PCMCIA---ExpectSurpriseRemoval. Others---ExpectOrderlyRemoval
Override Removal Policy in a Device INF File
[DDInstall.NT] <-- Replace DDInstall with the name of the install section for the device ; Contains CopyFiles and other directives
[DDInstall.NT.Services]
; Contains AddService directive to install driver
[DDInstall.NT.HW]
; Contains AddReg/DelReg sections to manage hardware-specific registry settings
AddReg=DDInstall_AddReg_HW_Removal_Policy
[DDInstall_AddReg_HW_Removal_Policy]
HKR,,"RemovalPolicy",0x00010001,Policy <--- See legend below for Policy values
The Policy value can be one of the following:
• Policy = 2 - ExpectOrderlyRemoval. The user will rarely remove the device, or will initiate removal only through software or hardware.
• Policy = 3 - ExpectSurpriseRemoval. The user will regularly remove the device with no warning to the operating system.
Override Removal Policy in a Device INF File (
SetupDiGetDeviceRegistryProperty
SetupDiSetDeviceRegistryProperty (SPDRP_REMOVAL_POLICY is reserved for use by the operating system and cannot be used in the Property parameter)
SPDRP_REMOVAL_POLICY
(Windows XP and later) The function retrieves the device's current removal policy as a DWORD that contains one of the CM_REMOVAL_POLICY_Xxx values that are defined in Cfgmgr32.h.
SPDRP_REMOVAL_POLICY_HW_DEFAULT
(Windows XP and later) The function retrieves the device's hardware-specified default removal policy as a DWORD that contains one of the CM_REMOVAL_POLICY_Xxx values that are defined in Cfgmgr32.h.
SPDRP_REMOVAL_POLICY_OVERRIDE
(Windows XP and later) The function retrieves the device's override removal policy (if it exists) from the registry, as a DWORD that contains one of the CM_REMOVAL_POLICY_Xxx values that are defined in Cfgmgr32.h.
7/29/2010
USB Event Tracking (ETW log in USB Core Stack)
Background:
=========
Event Tracing for Windows (ETW)
In Windows 7, ETW provides an event logging mechanism that the USB driver stack can exploit to aid in investigating, diagnosing, and debugging USB-related issues.
USB Core Stack
The USB host controller driver layer includes the host controller port driver (usbport.sys) and the miniport drivers (usbehci.sys, usbohci.sys, and usbuhci.sys). The USB hub driver layer consists of the USB hub driver (usbhub.sys).
Using USB ETW
============
Capture a USB event trace: logman
1. In the command-prompt window, enter the following two commands to begin the trace:
Logman start Usbtrace -p Microsoft-Windows-USB-USBPORT -o usbtrace.etl -ets -nb 128 640 -bs 128
Logman update Usbtrace -p Microsoft-Windows-USB-USBHUB -ets
After each of these commands completes, Logman should display the following message:
“The command completed successfully.”
2. Perform the steps in your USB device usage scenario.
3. Stop USB hub and port event collection by running the following command:
Logman stop Usbtrace –ets
Analyze an event trace log to troubleshoot a failure: netmon
Capture a system event trace and analyze timing or performance issues: Xperf
Using Xperf with USB ETW
1. start
Xperf –on Diag
Logman start Usbtrace -p Microsoft-Windows-USB-USBPORT -o usbtrace.etl -ets -nb 128 640 -bs 128
Logman update Usbtrace -p Microsoft-Windows-USB-USBHUB –ets
2.stop
Logman stop Usbtrace -ets
Xperf –stop
3. merge
Xperf –merge usbtrace.etl C:\kernel.etl merged.etl
Reference:
=======
http://blogs.msdn.com/b/usbcoreblog/archive/2010/03/17/new-whitepaper-on-usb-event-tracing.aspx
http://www.microsoft.com/whdc/connect/usb/Event-Tracing.mspx
=========
Event Tracing for Windows (ETW)
In Windows 7, ETW provides an event logging mechanism that the USB driver stack can exploit to aid in investigating, diagnosing, and debugging USB-related issues.
USB Core Stack
The USB host controller driver layer includes the host controller port driver (usbport.sys) and the miniport drivers (usbehci.sys, usbohci.sys, and usbuhci.sys). The USB hub driver layer consists of the USB hub driver (usbhub.sys).
Using USB ETW
============
Capture a USB event trace: logman
1. In the command-prompt window, enter the following two commands to begin the trace:
Logman start Usbtrace -p Microsoft-Windows-USB-USBPORT -o usbtrace.etl -ets -nb 128 640 -bs 128
Logman update Usbtrace -p Microsoft-Windows-USB-USBHUB -ets
After each of these commands completes, Logman should display the following message:
“The command completed successfully.”
2. Perform the steps in your USB device usage scenario.
3. Stop USB hub and port event collection by running the following command:
Logman stop Usbtrace –ets
Analyze an event trace log to troubleshoot a failure: netmon
Capture a system event trace and analyze timing or performance issues: Xperf
Using Xperf with USB ETW
1. start
Xperf –on Diag
Logman start Usbtrace -p Microsoft-Windows-USB-USBPORT -o usbtrace.etl -ets -nb 128 640 -bs 128
Logman update Usbtrace -p Microsoft-Windows-USB-USBHUB –ets
2.stop
Logman stop Usbtrace -ets
Xperf –stop
3. merge
Xperf –merge usbtrace.etl C:\kernel.etl merged.etl
Reference:
=======
http://blogs.msdn.com/b/usbcoreblog/archive/2010/03/17/new-whitepaper-on-usb-event-tracing.aspx
http://www.microsoft.com/whdc/connect/usb/Event-Tracing.mspx
7/28/2010
unsigned IM(passthru) driver cannot bind to newly installed NIC
1. unsigned IM(passthru) driver cannot bind to newly installed NIC
2. Uninstall a NIC in Device Manager, and re-scan hardware to re-insall it.
Unsigned IM(passthru) driver won't bind to the new NIC.
root cause:
This is by design on XP.
Check setupapi.log, see the miniport driver server-side installation is blocked because of lack of driver signature.
========
#-011 Installing section [PassthruMP.ndi] from "c:\windows\inf\oem17.inf".
#E358 An unsigned or incorrectly signed file "c:\windows\inf\oem17.inf" for driver "Passthru Miniport" blocked (server install). Error 1168: Element not found.
#E122 Device install failed. Error 1168: Element not found.
=======
Solution:
Get WHQL signature or use test sign when testing.
Server side Install http://msdn.microsoft.com/en-us/library/ff541322(VS.85).aspx
Kernel-Mode Code Signing Walkthrough （http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx）
2. Uninstall a NIC in Device Manager, and re-scan hardware to re-insall it.
Unsigned IM(passthru) driver won't bind to the new NIC.
root cause:
This is by design on XP.
Check setupapi.log, see the miniport driver server-side installation is blocked because of lack of driver signature.
========
#-011 Installing section [PassthruMP.ndi] from "c:\windows\inf\oem17.inf".
#E358 An unsigned or incorrectly signed file "c:\windows\inf\oem17.inf" for driver "Passthru Miniport" blocked (server install). Error 1168: Element not found.
#E122 Device install failed. Error 1168: Element not found.
=======
Solution:
Get WHQL signature or use test sign when testing.
Server side Install http://msdn.microsoft.com/en-us/library/ff541322(VS.85).aspx
Kernel-Mode Code Signing Walkthrough （http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx）
Subscribe to:
Posts (Atom)