WHQL vs Attestation signing for Win10

Hi everyone,

could you please share any relevant links or answer on a few questions below.

I have PnP (PCI) device driver. I need to certificate the driver only for Windows 10 x64.
I have successfully passed all WHQL tests using Win10 as a client machine and HLK version 17763.
Next, I prepared .hlkx file with my tests and signed the package using Hardware Token and sent the file to https://partner.microsoft.com/en-us/dashboard/hardware/Search
However, I got the following error:

Could not open package: D:\data\Temp\HardwareProcessorHost\HardwareProcessors\005\xxx.hlkx : at Microsoft.Windows.Kits.Hardware.ObjectModel.Submission.PackageManager…ctor(String packagePath)

at Microsoft.UniversalStore.HardwareWorkflow.Processors.HlkDecompressor.Decompress(String filepath, String outputDirectory) in E:\agent_work\98\s\Src\Processors\Source\Preparation\Decompress\HlkDecompressor.cs:line 48
at Microsoft.UniversalStore.HardwareWorkflow.Processors.PackageAnalysis.d__10.MoveNext() in E:\agent_work\98\s\Src\Processors\Source\Preparation\PackageAnalysis.cs:line 54

it looks like they cannot unpack my .hlkx file.
Next, I installed the latest HLK Studio version 18362, opened my existing .hlkx and successfully signed it again, but using this new .hlkx file I got the same error.
Next, I tried to use previous version of HLK - and this version (previous to HLK version 17763) cannot open my .hlkx.

Using powershell scripts I verified:

  1. the .hlkx was signed correctly (with 17763 and 18362)
  2. the .hlkx could not be opened with the previous HLK Client because similar callstack like from Microsoft (which is above).

Next I created cab file and successfully signed my PnP device driver with Attestation signing.
I’ve checked the driver with enabled Secure Mode on Win10 x64, it works well.

My questions are:

  1. Is that possible to sign a driver using WHQL tests for Windows 10 x64 only? Microsoft Hardware Centre even doesn’t have checkboxes for Windows 10 if I upload .hklx file.
  2. if the Attestation signing works well with Secure Boot for a device driver, are there any benefits to pass WHQL tests? as I understand, Attestation signing allows to distribute the driver through Windows Updates as well.
  3. Do anyone have the similar error on Hardware Centre? I found only one mention of the same issue here https://social.msdn.microsoft.com/Forums/en-US/c059a322-0065-40a3-9bc6-a1ec9d6d36c1/derived-driver-fails-at-preparation-stage?forum=whck but no answer

if the Attestation signing works well with Secure Boot for a device driver, are there any benefits to pass WHQL tests?

The only advantage to passing the WHQL tests is that, in general, passing them is considered a “best practice.” The only advantage to submitting your test results to MSFT is if one of your customers (in the broadest possible sense) requires that your driver/hardware be WHQL certified.

For example, IHVs who are providing their hardware to one or more large OEMs are usually required by the OEMs to get WHQL Certification.

Peter

Peter, thank you

Name of signer in my sys file after Attestation signing is “Microsoft Windows Hardware Compatibility Publisher”.
isn’t it a WHQL certified?

The only advantage to submitting your test results to MSFT is if one of your customers (in the broadest possible sense) requires that your driver/hardware be WHQL certified.
is that correct for any version of Windows or just for Win10?

isn’t it a WHQL certified?

No.

is that correct for any version of Windows

Attestation signing only works for Win 10. Current,y you can self-sign drivers for other versions of Windows.

WHQL certification has never been required in order to load a driver on Windows. The need for WHQL is always driven only by customer requirements.

Peter

Name of signer in my sys file after Attestation signing is “Microsoft Windows Hardware Compatibility Publisher”.
isn’t it a WHQL certified?

No. To be WHQL certified, you have to pass the HCK/HLK tests and submit a test log. WHQL then checks the test log to prove that you passed the tests.

With attestation signing, you are merely attesting (hence the name) that you did rudimentary tests on the driver. You don’t submit test logs, so WHQL can’t certify anything about your driver.

@A_K said:

2. if the Attestation signing works well with Secure Boot for a device driver, are there any benefits to pass WHQL tests? as I understand, Attestation signing allows to distribute the driver through Windows Updates as well.

When publishing drivers on Windows Update, my experience has been that WHQL drivers publish much faster that attestation signed drivers.
WHQL: hours
Attestation: days.

Is that just me?

Hi everyone,
I have the same problem as A_K. But I need WHQL for our customers.

All HLK tests are completed successfully. Package was built with all results, drivers and symbols. Package is signed with certifiicate during creation.
If I upload this on hardware dashboard it is accepted and the process is started but it stopps on step 2 (‘Preparation’) with same error message as at A_K above.
Has anyone an idea where the cause of the problem is and how I can solve it?

schnuffi16, I’m still interesting in getting WHQL certification. if you find a solution, please let me know)

Time for one of you to open an incident… or at least live chat with the people:

Hi there pals. Regarding hanging on ‘Preparation’ step - there was a ultra-dumb bug on the portal: if your package unsigned or signed with a cert that isn’t known to portal (you have to sign it with such a cert that issued by known CA that tied to your organization somewhere in portal settings, AFAIK) then you’ll briefly get an red error message somewhere in the page, that disappear completely upon any refresh leaving submission in totally hanged state.
You just have to double-check with what cert do you sign your package and thoroughly examine submission page without any refreshes for a couple of minutes.

aww, I was so stupid not to notice backtrace you provided, yes, perhaps you should reach dashboard support for that case

It also could be useful to try to recreate packages from passed projects and reassemble them in a new submission package. Motivation: WHCK infra is full of subtle legacy heisenbugs, especially HCK (there are race conditions on controller, inconsistent database info that lead to broken packages, sporadic service crashes, terrible lags, crashes on package creation due to SQL query error et cetera et cetera). I remember one type of annoying bug that could render your package un-parsable (though “openable”) by the portal - when controller lost some info about test machine. If this is occured then at the environment tab in the project you’ll see ‘Unknown platform’ right next to test machine’s hostname, sometimes you could save such a project and even assemble a submission package that look “great’n’green” but will blow hardware dashboard up upon submission due to missing platform info. This is a quite subtle bug somewhere in communication between DUT’s HCK service and HCK controller’s service, which I wasn’t able to fully grok and MS refused to fix it. Could be worked around with a couple of reboots on a test machine and controller. Also I’ve seen a broken submission (cabinet file) emitted by the old DTM studio that used to certify drivers for WLH and lower (nowadays used only for Windows Server 2008 w\o R2) that portal refused to accept. This also was fixed by a couple of package re-creations.
So I’m advice you to very thoroughly examine your submission package for any missing info or strange artifacts like ‘unknown platform’ and to recreate it from scratch a couple of times, this doesn’t require to rerun any tests. Dashboard support is full of slowbros and will address your inquiry in a couple of weeks, if you’re lucky enough.

Hi all,
thanks for answers.
I solved the problem now. The cause is further unknown.
My solution was that I used a different system installation for HLK Studio installation. There I have set all region, language and keyboard setup to US English. Now I can sign the same unsigned packages as before and dashboard accepts it.
My assumption is that on the first pc a region setup was inconsistent or not US English.

Time for one of you to open an incident... or at least live chat with the people:
Peter_Viscarola_, thank you, I chatted with them online, the support did not help, they said I may submit an incident.
It also could be useful to try to recreate packages
el_corona, thank you, that's good point

schnuffi16, it works for me as well, I signed the same package on another server and have got a success.
However, as a result, I downloaded sys file with the same digital signature as for Attestation signing

setupapi.dev.log has the same lines for both WHQL and Attestation signing versions

sig: Signer Score = 0x0D000005 (WHQL)
sig: Signer Name = Microsoft Windows Hardware Compatibility Publisher

schnuffi16, do you have the same results?