>> It’s all so confusing. It makes me happy I don’t do “real” installation
> procedures for products,
>
> Peter
> OSR
Peter, would you mind giving a brief description of the installation procedure that you prefer? (with a focus on: XP, Vista, Vista x64)
Prior to the Vista, I was inclined to manually copy all driver files to the proper Windows system directories (\windows\inf, \windows\system32\drivers, \windows\system32). When the USB device is plugged in, if the user selects the option of “Automatically find the drivers”, both XP and Vista would discover them if the inf was written properly.
Is that the process you refer to? Or is it something else, such as using DPInst or IFxApp, or DevCon, or other?
Aside from the smallest, hacked-up, engineering-level, crappy minimum necessary to get a driver installed for testing, I don’t do any installation procedures at all. So, for USB let’s say, I hack together some re-used junky .INF file, copy it to c:\Junk along with the .sys file, and plug the device in… then point the installer to the directory.
Ugly, but my only need is to get things installed for development and testing.
I also use DevCon a fair bit… one of the world’s greatest utilities, I think.
DevCon a fair bit… one of the world’s greatest utilities
Hear Hear!
Too bad the INetCfg swiss-army-knife equivalent SNETCFG.EXE got retired in
favor of BindView. Between devcon and snetcfg I have been able to avoid
creating installers of any sort for almost all development work. And don’t
forget SC.EXE to pull out those left-over PnP driver service entries!
There is something to be said for “simply works”.
And hardly ugly…
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, March 20, 2009 10:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Vista 64-bit code signing: “windows can’t verify the
publisher of this driver”
Aside from the smallest, hacked-up, engineering-level, crappy minimum
necessary to get a driver installed for testing, I don’t do any installation
procedures at all. So, for USB let’s say, I hack together some re-used
junky .INF file, copy it to c:\Junk along with the .sys file, and plug the
device in… then point the installer to the directory.
Ugly, but my only need is to get things installed for development and
testing.
I also use DevCon a fair bit… one of the world’s greatest utilities, I
think.
Ugly? No, that would be a setup driven by, say, xml configuration files.
mm
David R. Cattley wrote:
> DevCon a fair bit… one of the world’s greatest utilities >
Hear Hear!
Too bad the INetCfg swiss-army-knife equivalent SNETCFG.EXE got retired in
favor of BindView. Between devcon and snetcfg I have been able to avoid
creating installers of any sort for almost all development work. And don’t
forget SC.EXE to pull out those left-over PnP driver service entries!
There is something to be said for “simply works”.
And hardly ugly…
-dave
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, March 20, 2009 10:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Vista 64-bit code signing: “windows can’t verify the
publisher of this driver”
Aside from the smallest, hacked-up, engineering-level, crappy minimum
necessary to get a driver installed for testing, I don’t do any installation
procedures at all. So, for USB let’s say, I hack together some re-used
junky .INF file, copy it to c:\Junk along with the .sys file, and plug the
device in… then point the installer to the directory.
Ugly, but my only need is to get things installed for development and
testing.
I also use DevCon a fair bit… one of the world’s greatest utilities, I
think.
To answer Peter’s questions: Yes, it checks for signatures on x86 drivers at boot, and then ignores them if they are missing. Can’t say why - but that is the behavior. We’ve spent a lot of time with the OEMs making sure they have signatures on all their boot loaded drivers.
WHQL is checking for the signature on the .sys file precisely because of the boot performance issue. (At least I *think* they added this test - I’m not as close to this issue as I use to be Why don’t they sign it themselves? They don’t have the infrastructure in place. I believe this is in the SYSTEM logo tests, not the individual device logo tests. So, an IHV could get the logo, then added the embedded signatures to the binaries before handing them off to the OEMs to add to their systems.
MM: No contradiction. The KMCS walkthrough says “This requirement ensures optimal system boot performance.” Not, “This is required to boot.”
Jonah:
I think the dialog you are seeing is the “unsigned” Error dialog, not the warning dialog. When I look in the local computer Trusted Root store on my Vista machine, I don’t see a cert from Global Sign. Use MMC.exe - install the certificates plug in for the Computer Account - it will show up as Local Computer. And then look in the Trusted Root Certificate Authorities folder, certificates. Is the certificate there that your signing cert has as it’s root? (To find that, right click on a catalog file or .sys file that you have signed, go to properties, select the Digital Signatures Tab. Select the item from the signature list and click details. On the Digital signatures details dialog, do you see a message that says “A certificate chain processed, but terminated in a root certificate that is not trusted by the trust provider”? Alternative, what do you get if you do:
“signtool verify /v /pa .cat”
2. It should be looking at the signature on the catalog file and showing the signature, IF it is a “valid” signature. If you had a problem with #1, you’ll have a problem here.
3. That is a bug in that dialog. You should ignore it.
I’m confused - it uses the words ‘must’ and ‘requirement.’
In the special case of boot-start drivers—drivers that are loaded by the Windows Vista operating
>system loader—publishers MUST use an SPC to embedded-sign the driver binary image file. This
>REQUIREMENT ensures optimal system boot performance.
To answer Peter’s questions: Yes, it checks for signatures on x86 drivers at boot, and then ignores them if they are missing. Can’t say why - but that is the behavior. We’ve spent a lot of time with the OEMs making sure they have signatures on all their boot loaded drivers.
WHQL is checking for the signature on the .sys file precisely because of the boot performance issue. (At least I *think* they added this test - I’m not as close to this issue as I use to be Why don’t they sign it themselves? They don’t have the infrastructure in place. I believe this is in the SYSTEM logo tests, not the individual device logo tests. So, an IHV could get the logo, then added the embedded signatures to the binaries before handing them off to the OEMs to add to their systems.
MM: No contradiction. The KMCS walkthrough says “This requirement ensures optimal system boot performance.” Not, “This is required to boot.”
Jonah:
I think the dialog you are seeing is the “unsigned” Error dialog, not the warning dialog. When I look in the local computer Trusted Root store on my Vista machine, I don’t see a cert from Global Sign. Use MMC.exe - install the certificates plug in for the Computer Account - it will show up as Local Computer. And then look in the Trusted Root Certificate Authorities folder, certificates. Is the certificate there that your signing cert has as it’s root? (To find that, right click on a catalog file or .sys file that you have signed, go to properties, select the Digital Signatures Tab. Select the item from the signature list and click details. On the Digital signatures details dialog, do you see a message that says “A certificate chain processed, but terminated in a root certificate that is not trusted by the trust provider”? Alternative, what do you get if you do:
“signtool verify /v /pa .cat” > > 2. It should be looking at the signature on the catalog file and showing the signature, IF it is a “valid” signature. If you had a problem with #1, you’ll have a problem here. > > 3. That is a bug in that dialog. You should ignore it. > >
Jennifer, thanks again for your help! But please note:
> Jonah:
> 1. I think the dialog you are seeing is the “unsigned” Error dialog, not the
> warning dialog. When I look in the local computer Trusted Root store on my
> Vista machine, I don’t see a cert from Global Sign. Use MMC.exe - install the
> certificates plug in for the Computer Account - it will show up as Local
> Computer. And then look in the Trusted Root Certificate Authorities folder,
> certificates. Is the certificate there that your signing cert has as it’s root?
Yes, there is a “GlobalSign”, and two “GlobalSign Root CA” certificates, all 3 of those are under Trusted Root Certificate Authorities on both my XP Pro machine and Vista64 machine.
> (To find that, right click on a catalog file or .sys file that you have signed,
> go to properties, select the Digital Signatures Tab. Select the item from the
> signature list and click details. On the Digital signatures details dialog, do
> you see a message that says “A certificate chain processed, but terminated in a
> root certificate that is not trusted by the trust provider”?
On the .cat file’s “Digital Signatures” tab, clicking on the item in the Signature List, it says “This digital signature is OK”. No error message like you state on any of the sub-dialogs.
> Alternative, what
> do you get if you do:
> “signtool verify /v /pa .cat”
Number of files successfully Verified: 1 Number of warnings: 0 Number of errors: 0
Despite all this, during install, I still see what you believe is an Error message (as opposed to Warning message). If you could clarify exactly what the Error message and Warning message each say, that would be helpful.
Why don’t they sign it themselves? They don’t have the infrastructure in place. I believe this is in the SYSTEM logo tests, not the individual device logo tests. So, an IHV could get the logo, then added the embedded signatures to the binaries before handing them off to the OEMs to add to their systems.