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
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）
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).
How Can I Open a Text File as Unicode?
http://www.microsoft.com/technet/scriptcenter/resources/qanda/apr06/hey0419.mspx
How Can I Open a Text File as Unicode?
with that in mind here’s a script that will open the Unicode file and correctly echo back the contents:
Const ForReading = 1
Const TriStateTrue = -1
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("c:\scripts\test.txt", ForReading,False,TriStateTrue)
strText = objFile.ReadAll
objFile.Close
Wscript.Echo strText
How Can I Open a Text File as Unicode?
with that in mind here’s a script that will open the Unicode file and correctly echo back the contents:
Const ForReading = 1
Const TriStateTrue = -1
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("c:\scripts\test.txt", ForReading,False,TriStateTrue)
strText = objFile.ReadAll
objFile.Close
Wscript.Echo strText
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/14/2009
Overview of Signing and Install Process
I think "PIC" actually means "SPC".http://msdn.microsoft.com/en-us/library/aa906274.aspx
Kernel-Mode Code Signing Requirements for Public Release of a Driver
Windows Vista 64-bit Versions
The kernel-mode code signing policy requires that a kernel-mode driver be signed as follows:
? A kernel-mode boot-start driver must have an embedded Software Publisher Certificate (SPC) signature. This applies to any type of PnP or non-PnP kernel-mode boot-start driver.
? A non-PnP kernel-mode driver that is not a boot-start driver must have either a catalog file with an SPC signature or the driver file must include an embedded SPC signature.
? A PnP kernel-mode driver that is not a boot-start driver must have either an embedded SPC signature, a catalog file with a WHQL release signature, or a catalog file with an SPC signature. Although the kernel-mode code signing policy does not require that the catalog file of a PnP driver be signed, PnP device installation treats a driver as signed only if the catalog file of the driver is also signed.
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
Subscribe to:
Posts (Atom)