All about Windows Hardware Development https://docs.microsoft.com/archive/blogs/xiz/feed.xml Windows Driver/Device Development and Hardware Certifcation Wed, 17 Apr 2019 03:28:47 GMT en-US hourly 1 6 months after I move to Intel MCG https://docs.microsoft.com/archive/blogs/xiz/6-months-after-i-move-to-intel-mcg Sun, 01 Jun 2014 21:27:43 GMT https://blogs.msdn.microsoft.com/xiz/2014/06/01/6-months-after-i-move-to-intel-mcg/ Cheers! Great place to wok on Windows Tablet in MCG!

]]> MaximumTransferSize is obsolete after Win2000 https://docs.microsoft.com/archive/blogs/xiz/maximumtransfersize-is-obsolete-after-win2000 Sun, 03 Nov 2013 18:21:53 GMT https://blogs.msdn.microsoft.com/xiz/2013/11/03/maximumtransfersize-is-obsolete-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.     https://msdn.microsoft.com/en-us/library/ms790486.aspx
2.       https://msdn.microsoft.com/en-us/library/ms793357.aspx

]]> Layered Driver Architecture https://docs.microsoft.com/archive/blogs/xiz/layered-driver-architecture Sun, 03 Nov 2013 18:21:19 GMT https://blogs.msdn.microsoft.com/xiz/2013/11/03/layered-driver-architecture/ https://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.

]]> "CTS" is not supported by USBSer.sys? https://docs.microsoft.com/archive/blogs/xiz/cts-is-not-supported-by-usbser-sys Sun, 03 Nov 2013 18:20:47 GMT https://blogs.msdn.microsoft.com/xiz/2013/11/03/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.

]]> Get installed hotfixes in Windows https://docs.microsoft.com/archive/blogs/xiz/get-installed-hotfixes-in-windows Sun, 03 Nov 2013 18:20:17 GMT https://blogs.msdn.microsoft.com/xiz/2013/11/03/get-installed-hotfixes-in-windows/ Here is a command: wmic qfe list full

  • On XP, go to the registry directly: 
    Instances of this class represent updates found in two places in the registry:

     

    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows  NT\    CurrentVersion\Hotfix

    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates

  • On Vista+, the registry doesn't exist any more. Try the WMI Class: Win32_QuickFixEngineering Class https://msdn.microsoft.com/en-us/library/aa394391(VS.85).aspx
]]> To ignore a device's serial number https://docs.microsoft.com/archive/blogs/xiz/to-ignore-a-devices-serial-number Sun, 03 Nov 2013 18:19:33 GMT https://blogs.msdn.microsoft.com/xiz/2013/11/03/to-ignore-a-devices-serial-number/ https://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

]]> Run program as Local System Account https://docs.microsoft.com/archive/blogs/xiz/run-program-as-local-system-account Sun, 03 Nov 2013 18:18:53 GMT https://blogs.msdn.microsoft.com/xiz/2013/11/03/run-program-as-local-system-account/ To delete registry keys under Vista+...

This article  which demonstrates the use of PSTools from SysInternals which was acquired by Microsoft  in July, 2006. I launched the command line and issued the following statement  and suddenly I was running under the Local System Account like magic:

psexec -i -s cmd.exe

PSTools worked great.

 

https://verbalprocessor.com/2007/12/05/running-a-cmd-prompt-as-local-system

https://download.sysinternals.com/Files/PsTools.zip

]]> How to remove phantom/ghost devices https://docs.microsoft.com/archive/blogs/xiz/how-to-remove-phantomghost-devices Sun, 03 Nov 2013 18:18:24 GMT https://blogs.msdn.microsoft.com/xiz/2013/11/03/how-to-remove-phantomghost-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"

]]> Test Unit Ready (TUR) https://docs.microsoft.com/archive/blogs/xiz/test-unit-ready-tur Sun, 03 Nov 2013 18:17:45 GMT https://blogs.msdn.microsoft.com/xiz/2013/11/03/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.

 

https://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

]]> Overview of Signing and Install Process https://docs.microsoft.com/archive/blogs/xiz/overview-of-signing-and-install-process Sun, 03 Nov 2013 18:17:17 GMT https://blogs.msdn.microsoft.com/xiz/2013/11/03/overview-of-signing-and-install-process/  

 
I think "PIC" actually means "SPC".

https://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.
]]>