It is several years I did something with Windows kernel drivers for the last time. But now a customer wants a small change in an old obsolete USB kernel driver which isn't even mine but people responsible for it left the company and I'm now technically responsible for it. So I made the change, built the driver with VS 2019 as before, installed it and Win10 didn't load it because it didn't like my test signing certificate. The same happens when I tried to use our company certificate:
! sig: Verifying file against specific (valid) catalog failed.
! sig: Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
Oh well. Now the silly question. How am I supposed to do kernel development? I mean some efficient way. First, I don't use debuggers. Second, I'm always using a single machine for development and testing. Third, our company doesn't seem to allow us to turn testsigning ON (do you remember Mordac from Dilbert?). So is there a way I can build a driver and load it at my machine? In the past signing with company certificate made a trick (maybe even test one, I'm not sure).
Next, I want to give such a driver to a customer for beta testing. How it should be signed? I'd prefer to not ask them to turn testsigning ON.
There's no magic here. Your statement that "I don't use debuggers" seems silly. Professional programmers use debuggers, and enabling the kernel debugger disables certificate checking.
Any reasonable IT department will allow you to do whatever you need to do get your job done -- specifically, setting testsigning on. An unreasonable IT department should be reported to the CTO.
In the long term, you WILL be required to establish a Hardware Dashboard account so you can submit driver packages to Microsoft for signing. That's what you'll do for your customer betas.
You could possibly use a self-signed certificate as described here. But that's not going to work to distribute to your customer, only for local testing.
As Tim said, you'll want to set up a Hardware Dashboard account with Azure to get the final rubber stamp from Microsoft. You'll most likely need to use the Hardware Lab Kit in order to put together the submission package.
Maybe you remember we had this discussion here about 15 - 20 years before. It'd seem silly to repeat it
I don't use debuggers because it is extremely inefficient way for me especially for real time code. I use traces and they work great for me. At any platform from small embedded to Windows and Linux.
The reasonable is the key here... Have you worked in a corporation where R&D is only a small unit?
We have it. My question was about efficient way which this isn't. Well, maybe... is it possible to automate this signing during build and without WHOL testing?
This is what I used before but it stopped work now. I guess the problem is here:
For kernel-mode drivers, you will have to disable digital signature verification and boot Windows in a test mode with the bcdedit.exe commands:
Previously it worked without it when I copied my certificate to the right place (trusted roots or something like this). Now the same certificate which is still there doesn't work.
You will need to get your new driver signed through the MS Hardware Portal. That has changed. It requires an EV cert to establish an account. It is NOT required that you WHQL/HLK test your driver. You can follow the Attestation path which is well documented. It sounds like you have an existing account. Yes you can automate the signing process. It's not straightforward or easy. If it's been 20 years since you went through this process I don't see a good reason to automate it. Use your CI system for creating the submission then walk the last part through the process manually.
Your comment, then follow-on justification for not using a debugger is your own prerogative, but you're going to have a difficult time convincing anybody else this is sane.
If you or your company is too cheap to use a second computer for testing your driver on; things are a little harder, but not terribly so. A second computer wouldn't need to be on your network where IT has anything to say about it. If you're stuck developing and testing on the same machine you can use a VM and connect to the VM with gasp the debugger.
That's what I'm looking for. Could you estimate how much time it takes for one driver package? Let's say I'd like to do it for beta version for a customer.
20 years wasn't related to this We see good reasons to automate if it is possible and have people who do such tasks. They're just not familiar with this. Could you elaborate what is necessary and what are complications?
One of reasons is internal testing. Our QA take binaries for tests from build machines (Jenkins) and it'd be ideal if the output is signed driver package usable without testsigning ON.
I'm not going to do it, I already did it many years before here. I'm happy I did it for people who work with me and they like beeing much more efficient.
Sure but I usually prefer to debug driver on the same system I'm working on. Yes, I have the second machine and I can use VM but I was asking if I can do things the way I was used before. Could we discuss HOW and not WHY?
Could you estimate how much time it takes for one driver package?
Uploading, signing, and downloading the signed package typically takes less than 1 hour for me. There have been times where it's been longer.
Our QA take binaries for tests from build machines (Jenkins) and it'd be ideal if the output is signed driver package usable without testsigning ON.
Release signing for QA is definitely not the preferred or "normal" route for doing such things. While convenient for your QA team, it ties up signing resources for the rest of the world for builds you likely won't actually release. But to answer your question about automating the signing process I'd point you to the Surface Dev Center Manager.
...but I was asking if I can do things the way I was used before.
In short, no. You can't do things the way you did before on a single machine. If you want to use a single physical machine I'd recommend spinning up a VM and loading your driver in the VM with testsigning enabled.
Could we discuss HOW and not WHY?
On this forum you're going to see a lot of responses that first want to understand why. A lot of people ask pointed questions about how to do something they think they want to do. More often than not, they are trying to solve a problem in an absurd way. In your first post in particular there are a few red flags about abnormal approach: voiding a debugger, wanting released signed binaries for testing, using the same machine for developing/testing a kernel driver. It's natural to ask, what makes your situation different than the rest of the community. It's probably not.
Obviously you know your environment better than anyone else here can, but saying things like debuggers reduce productivity isn't going to resonate with anyone. A debugger is not always be the best tool, but when it is the best tool there really isn't any substitute. There are lots of other kinds of tools too. Why limit yourself? But hey, you do what you think is best for your situation.
That being said, using a single machine has never been best practice. It is certainly easier now that you can setup VMs versus the old days where you really did need two physical machines to work on any kind of driver. These days you can do most work this way on a single machine. And one way or another, you really need full control of the system under test. Including the ability to set any security setting or modify any part of that system. It is quite futile to attempt to work on KM software - that can theoretically circumvent any security measure - while trying to limit your access to the system under test.
I think you already know the answer. There has been plenty of griping about the changes that Microsoft has made in recent years, but it is impossible to go back in time. So we just deal with what the present requirements are and move on
Thanks. A bit too much for automated build but good to know.
Is it a real problem i.e. are Microsoft resources really so limited here? Also, what's the rigth path for QA? Enabling test signing on their machines?
Great, thank you.
Unfortunately, I was just told our EV key requires USB token which has to be connected to local machine... I still don't know how exactly it is used but I guess it doesn't make automatic signing easier. Any experience here?
That's what I wanted to know. Progress...
It started to seem as a viable solution... used it in the past and wasn't quite happy with it but here progress can help. Machines have much more power and CPU cores nowadays which are idle (unless one uses Teams ;-)).
I know I'm not sure if it is visible somewhere but I'm member for at least 22 years, probably more. I'm not very active anymore but I was a lot 10+ years before. And I still sometimes give somebody a link to famous Peter's article about gluing wings to a pig. So I understand and I'd probably ask the same in the past and I'm merely asking if we can skip this part here and accept I probably know what I'm doing
The difference is I'm really lazy about tedious things which are done some way because everybody does it. So I develop my own ways which are more efficient for me. The disadvantage is they could be broken as here because everybody uses debugger and two machines
Have I said it? I don't think so I said debugging code via debuggers is extremely inefficient way for me. With traces I'm much more efficient but of course, they have to be integral part of the code before it is even run for the first time so you don't need to add any and just check what code is doing. As ETW.
I don't. For example I successfully used debuggers as trace support at some embedded systems. Sometimes I even use them to step at instruction level there when something weird happens (well, it is years I did it last time). I just say I don't need and don't want them for Windows driver development. Well, except of crashdump analysis, of course.
Everything has pros and cons. I had to be very careful to not crash my machine by a bug in the driver under development.
Yep, I completely agree. Have you tried to explain it to a Mordac?
This is why I asked, I seldom do Windows driver development now so I wanted to know what changed and how to deal with it. I guess I know now but if anybody has more points or ideas I'd appreciate it.
Well, if you are asking if I have a boss - the answer is maybe technically, but not really. My father is president of the company, but I own more shares than him, and he is smart enough not to ask too many questions about how code is actually written etc. Of course I also have the strange circumstance that my mother is my direct employee. Careful decorum is the order of the day.
So I am not going to second guess whatever complex circumstance you find yourself in. But there are things that can't be changed no matter who is asking.
What Mr. @Shane_Corbin might not realize is that Mr. @Michal_Vodicka is a long standing member of this group, and in bygone days was active daily and very helpful. So, he’s a “friend of the family” so to speak
Michal: Mr. Corbin is giving you good advise, Ignoring the tangential comments regarding using a single machine and a debugger (where I totally agree him, but realize that after all these years nobody is going to change your mind).
I can perhaps add a couple of things:
EV Certs need to be on “secure” devices, like an eToken or a secure key store. This makes it more annoying to use during signing, but not too much if you have ready access to the key. You plug the key into the machine from which you’re doing the signing, the cert just shows up like normal.
Attestation Signing is simple, once you understand the process for building the “driver package”. It’s usually pretty fast: build the package, upload, MSFT runs their automated process, download result. As Mr. Corbin said, the “wait” on the MSFT process is typically less than an hour (in my experience, typically less than 20 mins), but the MSFT dashboard is pure shite and it sometimes gets itself into a bad state. On those occasions it can take an indeterminate amount of time.
For testing, the usual process is to sign the driver using a self- signed cert built with makecert. The VS WDK process will do this automatically for you. You take certificate and install it on the test machine, in the Trusted Root Certificate Authority cert store. You also need to enable test signing. An alternative to this is to have a debugger actively attached to the target machine… when you have a debugger actively attached, driver signing is effectively bypassed.
Welcome back… it’s good to “see” you here again… I hope that helps,
I have noticed people that don't use debuggers is often due to giving up after all the frustration barriers trying to set them up. I once knew an old EE guy who debugged by wiggling a line on the parallel port and watching it on an oscilloscope. It was a painfully slow way to debug, but he didn't know it. He had no idea at the time how a debugger would give him orders of magnitude more productivity.
Great chess players can play chess blind folded and they can do pretty well at it too which is impressive. But the fact is they are slower and less accurate with a blind fold on, even Carlsen. Great developers can solve bugs without a debugger, but here again it is slower and less accurate. Debuggers remove the blind fold and you can see everything right in front of you. Anyone using a debugger understands it enhances their productivity. That's why we use them. Linus is right they are not a necessity, but he is wrong that we would all be better off without them.
Thanks for your kind words, Peter Is there a way how to find when one joined this list? Just curious because I don't remember, nothing important.
Yes, I was said our EV key needs USB token which is in the office on another continent and can't be used via remote desktop. Which doesn't make things easy. So I'll need remote coworker to make this task, I'm sure he'll be happy
I used self signed cert way and Trusted Root Certificate Authority store before. This is what stopped working for me and the reason why I asked. I realize test signing has to be enabled which may seem as a small obstacle when you have full control over the machine but it can be surprisingly complicated in a corporation. Oh well, will have to handle is some way.
This is my partial reason here, I don't want to bother with two machines and connection to make WinDbg working. But in the past I used SoftICE without these burdens a lot. Years later I found myself to not using it for debugging my code but mainly working with others' code for which I didn't have sources.
For embedded programming a debugger is often connected but I still don't use it for debugging my code because there is no reason.
Actually, I agree with him. Debugger gives developer isolated local view which is good for learning but experienced and productive developer needs global view. I usually don't need to check the state of my variables in stopped process, I need to see code flow in real time. I admit there are cases when it can be useful but they're rare for me.
You know, code which doesn't need debugger has to be written special way. Robust, self checking, traces everywhere. It takes a bit more time to write it but debugging is a piece of cake then. More important, it allows anybody else to see what is wrong in your code almost immediatelly which is really helpful with complicated projects with many collaborating components. But I'm not here to persuade anybody, my original problems seems solved Well, at least I know what changed and how to deal with it.
No, I mean Mordac, the preventer of Information Services. It was funny joke until I found they really exist in corporations. You don't meet them personally, they're sitting in their office on the other side on the World and just add restrictions to your machines without telling nothing. You just notice a setting which was working yesterday is greyed out today. Every month or week one by one. Feel lucky if you never encountered this
Yes, I found my NTDEV archive starting 2002 but it isn't the oldest one. I probably have it in some old backup but don't want to search for it. I guess I could be here before 2000 (and now I'm feeling old...)
I'm not sure if it is visible somewhere but I'm member for at least 22 years, probably more. I'm not very active anymore but I was a lot 10+ years before. And I still sometimes give somebody a link to famous Peter's article about gluing wings to a pig. So I understand and I'd probably ask the same in the past and I'm merely asking if we can skip this part here and accept I probably know what I'm doing 
I'm done with it if others are.