At work I use Microsoft HCK as a framework for testing my projects which involves testing a few drivers and NT services. This is working great for us since we can do our custom test jobs as well as use the ones from WHQL tests. We invested a lot of time into creating different tests jobs and tools and our testing ecosystem is based on that. Using HCK we can test dozens of machines covering major operation systems: XP, Vista, 7, 8, Server 2003, Server 2008 and Server 2012.
Recently Microsoft released Windows 8.1 and Server 2012 R2 operating systems which do not seem to be compatible with the version of HCK we are using (HCK for Windows 8). If you try to install HCK client on 8.1 or Server 2012 R2 you will see the following error message: “Windows Hardware Certification Kit Client Setup wizard ended prematurely”. The nice message will look like this:
It seems like the Microsoft response to this problem is simple: upgrade your HCK from 8.0 to 8.1 and the problem will go away. However, there is catch.
The newer HCK 8.1 does not support Windows XP, Windows Vista and Server 2003. Which means that if you are writing custom test jobs, you will probably need to have two different HCK servers covering all operation systems:
HCK 8.0 to cover XP, Vista and Server 2003
HCK 8.1 to cover 7, 8, 8.1, Server 2008, Server 2012, Server 2012 R2
The problem with this approach is synchronization of jobs. Since HCK is poorly documented, you most likely will not found any official documentation on how to synchronize jobs between two different versions of HCK. Moreover, as the HCK protocol is proprietory, it might not be possible at all in the future versions.
The most interesting thing is, in terms of features the difference between Windows 8.0 and Windows 8.1 is quite small. Conceptually, these are the same systems. How come that HCK 8.0 supports Windows 8.0 but does not support Windows 8.1 given the technical similarities? Perhaps, with this idea in mind, it will be possible to make Windows 8.1 work in HCK 8.0 and have a full coverage of all operating systems in a single HCK server?
In order to see what exactly is the problem, one has to dig into the MSI log of the installation. The message which indicates error usually mean a failure of some custom action inside MSI, and analysis of the custom action might shed more light on the problem.
The usual place for HCK installation is a temp folder the user. The file name is Windows Certification Kit Client_Install.log. Just search for this file and see if you get any hits. Once you found the file, open it in any text editor and try to see which is the exact problem of failure:
MSI (c) (C4:9C) [20:22:08:376]: Doing action: SetICFEnabled
Action start 20:22:08: SetICFEnabled.
MSI (c) (C4:AC) [20:22:08:408]: Invoking remote custom action. DLL: C:\Users\VSHCHE~1\AppData\Local\Temp\MSI4CD9.tmp, Entrypoint: SetICFProperties
MSI (c) (C4:B0) [20:22:08:454]: Cloaking enabled.
MSI (c) (C4:B0) [20:22:08:454]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (C4:B0) [20:22:08:454]: Connected to service for CA interface.
CustomAction SetICFEnabled returned actual error code 1157 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (c) (C4:9C) [20:22:08:532]: Note: 1: 1723 2: SetICFEnabled 3: SetICFProperties 4: C:\Users\VSHCHE~1\AppData\Local\Temp\MSI4CD9.tmp
MSI (c) (C4:9C) [20:22:08:532]: Product: Windows Hardware Certification Kit Client -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action SetICFEnabled, entry: SetICFProperties, library: C:\Users\VSHCHE~1\AppData\Local\Temp\MSI4CD9.tmp
As you can see above, the custom action SetICFProperties failed with some error. It is unclear what this custom action is doing, but as the name stands, ICF may mean Internet Connection Firewall. From this point, there are several choices to follow and understand what is the purpose of this custom action:
1. (easy) One may use Orca msi editor and remove the condition to run SetICFProperties custom action
2. (complex) One may use Ida disassembler and analyze the function SetICFProperties exported by some of the custom action dlls
I decided to go with the choice #1, however, it was clear for me that if disabling custom action did not solve anything, I would have to fallback to #2 anyway. So, here is the exact steps on what to do next:
1. Open Windows Hardware Certification Kit Client-x86_en-us.msi or Windows Hardware Certification Kit Client-x64_en-us.msi with Orca
2. Navigate to CustomAction table as shown on image
3. Remove entry of the table and memorize the name of the action: “SetICFEnabled”
4. Now, you need to navigate to InstallExecuteSequence table as shown on image and remove entry “SetICFEnabled”
5. Now, you need to navigate to InstallUISequence table as shown on image and remove entry “SetICFEnabled”
6. Save your modifications with Orca and try to run msi in Windows 8.1
7. Observe the MSI installs successfully
It turns out that SetICFProperties custom action is simply adding HCK Client communication port (tcp 1771) into exclusion list of your Microsoft Internet Connection Firewall. Since something has changed in Windows 8.1 regarding ICF the old way of adding exclusion for tcp port did not work and the whole MSI just failed with some generic error.
What it means for you is that despite patching the MSI with Orca you will probably need to add exclusion to tcp 1771 port (out and in) manually in your Windows 8.1 machines.