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.
Showing posts with label WDK. Show all posts
Showing posts with label WDK. Show all posts
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/27/2009
WDF Logo Requirements Regarding Coinstallers
http://blogs.msdn.com/iliast/archive/2009/08/13/wdf-logo-requirements-regarding-coinstallers.aspx
The current situation (in WLK 1.4) for WHQL-signing is:
Win7 + WDF 1.9: No coinstaller restrictions. This means that you can use any WDF 1.9 coinstaller (beta, RC, RTM, intermediate builds, etc) or you can use no coinstaller. Since the coinstaller is not used to update a Win7 system, we wanted to allow driver submissions before Win7 RTMed, so this is a temporary policy. Now that the WDF 1.9 RTM coinstallers are out, it is suggested that you use those. We might update WLK 1.4 with a QFE to make the usage of the RTM coinstallers mandatory.
Win7 + WDF 1.0-1.7: You can use either an RTM coinstaller or no coinstaller
Windows 2000-Vista + WDF 1.0-1.9: You can use any RTM WDF coinstaller or no coinstaller (of course, you need to make sure that the needed version of WDF is already inbox if you don't submit a coinstaller)
After WLK 1.5 comes out (October 2009) the WHQL-signing situation will be:
For all operating systems and all versions of WDF (1.0 - 1.9) you can use either an RTM coinstaller or no coinstaller (if you don't submit a coinstaller, then the same restrictions as above will apply).
The current situation (in WLK 1.4) for WHQL-signing is:
Win7 + WDF 1.9: No coinstaller restrictions. This means that you can use any WDF 1.9 coinstaller (beta, RC, RTM, intermediate builds, etc) or you can use no coinstaller. Since the coinstaller is not used to update a Win7 system, we wanted to allow driver submissions before Win7 RTMed, so this is a temporary policy. Now that the WDF 1.9 RTM coinstallers are out, it is suggested that you use those. We might update WLK 1.4 with a QFE to make the usage of the RTM coinstallers mandatory.
Win7 + WDF 1.0-1.7: You can use either an RTM coinstaller or no coinstaller
Windows 2000-Vista + WDF 1.0-1.9: You can use any RTM WDF coinstaller or no coinstaller (of course, you need to make sure that the needed version of WDF is already inbox if you don't submit a coinstaller)
After WLK 1.5 comes out (October 2009) the WHQL-signing situation will be:
For all operating systems and all versions of WDF (1.0 - 1.9) you can use either an RTM coinstaller or no coinstaller (if you don't submit a coinstaller, then the same restrictions as above will apply).
8/19/2009
USB Port busy, or not
It seems no APIs or interfaces to get the status of a USB Port (working or idle).
As workarounds, it may work to force reflush cache by unmounting and re-mounting volume or remove and rescan usb key device.
1. Flush disk cache by unmounting and re-mounting volume
2. Devcon remove "USB\VID_XXXX&PID_XXXX" and then "devcon rescan"
8/18/2009
Windows Auto-Sleep
1. Application Power Management Best Practices for Windows Vista
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/PM_apps.mspx
Sleep Idle Timeout
If a system has been idle longer than the sleep idle timeout in the power policy, Windows automatically places the system in the sleep state. Windows uses both user input and processor usage to determine if a system is idle and tracks this information over time.
Generally, applications must prevent the system from entering the sleep state while applications are performing a background task or undertaking an operation that the user expects the system to continue until the operation is complete. Applications might need to prevent the sleep idle timeout in the following scenarios:
· A media application that displays full-screen content or visualizations
· Background applications such as hard disk defragmentation or antivirus utilities while a system scan is in progress
· A media application that records television content
· An application or service that streams content to other devices on the network
· An application such as a Web browser while downloading large files from the internet or network
· Applications that synchronize content to another device or computer
When preventing the sleep idle timeout in their applications, developers must exercise caution because the user expects the system to idle to sleep if it is enabled in power policy. Therefore, applications should prevent the sleep idle timeout only when absolutely necessary.
2. System Sleep Criteria: System Sleep Criteria:
http://msdn.microsoft.com/en-us/library/aa373233%20(VS.85).aspx
If a system has been idle longer than the sleep idle timeout in the power policy, Windows automatically places the system in the sleep state. Windows uses both user input and processor usage to determine if a system is idle and tracks this information over time.
3. Windows Auto-sleepAuto-sleep is supposed to happen during periods of inactivity. It works with system idle timer.As long as the system determines that there is user or application activity, it will not enter sleep. The system can detect certain activities, such as user input or network communications. Windows takes consider many things to determine system is idle(inactive), including
· There is no user input.
· CPU and disk utilization levels.
· The system is not running on battery power.
· No presentation program, such as a slide show or a movie player, is running.
· Things going on in the background
· If you are connected to a broadband connection, that can be picked up as possible network activity
· Audio channel not open
· Modem device not in use
· Others
http://www.microsoft.com/whdc/system/pnppwr/powermgmt/PM_apps.mspx
Sleep Idle Timeout
If a system has been idle longer than the sleep idle timeout in the power policy, Windows automatically places the system in the sleep state. Windows uses both user input and processor usage to determine if a system is idle and tracks this information over time.
Generally, applications must prevent the system from entering the sleep state while applications are performing a background task or undertaking an operation that the user expects the system to continue until the operation is complete. Applications might need to prevent the sleep idle timeout in the following scenarios:
· A media application that displays full-screen content or visualizations
· Background applications such as hard disk defragmentation or antivirus utilities while a system scan is in progress
· A media application that records television content
· An application or service that streams content to other devices on the network
· An application such as a Web browser while downloading large files from the internet or network
· Applications that synchronize content to another device or computer
When preventing the sleep idle timeout in their applications, developers must exercise caution because the user expects the system to idle to sleep if it is enabled in power policy. Therefore, applications should prevent the sleep idle timeout only when absolutely necessary.
2. System Sleep Criteria: System Sleep Criteria:
http://msdn.microsoft.com/en-us/library/aa373233%20(VS.85).aspx
If a system has been idle longer than the sleep idle timeout in the power policy, Windows automatically places the system in the sleep state. Windows uses both user input and processor usage to determine if a system is idle and tracks this information over time.
3. Windows Auto-sleepAuto-sleep is supposed to happen during periods of inactivity. It works with system idle timer.As long as the system determines that there is user or application activity, it will not enter sleep. The system can detect certain activities, such as user input or network communications. Windows takes consider many things to determine system is idle(inactive), including
· There is no user input.
· CPU and disk utilization levels.
· The system is not running on battery power.
· No presentation program, such as a slide show or a movie player, is running.
· Things going on in the background
· If you are connected to a broadband connection, that can be picked up as possible network activity
· Audio channel not open
· Modem device not in use
· Others
6/23/2009
Safely Remove Hardware
1. Invoke the Safely Remove Hardware Dialog:
RunDll32.exe shell32.dll,Control_RunDLL hotplug.dll
2. First issue CM_Query_And_Remove_SubTree on the device node, and then follow up with CM_Request_Device_Eject on the device node. Note: use the device node for the USB storage device enumerated by the USB hub, not the volume device enumerated via USBSTOR.
Approach overview1. Open the device via the drive letter (\\.\d:) and issue a IOCTL_MOUNTDEV_QUERY_UNIQUE_ID to obtain the unique ID for the device.2. Use the SetupDi calls to enumerate all mounted devices. Open each device (via the interfaces) and issue IOCTL_MOUNTDEV_QUERY_UNIQUE_ID calls to find the mounted device that has a matching unique ID.3. Use the SetupDi calls to obtain the device node ID for the matching device. This can then be used by the CM_ calls to initiate a safe removal operation.Details1. Use CreateFile to open the drive ("\\.\d:"). Use FILE_SHARE_READ FILE_SHARE_WRITE and GENERIC_READ.2. Issue IOCTL_MOUNTDEV_QUERY_UNIQUE_ID with an output buffer size of sizeof(MOUNTDEV_UNIQUE_ID). The request will fail, but will return a copy of the MOUNTDEV_UNIQUE_ID structure with the UniqueIdLength field filled in. Check the count of bytes returned (should be >= sizeof MOUNTDEV_UNIQUE_ID) to be sure that the required buffer size was returned.3. Allocate a new buffer of size sizeof(MOUNTDEV_UNIQUE_ID) plus the value of UniqueIdLength returned by the previous call.4. Issue IOCTL_MOUNTDEV_QUERY_UNIQUE_ID with the new output buffer and size. The call should succeed.5. Call SetupDiGetClassDevs( &MOUNTDEV_MOUNTED_DEVICE_GUID, NULL, NULL, DIGCF_DEVICEINTERFACE) to obtain a device info object representing mounted storage devices.6. Repeatedly call SetupDiEnumDeviceInterfaces( dev_info, NULL, &MOUNTDEV_MOUNTED_DEVICE_GUID, index, &interface_data) to examine each interface.a. Call SetupDiGetDeviceInterfaceDetail to obtain the interface detail, including a device path that can be passed to CreateFile.b. Use CreateFile to open the device (interface_detail->DevicePath).c. Issue IOCTL_MOUNTDEV_QUERY_UNIQUE_ID with an output buffer size of sizeof(MOUNTDEV_UNIQUE_ID). The request will fail, but will return a copy of the MOUNTDEV_UNIQUE_ID structure with the UniqueIdLength field filled in. Check the count of bytes returned (should be >= sizeof MOUNTDEV_UNIQUE_ID) to be sure that the required buffer size was returned.d. Allocate a new buffer of size sizeof(MOUNTDEV_UNIQUE_ID) plus the value of UniqueIdLength returned by the previous call.e. Issue IOCTL_MOUNTDEV_QUERY_UNIQUE_ID with the new output buffer and size. The call should succeed.f. Compare the unique ID of the device with the unique ID found in step 4. If they match, we found the SetupDi device instance equivalent of the drive letter.7. Call SetupDiGetDeviceInstanceId to obtain the device instance ID of the device, which can then be used in calls to the CM_ APIs.Additional items1. When initiating a safe removal for a USB storage device, the removal should be done for the root of the device, which generally seems to be of class "USB" (as opposed to USB store). The function CM_Get_DevNode_Registry_Property can be used to query the device class. If the device is not of class USB, then navigate to the parent using CM_Get_Parent. When a device instance of class "USB" is reached, that can be used as the target for a safe removal operation.2. Alternatively, rather than checking device classes, the app can check for known good hardware IDs or compatible IDs, and keep walking up the tree until it finds one it can work with.
RunDll32.exe shell32.dll,Control_RunDLL hotplug.dll
2. First issue CM_Query_And_Remove_SubTree on the device node, and then follow up with CM_Request_Device_Eject on the device node. Note: use the device node for the USB storage device enumerated by the USB hub, not the volume device enumerated via USBSTOR.
Approach overview1. Open the device via the drive letter (\\.\d:) and issue a IOCTL_MOUNTDEV_QUERY_UNIQUE_ID to obtain the unique ID for the device.2. Use the SetupDi calls to enumerate all mounted devices. Open each device (via the interfaces) and issue IOCTL_MOUNTDEV_QUERY_UNIQUE_ID calls to find the mounted device that has a matching unique ID.3. Use the SetupDi calls to obtain the device node ID for the matching device. This can then be used by the CM_ calls to initiate a safe removal operation.Details1. Use CreateFile to open the drive ("\\.\d:"). Use FILE_SHARE_READ FILE_SHARE_WRITE and GENERIC_READ.2. Issue IOCTL_MOUNTDEV_QUERY_UNIQUE_ID with an output buffer size of sizeof(MOUNTDEV_UNIQUE_ID). The request will fail, but will return a copy of the MOUNTDEV_UNIQUE_ID structure with the UniqueIdLength field filled in. Check the count of bytes returned (should be >= sizeof MOUNTDEV_UNIQUE_ID) to be sure that the required buffer size was returned.3. Allocate a new buffer of size sizeof(MOUNTDEV_UNIQUE_ID) plus the value of UniqueIdLength returned by the previous call.4. Issue IOCTL_MOUNTDEV_QUERY_UNIQUE_ID with the new output buffer and size. The call should succeed.5. Call SetupDiGetClassDevs( &MOUNTDEV_MOUNTED_DEVICE_GUID, NULL, NULL, DIGCF_DEVICEINTERFACE) to obtain a device info object representing mounted storage devices.6. Repeatedly call SetupDiEnumDeviceInterfaces( dev_info, NULL, &MOUNTDEV_MOUNTED_DEVICE_GUID, index, &interface_data) to examine each interface.a. Call SetupDiGetDeviceInterfaceDetail to obtain the interface detail, including a device path that can be passed to CreateFile.b. Use CreateFile to open the device (interface_detail->DevicePath).c. Issue IOCTL_MOUNTDEV_QUERY_UNIQUE_ID with an output buffer size of sizeof(MOUNTDEV_UNIQUE_ID). The request will fail, but will return a copy of the MOUNTDEV_UNIQUE_ID structure with the UniqueIdLength field filled in. Check the count of bytes returned (should be >= sizeof MOUNTDEV_UNIQUE_ID) to be sure that the required buffer size was returned.d. Allocate a new buffer of size sizeof(MOUNTDEV_UNIQUE_ID) plus the value of UniqueIdLength returned by the previous call.e. Issue IOCTL_MOUNTDEV_QUERY_UNIQUE_ID with the new output buffer and size. The call should succeed.f. Compare the unique ID of the device with the unique ID found in step 4. If they match, we found the SetupDi device instance equivalent of the drive letter.7. Call SetupDiGetDeviceInstanceId to obtain the device instance ID of the device, which can then be used in calls to the CM_ APIs.Additional items1. When initiating a safe removal for a USB storage device, the removal should be done for the root of the device, which generally seems to be of class "USB" (as opposed to USB store). The function CM_Get_DevNode_Registry_Property can be used to query the device class. If the device is not of class USB, then navigate to the parent using CM_Get_Parent. When a device instance of class "USB" is reached, that can be used as the target for a safe removal operation.2. Alternatively, rather than checking device classes, the app can check for known good hardware IDs or compatible IDs, and keep walking up the tree until it finds one it can work with.
5/31/2009
Test an unsigned driver on Vista 64
The recommendation is test-sign your driver...
Installing an Unsigned Driver during Development and Test
http://msdn.microsoft.com/en-us/library/aa906338.aspx
By default, 64-bit versions of Windows Vista and later versions of Windows will load a kernel-mode driver only if the kernel can verify the driver signature. However, this default behavior can be disabled to facilitate early driver development and non-automated testing. Developers can use one of the following mechanisms to temporarily disable load-time enforcement of a valid driver signature. However, to fully automate testing of a driver that is installed by Plug and Play (PnP), the catalog file of the driver must be signed. Signing the driver is required because Windows Vista and later versions of Windows display a driver signing dialog box for unsigned drivers that require a system administrator to authorize the installation of the driver. This PnP driver installation behavior cannot be disabled on Windows Vista and later versions of Windows.
How to work-around to install and load unsigned driver on Vista64?
1. To install unsigned dirver.
gpedit.msc -> User Configuration -> Administrative Templates -> System -> Driver Installation
->Code signing for device drivers.
2. To disable load-time signature enforcement for a kernel mode driver.
Installing an Unsigned Driver during Development and Test
http://msdn.microsoft.com/en-us/library/aa906338.aspx
By default, 64-bit versions of Windows Vista and later versions of Windows will load a kernel-mode driver only if the kernel can verify the driver signature. However, this default behavior can be disabled to facilitate early driver development and non-automated testing. Developers can use one of the following mechanisms to temporarily disable load-time enforcement of a valid driver signature. However, to fully automate testing of a driver that is installed by Plug and Play (PnP), the catalog file of the driver must be signed. Signing the driver is required because Windows Vista and later versions of Windows display a driver signing dialog box for unsigned drivers that require a system administrator to authorize the installation of the driver. This PnP driver installation behavior cannot be disabled on Windows Vista and later versions of Windows.
How to work-around to install and load unsigned driver on Vista64?
1. To install unsigned dirver.
gpedit.msc -> User Configuration -> Administrative Templates -> System -> Driver Installation
->Code signing for device drivers.
2. To disable load-time signature enforcement for a kernel mode driver.
- Use F8 Advanced Boot Option. This setting does not persist across system restarts
- Attach a Kernel Debugger to Disable Signature Verification
5/11/2009
Test Unit Ready (TUR)
The SCSI Test Unit Ready command is used to determine if a device is ready to transfer data (read/write). The device will then return either good status or a check condition
SCSI communication takes place between an initiator and a target. The initiator sends a command to the target which then responds. SCSI commands are sent in a Command Descriptor Block (CDB). At the end of the command the target returns a Status Code byte which is usually 00h for success, 02h for a Check Condition (error), or 08h for busy.
When the target returns a Check Condition in response to a command, the initiator usually then issues a SCSI Request Sense command in order to obtain more information.
http://support.microsoft.com/kb/842411
To check the status of a backup device, Plug and Play sends a Test Unit Ready request to the device every second
4/27/2009
How to remove phantom/ghost devices
- What is phantom devices
Hidden, inactive deives, ghost devices. When a device is physically removed from a machine, the driver becomes a phantom and is no longer visible in Device Manager. Normally this is desirable, but can be a problem if you wish to remove the device driver.
- How to identify and remove phantom devices in device manager (manually)?
do the following:
1. From the command prompt on the problem media server, run:C:\>set devmgr_show_nonpresent_devices=1C:\>start devmgmt.msc
2. Then, select View from the drop down and select to Show Hidden Devices.At this point, any ghost tape devices will be seen with lighter, transparent icon and can be removed. This is done by right-clicking the ghost tape device and selecting "Uninstall".
- How to do this programming...
devcon command works!
Find * FindAll * Remove "@hwid"
Here is a script works...
4/14/2009
To ignore a device's serial number
http://www.lvr.com/usbfaq.htm
During device testing, we attach many devices that are identical except for the serial numbers. How can I prevent Windows from asking to install a new driver every time a device is attached?
This method causes Windows 2000 and XP to ignore a device's serial number. It's recommended for test environments only.
This registry key controls whether Windows uses or ignores device serial numbers:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags]
It's possible to ignore all serial numbers, though this approach is NOT recommended. To ignore all serial numbers, in the above key, change this value to zero:
GlobalDisableSerNumGen = 1
To ignore the serial number for an individual device, create an entry under the above ...\UsbFlags key. The name must
start with "IgnoreHWSerNum" followed by the vendor and product ID of the device. A value of 1 = disable the serial number.
Example (Vendor ID = 0925h, Product ID = 016Ah):
IgnoreHWSerNum0925016A= 1
During device testing, we attach many devices that are identical except for the serial numbers. How can I prevent Windows from asking to install a new driver every time a device is attached?
This method causes Windows 2000 and XP to ignore a device's serial number. It's recommended for test environments only.
This registry key controls whether Windows uses or ignores device serial numbers:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags]
It's possible to ignore all serial numbers, though this approach is NOT recommended. To ignore all serial numbers, in the above key, change this value to zero:
GlobalDisableSerNumGen = 1
To ignore the serial number for an individual device, create an entry under the above ...\UsbFlags key. The name must
start with "IgnoreHWSerNum" followed by the vendor and product ID of the device. A value of 1 = disable the serial number.
Example (Vendor ID = 0925h, Product ID = 016Ah):
IgnoreHWSerNum0925016A= 1
2/09/2009
MaximumTransferSize is oboslete after Win2000
MaximumTransferSize member of the USBD_PIPE_INFORMATION structure is obsolete after Win2000. Systems after win2000 don't care about this value anyway.The USB stack ignores the value in MaximumTransferSize for both composite and non-composite devices, this values will be set to the default.The default values of MaximumTransferSize under Vista are listed below.
1. http://msdn.microsoft.com/en-us/library/ms790486.aspx
2. http://msdn.microsoft.com/en-us/library/ms793357.aspx
1. http://msdn.microsoft.com/en-us/library/ms790486.aspx
2. http://msdn.microsoft.com/en-us/library/ms793357.aspx
2/03/2009
"CTS" is not supported by USBSer.sys?
The usbser.sys assumes that the device has always signaled CTS.
The RTS/CTS hardware handshaking is not implemented in usbser.sys.
The RTS/CTS hardware handshaking is not implemented in usbser.sys.
1/05/2009
Layered Driver Architecture
http://msdn.microsoft.com/en-us/library/ms791644.aspx
Layered Driver Architecture
Windows operating systems support a layered driver architecture. Every device is serviced by a chain of drivers, typically called a driver stack. Each driver in the stack isolates some hardware-dependent features from the drivers above it.
The following figure shows the types of drivers that could potentially be in a driver stack for a hypothetical device. In reality, few (if any) driver stacks contain all these types of drivers.
Layered Driver Architecture
As the preceding figure shows:
Above the driver stack is an application. The application handles requests from users and other applications, and calls either the Win32 API or a routine that is exposed by the user-mode client driver.
A user-mode client driver handles requests from applications or from the Win32 API. For requests that require kernel-mode services, the user-mode client driver calls the Win32 API, which calls the appropriate kernel-mode client or support routine to carry out the request. User-mode client drivers are usually implemented as dynamic-link libraries (DLL). Printers support many operations that can be performed in user mode, and so typically have user-mode clients; disks and other storage devices, networks, and input devices do not.
A kernel-mode client driver handles requests similar to those handled by the user-mode client, except that these requests are carried out in kernel mode, rather than in user mode.
A device class and miniclass driver pair provides the bulk of the device-specific support. The class driver supplies system-required but hardware-independent support for a particular class of device. Class drivers are typically supplied by Microsoft.
A miniclass driver handles operations for a specific type of device of a particular class. For example, the battery class driver supports common operations for any battery, while a miniclass driver for a vendor's UPS device handles details unique to that particular device. Miniclass drivers are typically supplied by hardware vendors.
A corresponding port driver (for some devices, this is a host controller or host adapter driver) supports required I/O operations on an underlying port, hub, or other physical device through which the device attaches. Whether any such drivers are present depends on the type of device and the bus to which it eventually connects.
All driver stacks for storage devices have a port driver. For example, the SCSI port driver provides support for I/O over the SCSI bus.
For USB devices, a hub and host controller driver pair perform the duties of the port driver. These drivers handle I/O between the devices on the USB bus and the bus itself.
A corresponding miniport driver handles device-specific operations for the port driver. For most types of devices, the port driver is supplied with the operating system, and the miniport driver is supplied by the device vendor.
At the bottom of the figure is the hardware bus driver. Microsoft supplies bus drivers for all the major buses as part of the operating system. You should not attempt to replace these drivers.
Network drivers have their own unique terminology, defined in Windows 2000 and Later Network Architecture and the OSI Model. Nevertheless, network drivers are similarly layered, and each layer isolates device-specific or protocol-specific functionality from the layer above it.
Exactly which drivers are present, and what they are called, depends on the type of device and the bus to which it connects.
Graphics cards, for example, require a display driver, a video port driver, and a video miniport driver. The display driver is analogous to the kernel-mode client driver in the previous figure. It provides general drawing capabilities and can often work with more than one graphics card. The video port driver supports device-independent graphics operations. It works in tandem with the video miniport driver, which provides functionality that is specific to one graphics card (or a family of graphics cards). The paired video port/miniport drivers are analogous to the port/miniport drivers in the figure, and no class/miniclass drivers are present. For more information, see Display Architecture.
For simplicity, filter drivers are not shown in the previous figure. However, a filter driver can fit in at any layer of the driver stack above the hardware bus driver. A filter driver adds value to an existing driver by "filtering" — intercepting and manipulating device I/O. As a general rule, filter drivers do not operate the hardware directly, but work only on data and I/O requests passed to them from the next-higher or next-lower driver.
DirectShow, the Microsoft software for video capture, includes system-supplied filter drivers that run in user mode. These filters act as clients of the kernel-mode stream class driver to expose the underlying video capture technology.
Layered Driver Architecture
Windows operating systems support a layered driver architecture. Every device is serviced by a chain of drivers, typically called a driver stack. Each driver in the stack isolates some hardware-dependent features from the drivers above it.
The following figure shows the types of drivers that could potentially be in a driver stack for a hypothetical device. In reality, few (if any) driver stacks contain all these types of drivers.
Layered Driver Architecture
As the preceding figure shows:
Above the driver stack is an application. The application handles requests from users and other applications, and calls either the Win32 API or a routine that is exposed by the user-mode client driver.
A user-mode client driver handles requests from applications or from the Win32 API. For requests that require kernel-mode services, the user-mode client driver calls the Win32 API, which calls the appropriate kernel-mode client or support routine to carry out the request. User-mode client drivers are usually implemented as dynamic-link libraries (DLL). Printers support many operations that can be performed in user mode, and so typically have user-mode clients; disks and other storage devices, networks, and input devices do not.
A kernel-mode client driver handles requests similar to those handled by the user-mode client, except that these requests are carried out in kernel mode, rather than in user mode.
A device class and miniclass driver pair provides the bulk of the device-specific support. The class driver supplies system-required but hardware-independent support for a particular class of device. Class drivers are typically supplied by Microsoft.
A miniclass driver handles operations for a specific type of device of a particular class. For example, the battery class driver supports common operations for any battery, while a miniclass driver for a vendor's UPS device handles details unique to that particular device. Miniclass drivers are typically supplied by hardware vendors.
A corresponding port driver (for some devices, this is a host controller or host adapter driver) supports required I/O operations on an underlying port, hub, or other physical device through which the device attaches. Whether any such drivers are present depends on the type of device and the bus to which it eventually connects.
All driver stacks for storage devices have a port driver. For example, the SCSI port driver provides support for I/O over the SCSI bus.
For USB devices, a hub and host controller driver pair perform the duties of the port driver. These drivers handle I/O between the devices on the USB bus and the bus itself.
A corresponding miniport driver handles device-specific operations for the port driver. For most types of devices, the port driver is supplied with the operating system, and the miniport driver is supplied by the device vendor.
At the bottom of the figure is the hardware bus driver. Microsoft supplies bus drivers for all the major buses as part of the operating system. You should not attempt to replace these drivers.
Network drivers have their own unique terminology, defined in Windows 2000 and Later Network Architecture and the OSI Model. Nevertheless, network drivers are similarly layered, and each layer isolates device-specific or protocol-specific functionality from the layer above it.
Exactly which drivers are present, and what they are called, depends on the type of device and the bus to which it connects.
Graphics cards, for example, require a display driver, a video port driver, and a video miniport driver. The display driver is analogous to the kernel-mode client driver in the previous figure. It provides general drawing capabilities and can often work with more than one graphics card. The video port driver supports device-independent graphics operations. It works in tandem with the video miniport driver, which provides functionality that is specific to one graphics card (or a family of graphics cards). The paired video port/miniport drivers are analogous to the port/miniport drivers in the figure, and no class/miniclass drivers are present. For more information, see Display Architecture.
For simplicity, filter drivers are not shown in the previous figure. However, a filter driver can fit in at any layer of the driver stack above the hardware bus driver. A filter driver adds value to an existing driver by "filtering" — intercepting and manipulating device I/O. As a general rule, filter drivers do not operate the hardware directly, but work only on data and I/O requests passed to them from the next-higher or next-lower driver.
DirectShow, the Microsoft software for video capture, includes system-supplied filter drivers that run in user mode. These filters act as clients of the kernel-mode stream class driver to expose the underlying video capture technology.
9/24/2008
How to "Refresh" Device Manager by programming
We are talking about: Device Manager->Action->Scan for hardware changes
The following CM APIs should work:
The following CM APIs should work:
8/28/2008
PAE, 4GT and AWE
PAE: Physical Address Extension
4GT: 4-gigabyte tuning
AWE: Address Windowing Extensions
4GT: 4-gigabyte tuning
AWE: Address Windowing Extensions
- PAE allows the operating system to access and use more than 4 GB of physical memory. PAE also enables several advanced system and processor features, such as hardware-enabled Data Execution Prevention (DEP), Non-Uniform Memory Architecture (NUMA) and the ability to add memory to a system while it is running (hot-add memory), so it can also be used on computers that have less than 4 GB of memory. PAE is supported only on 32-bit versions of Windows; 64-bit versions of Windows do not support PAE.
- 4GT extends the 32-bit user virtual address space from 2 GB to up to 3 GB.
- AWE is a set of APIs that allows a process to allocate non-paged physical memory and then dynamically map portions of this memory into the virtual address space of the process.
- When neither 4GT nor AWE are being used, the amount of physical memory that a single 32-bit process can use is limited by the size of its address space (2 GB). In this case, a PAE-enabled system can still make use of more than 4 GB of RAM to run multiple processes at the same time or to cache file data in memory.
- 4GT can be used with or without PAE. However, some versions of Windows limit the maximum amount of physical memory that can be supported when 4GT is used. On such systems, booting with 4GT enabled causes the operating system to ignore any memory in excess of the limit. For details, see Memory Limits for Windows Releases.
- AWE does not require PAE or 4GT but is often used together with PAE to allocate more than 4 GB of physical memory from a single 32-bit process.
8/27/2008
USB Device ENUMERATION PROCESS
( Copy From Microchip AN1003)
The following summarizes the steps involved in theenumeration of a USB device and explains how thedevice goes from Powered to Default, Address and theConfigured state during the enumeration process.
1. User plugs a USB device into a USB port. The hub provides power to the port and the device isin the Powered state.
2. The hub detects the device.
3. The hub uses an interrupt pipe to report the event to the host.
4. Host sends Get_Port_Status request to obtain more information about the device.
5. Hub detects whether device is Low-Speed orFull-Speed operation and sends the information to the host in response to Get_Port_Status.
6. Host sends a Set_Port_Feature request, asking the hub to reset the port.
7. Hub resets the device.
8. Host learns if a Full-Speed device supports High-Speed operation (using Chirp K signal).
9. Host verifies if the device has exited the Reset state using Get_Port_Status.
10. At this point, the device is in the Default state(device is ready to respond to control transfersover the default pipe at Endpoint 0, default address is 00h and the device can draw up to100 mA from the bus).
11. Host sends Get_Descriptor to learn the maximum packet size (Note: eighth byte of the device descriptor is bMaxPacketSize).
12. The host assigns an address by sending a Set_Address request. Device is now in the Address state.
13. Host sends Get_Descriptor to learn more about the device. The host responds by sending the descriptor followed by all other subordinate descriptors.
14. Host assigns and loads a device driver.
15. Host’s device driver selects a configuration bysending a Set_Configuration request. The device is now in the Configured state.
16. Host assigns drivers for interfaces in composite devices.
17. If the hub detects an overcurrent, or if the host requests the hub to remove power, the device will be unpowered by the USB bus. In this case, the device and host cannot communicate and the device is in the Attached state.
18. If the device does not see any activity on the busfor 3 ms, it goes into the Suspend state. The device consumes minimal bus power in thisstate.
8/26/2008
Composite USB device
A device that contains more than one interface descriptor is known as a composite USB device. Each interface in a composite USB device is numbered.
USB Device Stack for Windows XP and Later
The PCI bus driver enumerates the USB host controllers in the system and creates a PDO for each one. In Windows XP (SP1 and later) and Windows Server 2003, the operating system supports USB 2.0 and can enumerate both USB 2.0-compliant and USB 1.1-compliant hardware. If both sorts of controller are present on the same controller card in a version of Windows that supports USB 2.0, the PCI bus driver creates two separate PDOs, one for each controller. Only one PDO is shown in the figure. After creating a PDO for the host controller, the system loads the port driver, usbport.sys, and its accompanying miniports (not shown in the figure). The port driver then creates an FDO for the host controller.
The port driver enumerates the root hub. The usbhub.sys driver enumerates all other USB hubs. The figure only shows one level of hub device objects, but USB allows daisy-chaining of hub devices, so there could potentially be many more hub device objects in the tree. The hub driver detects and enumerates the USB composite keyboard device and creates a PDO for it.
In Windows XP and later versions of the operating system, the generic parent facility is implemented by a separate driver called the USB composite client generic parent driver. For a detailed discussion of this driver, see USB Common Class Generic Parent Driver. When the system detects a composite device, it loads the generic parent driver, which creates an FDO for the device as a whole. Afterwards, the generic parent driver creates separate PDOs for each interface of the composite device. In Windows 2000, these actions are performed by the hub driver. For more information, see USB Device Stack for Windows 2000.
In the example illustrated in the figure, the composite device consists of a HID-compliant keyboard interface and a HID-compliant power keys interface. The hub driver creates a separate PDO for each interface. After that, the HID class driver creates an FDO for each interface.
The port driver enumerates the root hub. The usbhub.sys driver enumerates all other USB hubs. The figure only shows one level of hub device objects, but USB allows daisy-chaining of hub devices, so there could potentially be many more hub device objects in the tree. The hub driver detects and enumerates the USB composite keyboard device and creates a PDO for it.
In Windows XP and later versions of the operating system, the generic parent facility is implemented by a separate driver called the USB composite client generic parent driver. For a detailed discussion of this driver, see USB Common Class Generic Parent Driver. When the system detects a composite device, it loads the generic parent driver, which creates an FDO for the device as a whole. Afterwards, the generic parent driver creates separate PDOs for each interface of the composite device. In Windows 2000, these actions are performed by the hub driver. For more information, see USB Device Stack for Windows 2000.
In the example illustrated in the figure, the composite device consists of a HID-compliant keyboard interface and a HID-compliant power keys interface. The hub driver creates a separate PDO for each interface. After that, the HID class driver creates an FDO for each interface.
8/25/2008
PnP Device Installation
1. Plug the device into the computer.
2. The device is enumerated. the bus driver notifies the kernel-mode PnP manager that the list of devices on the bus has changed. The Kernel-mode PnP manager sends IRPs(IRP_MN_QUERY_ID, IRP_MN_QUERY_CAPABILITIES) to bus driver to gather information about the new device, such as HadwardID, CompatibleIDs and device capabilities.
3. The kernel_mode PnP manager notifies user-mode PnP manager that there is a device to be installed. The user-mode PnP manager tries to perform a server-side installation(quiet intallation)
4. The user-mode PnP manager creates a new process using rundll32.exe and launches newdev.dll to install the device.
5. newdev.dll calls SteupAPI(device installation functions) and CfgMgr API(PnP configuration manager functions) to carry out its installation tasks. If a device without "in box" drivers is plugged in before the operating system is installed, Device Manager will display the device as "unknown".
6. The class installer and co-installer, if any, can participate in the installation by handling DIF requests.
7. Setup transfers control to kernel mode to load drivers and start the device.
Once Setup has selected the best driver for the device, copied the appropriate driver files, registered any device-specific co-installers, and registered any device interfaces, it transfer control to kernel mode to load the drivers ans start the device.
8. The (Kernel mode?) PnP manager loads appropriate function driver and any optional filter drivers for the device. ...
a. The PnP manager calls DriverEntry routine for any required driver that is not yet loaded.
b. Then the PnP manager calls the AddDevice routine for earch driver, starting with lower-filter drivers, then the function driver, and, lastly, any upper filter driver.
c. The PnP manager assigns resources to the device, if required, and sends IRP_MN_START_DEVICE to the device's drivers.
9. Installer can change device settings or install application SW, in finish-install wizard pages( or finish-install actions in Vista above)
I suppose in step 7, Setup has done the select-copy-register driver thing, device manager could refresh automatically once. (deivice will display "Unknown" to a named device).
and then in step8, PnP manger to load driver in stack and start device, device manger could refresh automatically the 2nd time.
2. The device is enumerated. the bus driver notifies the kernel-mode PnP manager that the list of devices on the bus has changed. The Kernel-mode PnP manager sends IRPs(IRP_MN_QUERY_ID, IRP_MN_QUERY_CAPABILITIES) to bus driver to gather information about the new device, such as HadwardID, CompatibleIDs and device capabilities.
3. The kernel_mode PnP manager notifies user-mode PnP manager that there is a device to be installed. The user-mode PnP manager tries to perform a server-side installation(quiet intallation)
4. The user-mode PnP manager creates a new process using rundll32.exe and launches newdev.dll to install the device.
5. newdev.dll calls SteupAPI(device installation functions) and CfgMgr API(PnP configuration manager functions) to carry out its installation tasks. If a device without "in box" drivers is plugged in before the operating system is installed, Device Manager will display the device as "unknown".
6. The class installer and co-installer, if any, can participate in the installation by handling DIF requests.
7. Setup transfers control to kernel mode to load drivers and start the device.
Once Setup has selected the best driver for the device, copied the appropriate driver files, registered any device-specific co-installers, and registered any device interfaces, it transfer control to kernel mode to load the drivers ans start the device.
8. The (Kernel mode?) PnP manager loads appropriate function driver and any optional filter drivers for the device. ...
a. The PnP manager calls DriverEntry routine for any required driver that is not yet loaded.
b. Then the PnP manager calls the AddDevice routine for earch driver, starting with lower-filter drivers, then the function driver, and, lastly, any upper filter driver.
c. The PnP manager assigns resources to the device, if required, and sends IRP_MN_START_DEVICE to the device's drivers.
9. Installer can change device settings or install application SW, in finish-install wizard pages( or finish-install actions in Vista above)
I suppose in step 7, Setup has done the select-copy-register driver thing, device manager could refresh automatically once. (deivice will display "Unknown" to a named device).
and then in step8, PnP manger to load driver in stack and start device, device manger could refresh automatically the 2nd time.
Subscribe to:
Posts (Atom)