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.)

1. 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
2. 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.

Reference:
http://blogs.msdn.com/b/wer/archive/2009/02/09/kernel-dump-storage-and-clean-up-behavior-in-windows-7.aspx

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

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

[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.

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

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）

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).

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

USB Port busy, or not

How to detect USB Port status connected with a USB Flash drive? (working or idle).

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"

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

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.