Deploying the CyUSB driver on Windows 7 64bit

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

We are a small company selling bespoke scientific instruments. A few years ago, we contracted a local firm to design an electronics board for specialist fast timing. It uses the CY7C68013A microcontroller for management purposes and for communication with a PC over USB. It turned out that our sub-contractor did not write a device driver, but merely supplied the Cypress CyUSB.sys driver and a simple user mode wrapper around the required parts of the CyUSB.lib library. Indeed it turns out that the sub-contractor does not have the skills to write a driver, their speciality is electronics.
 
All the other higher level driver software has been written in-house, is user-mode and 32bit. We have not bothered to sign any of the code, as in our world it simply doesn't add any value. We sell only 5-10 units a year, mostly as part of instrument sales and mostly with a PC supplied by us. We have a personal relationship with our small number of clients and they have to trust us on a range of issues; possible errors with the drivers is the least of their worries. In any case, we haven't actually touched the driver code as such, CyUSB.sys, we have merely changed the .inf file to match the vendor and product IDs in the code that runs the board. We do have our own official USB vendor code, purchased a long time ago.
 
All this has been working absolutely fine with Windows XP based PCs; the message warning about the unsigned driver is usally only seen by us and one can elect to ignore it. Anyway, I am not embarrassed for the client to see such a warning message; they understand the specialist nature of what we do. Now, however, we are being forced towards Windows 7. We have run the hardware with Windows 7 32 bit, where one can still override the complaint about the lack of driver signing. We have also managed to make it run under Windows 7 64bit, having followed the procedure for disabling driver signing. I will be forced to use Windows 7 64bit in future; it now seems to be the default on all new PCs. I have not yet found a method for running our hardware that does not involve disabling all signing protection and requiring our users to run permanently in a test mode.
 
So, ideally there would be a way to make a given Windows 7 64bit installation run our hardware without disabling all protections. If anyone knows how to do this they would make me very happy by telling me, but I am coming to the conclusion that Microsoft have succeeded in making this impossible.  Otherwise we have to get the driver signed. But there is a great deal of confusing information on this topic. I really need a walkthrough that is completly specific to Windows 7 64bit. I think I might have discovered that the driver has to go through the WHQL process, requiring a client server setup and test results submitted to Microsoft. Is this necessary even though the CyUSB comes from Cypress? I think that not all signing certificates will be suitable. I only need to do this once. There is not going to be any upgrades to this part of the software. It should last us until we have to design a completely new board - some more years - our world does not move at the pace of consumer electronics.

I would be very happy to use a sub-contractor, if I could find somone suitable at a sensible cost (bearing in mind the very small numbers). I am not sure whether the signing process requires one of our actual boards, as well as the driver; we only have a few available at a time. The hardware does not fall into any standard class, so there is very little that general testing software could do with it.

The whole thing is very frustrating, especially since we haven't actually touched any driver code. I would be very grateful for advice from someone who has been through this process. Sorry there is so much detail, but I wanted the context to be clear so the suggestions are appropriate.

TIA

0 Likes
1 Solution
Anonymous
Not applicable

 Hi,

   

 As far as I know driver signing is the only way to get rid of this problem. Following links would be helpful for you http://www.cypress.com/?id=4&rID=37913 and http://www.cypress.com/?app=forum&id=167&rID=56763.

   

Thanks

   

Prajith

View solution in original post

0 Likes
7 Replies
Anonymous
Not applicable

 Hi,

   

 As far as I know driver signing is the only way to get rid of this problem. Following links would be helpful for you http://www.cypress.com/?id=4&rID=37913 and http://www.cypress.com/?app=forum&id=167&rID=56763.

   

Thanks

   

Prajith

0 Likes
Anonymous
Not applicable

Thanks for the pointers. The second link was especially helpful and I have eventually succeeded. I thought a couple of notes might help anyone following.

   

I went for GlobalSign for a code signing certificate in the end. Their website seemed to have a bit more help on it and looked friendlier and they were by no means the most expensive. It took about 3 days to get the certificate. There was a much cheaper code signing certificate available from another site  - but they advised that it could not be used for kernel mode signing, presumably a difficultly with the cross-certification to Microsoft.

   

The GlobalSign help showed me how to get the certificate out of the browser store (I was using Firefox on Windows XP) and into the personal certificate store - not too hard.

   

I believe you have to make a .cat file. The easiest way is probably to use inf2cat.exe. I couldn't find a source for this by itself, so had to download all 620MByte of the Microsoft Windows Driver Kit to get a copy (I downloaded WDK 7.1.0 and simply searched for inf2cat.exe). This step required me to burn a DVD and took a while - frustrating for such a small tool.

   

I downloaded the cross-certificate from the Microsoft site and put it in a directory near the drivers so I could refer to it easily in a batch file I constructed to run the signtool command.

   

The last gotcha was some daftness associated with the GlobalSign root certificates. I had to delete a bunch of them from my certificate store before the cross-certification worked properly. This felt a bit irreversible and scary, but was absolutely necessary and mentioned on the GlobalSign site. The "Signtool verify..." command was useful to check the root certification which has to go back to Microsoft and didn't until I had this bit correct.

   

All in all, this was an immensly expensive exercise, mostly in time spent. I am unconvinced that the paternalistic attitude from Microsoft (users can't be trusted to make an exception - not even Admin users!) is any real benefit to anyone except Microsoft and the certificate sellers, but I guess our use (Scientific instruments) is non-typical and so why should Microsoft care.  It's made me look longingly at Linux again; maybe Cypress should consider providing a little more help in that direction.

0 Likes
Anonymous
Not applicable

Hi

   

I used GlobalSigns Code Signing Certificate, I managed to sgn the .cat file and the cyusb.sys file using the signtool but when the driver loads (Win7 64bit) it complained about the driver file (cyusb.sys). When I contacted GlobalSign they told me I needed a "Driver signing certificate"

   

So not sure how it worked ok for you.

0 Likes
Anonymous
Not applicable

Hi

   

 

   

I finally managed to get the Globalsign Code Sign Certificate to sign my driver properly. My problem was that the root certificate I was using was not chaining back to microsoft. Reason for the Code 52 from Device Manager.

   

 

   

Regards

   

jaz

0 Likes
Anonymous
Not applicable

 Thanks for updating the thread.

   

 

   

Regards

   

Nikhil

0 Likes
Anonymous
Not applicable

win7 64bit, must add depend object: Setupapi.lib;  CyAPI.lib (x64 )

0 Likes
Anonymous
Not applicable

 Hi,

   

Thanks for your update.

   

-PRJI

0 Likes