The Windows Drivers team at Microsoft would love to hear your feedback on our upcoming initiatives and how they impact your work. Your input is invaluable—it helps us understand what works, what doesn’t, and how we can deliver a state-of-the-art driver developer experience.
We have only received 14 responses, so we decided to remove the deadline for response and now I can’t even edit the post. Can someone help me with how to edit a post?
There is more to driver development than just the WDK. That survey had no place to address shortcomings with the driver signing submission process and how to resolve issues with the HLK.
It seems to miss the point that constant revisions of the WDK, none of which have been well tested or even apparently tested at all for down-level support, is maddening. The survey feels like it’s looking to discover a short list actionable items (“please be as specific as possible”, “please provide detailed repro steps”) without addressing the wholistic issues of the Windows driver development process or eco-system.
The third-party driver development community has been increasingly ignored and disrespected over the past ten years. The whole process has lost its way and gone from being focused on partnering for the enablement of third party devices and connectivity to being a dictatorial roadblock to supporting devices on Windows.
In general, the message that I hear from the community is that it feels like MSFT thinks we should be grateful that we get to write drivers for their operating system, instead of Microsoft being welcoming and appreciative that we want to support our devices and solutions on their platform.
That’s my survey contribution. I’ve been as specific as possible.
This particular survey is focused on WDK, however if you have issues with other related kits such as HLK or SDK, you could share those on question “12” of the survey “Any other feedback and suggestions”
Years ago, during that period when “Total Quality Management” was a buzzword in every large corporation, I worked at such a corporation (Control Data Corporation), and took some seminars on rooting out the problems in an organization by using surveys and questionnaires. From that, I actually did learn some valuable lessons.
When you create a committee to root into problems, every individual on that committee has a very firm notion of what the major problems are. The hitch is that each member of the committee has a DIFFERENT idea, and those ideas are rarely related to the actual problems faced by the organization.
Thus, when they send out a survey, the survey is almost always worded in such a way to direct the participants into one of the pre-conceived (and incorrect) problem areas, to confirm the biases of the committee members. It is very, VERY difficult to word a survey in such a way as to find out what the organization members, customers, and clients actually see as the problems. Our committee put together a survey like that, and the information we got back was virtually useless, because we asked the wrong questions.
Thus, although I agree with your sentiment, I also have great sympathy for the folks trying to dig out the truth. It ain’t easy. In the 1990s, this is what the Windows Hardware Developer’s Conferences were good for – get the real developers in a room with the decision makers, and let’s have a rollicking roundtable.
Regarding question 12 on the survey, yes, that’s exactly where I made mention of the driver signing and HLK related issues that I’ve encountered.
It seems to me that Microsoft should not, in fact, have a problem with figuring out what the WDK needs to support w/respect to down-level / legacy versions of Windows. If they simply look at their own LTSC end of support dates for various builds that are still supported, then the WDK needs to support those builds of Windows. Properly QA testing the WDK itself should follow with ensuring that every example builds and executes correctly for every build of Windows that is supported and every development tool set (Visual C++) version that is supported. Additionally, the examples being built need to exercise as much of the documented WDK as possible. If specific kernel-mode API functions aren’t going to be tested, that needs to be noted in the WDK documentation. Surely this is something that can be automated to a large degree in terms of build pipelines and subsequent testing of the code that has been built.
Is somebody going to drop the “AI shoe” on this and say that we should just have AI build & test it all for us?
I just noticed that after upgrading from Windows 10 IoT LTSC build 1809 to Windows 11 IoT LTSC IoT build 24H2 that you can no longer get the WDK for 24H2 and only WDK for 25H2 is available.
Can we still build drivers for Windows 11 LTSC build 24H2 with 25H2 WDK?
Windows Iot Enterprise LTSC is a still an (allegedly) supported product.
I did your survey however the last part (any other thoughts) I said that I think you should be also paying attention to the problems people are having signing up for the hardware dashboard to get their drivers signed.
@Peter_Viscarola_OSR Thank you for sharing such honest feedback; and @Tim_Roberts I appreciate your thoughtful perspective on how difficult it can be to uncover the real problems through surveys alone. Both of your points resonate deeply.
It’s clear that parts of the Windows driver development experience have not met expectations, and that frustration is valid. We recognize that somewhere along the way, the connection between Microsoft’s goals for this community and your lived experience as developers became misaligned. That’s something we’re committed to fixing.
Our focus now is on rebuilding trust and partnership — not through isolated surveys or one-time gestures, but through open, continuous engagement with the people using our developer kits and tools to develop and certify drivers on Windows platform. I’d like us to work together toward sustainable improvements that make the developer experience better for everyone.
Please continue to share specific, candid feedback — even the hard parts. That’s exactly what we need to hear to make meaningful change
improve the visual studio debugger to work properly with drivers, eliminate windbg
since the wdk depends on a specific version of the sdk, bundle the wdk as part of the sdk
wdk development should be selectable directly from the visual studio installer, not a hodgepodge of addons downloaded later that need lots of tweaking. a new mindset is needed to tune internal processes to the customer, not fitting customers to bad processes.
all wdk header files should be /Wall clean
all wdk header files should compile in usermode in addition to kernel mode. It’s ridiculous to fork things like storport.h and scsi.h to have the same things inside, but different.
should not need to manually add $(VC_IncludePath) to the additional include directories in order for c++ code to compile
useful and safe language features should not result in unresolved externals like for example certain usages of std::min
remove the requirement to sign drivers. attestation submissions take hours of frustrating waiting and achieves nothing for the isv or the customers according to each. EV code signing has become an ever higher chokepoint that will continue to get worse and yet no one at microsoft has seemed to notice or care. No one evaluates the dark side of signing in that it makes it harder for legitimate businesses to do their job, discourages developing for the windows platform, slows down time to market, and saps time and resources that would otherwise go into making the windows platform better. One only needs to look at this forum to see how frustrating the process has become.
A great sentiment. I can only continue to hope that it will someday be backed by action in favor of the community.
The usability of the entire driver development process has very significantly declined over the last decade, to the point where the whole process is downright hostile to third parties. Time after time we’ve raised issues that are importantly to the community in constructive ways, only to have our efforts rebuffed. If you all (Microsoft overall, not the people on the WDK team specifically) are serious about wanting to partner, you have to give us some of the things we’ve been asking for, and not just ignore everything we say.
Consider the fact the older versions of the WDK and EWDK are being taken offline. We’ve made it very clear that this is not helpful to the community. The result? Kits are even more aggressively bejng taken offline.
Can we not have a web page that’s updated regularly, that describes WDK releases — when a release happens, what’s changed, etc… and that has a constantly updated list of known issues? Maybe, gasp, email when a new version of the WDK drops? That used to be a thing, you know… emails about the kits team.
Consider how many times (Tens? Hundreds? Thousands?) we’ve described how very important down-level support is to the community. How MSFT can “wish away” old Windows versions but our customers and their customer cannot. The result? Nuthin’…
@chuckchopp is absolutely right about testing the WDK with every supported platform. I don’t frequently agree with @Rourke, but what he says about installation is on point. The process is as annoying today as it is frustrating. And @Tim_Roberts is of course correct when he talks about the utility of Driver Developer Conferences… from both sides. I know big, multinational, gatherings are less of a thing now… but maybe create a track at Build or something?
The EWDK is a great thing. Truly. Why is it that some things build in the EWDK and not VS and vice versa? Why are the properties not exactly the same?
The NuGet WDK is terrible for many reasons, not the least of which is the security implications. It is a bad idea, and I am terrified that it will become the defacto standard sometime in future.
I’ve come back to edit my initial post here to add a note about the WDK documentation. The docs… it’s actually pretty meaningful that doc issues weren’t one of the first things that came to my mind to complain about. They still lag badly behind the OS releases. They still are inconsistently technically correct, mix technical truths with Microsoft policy, and too often serve to drive some PM’s agenda rather than being maximally transparent or helpful. They still lack architectural insight and fail to consistently articulate device models within an overall framework of the I/O subsystem. And the docs related to particular device stacks often leave a LOT to be desired. OMG… ever try to write a StortPort driver for a contemporary NVMe drive? Don’t. It’s impossible trying to use the docs alone.
When’s the last time we had any progress or evolution in WDF? I mean, aside from the addition of new device-specific class extensions (which has been pretty great, by the way). As I’ve pointed out once or twice (for 20 years) there’s still work to be done on WDF, still rough spots that trip up new learners.
The signing process… gosh… that could be a whole book of issues, couldn’t it? Why can’t support for driver signing be more visible and available? At OSR I admit that we’ve been fortunate (so far) that our dashboard accounts have continued to work, thank God. But when people have trouble with dashboard accounts, with interpreting a diagnostic message related to signing… why is there nobody — really, nobody at all… for months at a time — to help? Why on earth do the signing rules keep changing? Why do the program rules for dashboard accounts keep changing? And most of all, why doesn’t anybody document what’s going on accurately and contemporaneously? Why do I have to login to the dashboard to read a pop-up about some sort of mysterious credentialing process that threatens me with a 16 October deadline? Does the dashboard not have a list of emails for people with accounts? Can the PM not figure out how to create a web page and post information?
OK… I’ve already gone on too long, and I’ve repeated things I’ve said many times over. So, let me wrap this up.
I think I’m in a unique position to have insight into both the community — cuz I’ve lived in it for 30 years now — AND Microsoft, because I spent several years working on campus as a consultant to the WDK team and de-facto DDK/WDK architect. What MSFT needs is one sufficiently senior person who is responsible for the end-to-end Windows driver development experience. One person who’s truly motivated to reduce friction for IHVs, ISVs, and OEMs that want to use Windows to enable their devices. This person needs to own things from “How do I connect my device to Windows” to “This is how you use the WDK” to “This is what’s in the docs” to “This is the framework for driver development” to “This is what you need to do to sign and/or logo your device/driver and deliver it on Wu.” One person (probably at the director level) who can say “I am personally committed to ensuring Microsoft’s policies and infrastructure serve the 3rd party hardware and driver community in such a way as to make Windows the easiest and most preferred platform for device connectivity and enablement” and deliver on that promise. THEN… You need devs who understand windows architecture and kernel mode development, and can effectively rep for the community to the devs who own the OS components (and vice versa), track changes in the OS that affect 3rd party drivers, regularly work and interact with devs in (what used to be called) core and the device teams, and step to them when they get out of line. You need PMs who can effectively oversee and untangle the stew that is VS, the linker and compiler, the WDK integration, and the headers and libs and make sure it actually works and keep the community in the loop. You need PMs who can make the entire driver signing. experience work for the community. And you need a PM whose entire job is to communicate, full time, both ways between MSFT and the 3rd party driver development community, keeping all the stakeholders informed on both sides.
[later edited to add] Sigh… Reality check: I realize this is fantasy and would require a corporate commitment that Microsoft is extremely unlikely to make in this age of “AI first” and “Windows doesn’t make us any money.”
Yes. No tool should ever go away. EVER. I have talked before about one of the mindset disconnects that happens in Microsoft. The people in Redmond are all living in the future, although they often don’t know it. They are all using Windows Version X+1, which is not even available yet. To them, Windows Version X is a solved problem and an uninteresting legacy system. It does not even occur to them that customers still have production machines running Windows 7. Often, those machines are in industrial processing systems, which require custom hardware that needs custom drivers that sometimes have to be modified.
This, sadly, is one reason why we advised our telemetry clients to move to Linux. Today, I can still check out and build a Linux kernel from 2005 and all the tools to support it, if I should need to support some ancient client.
Peter’s and Tim’s comments are a lot of the reason I retired a number of years ago. Many of my clients were telecom, medical or unique manufacturing vendors. In all the cases they could not move quickly from one version of Windows to another, medical and telecom have cycles up to a decade to get a device approved. Manufacturing just wants a device that works and not having to worry about chasing technology (some of the vendors I supported still had to deal with relay ladder logic with real relays!).
One of the final straws on Windows was for a client of mine who took 10 years to get their device certified world wide, only to find that Microsoft wanted to nullify an agreement that they could keep paying royalties on NT4 Embedded and wanted them to move to the latest system which would have destroyed their profits (because of the cost of starting certification over again).
But when people have trouble with dashboard accounts, with interpreting a diagnostic message related to signing… why is there nobody — really, nobody at all… for months at a time — to help?
This is the situation that I’ve been dealing with in with a driver signing issue and the HLK since May of 2025. I’ve got an HLK test failing only on Windows Server 2025 (x64), but passing on the other x64 builds of Windows where it’s called for in the appropriate HLK version-specific playlists. The same test, for whatever reason, isn’t in the ARM64 playlist. The filters don’t provide a mitigation for the test failure, either. As a result, when uploading the x64 and ARM64 builds of the driver in their associated HLK packages, the ARM64 builds are automatically scanned and get certified & signed in less than 24 hours while the x64 builds show a warning that a manual review process is in-progress and they don’t get certified & signed until approximately 5 to 7 days later.
The lack of availability for HLK support is a hindrance in this case. What’s maddeningly frustrating is that there is absolutely nothing provided by Microsoft to state exactly why the x64 build of the driver must go through a manual review process with nothing suggested about how to remediate the issue. And to just make matters worse, there’s no option to make contact with Microsoft to make an inquiry regarding the manual review process.
What’s absolutely ironic is that the driver being tested doesn’t implement any functionality that would subject to being exercised by the test that is failing only on Windows Server 2025 (x64).
The HLK itself is one hot mess of a dumpster fire all on its own, too. The only “product” from Microsoft that I’ve found to be more kludgy and less friendly to set up is SCCM. There’s no concept of an “upgrade”; everything is simply “wipe it out and start from scratch” each time there is a refresh of any given version of the HLK. The pre-installed virtual disk images don’t allow for things like renaming the system to fit into an existing network environment, nor does the HLK allow for renaming of a computer. Post-installation configuration steps required to be taken for certain tests to be executed are often buried in obscure locations in the documentation, leading to failed tests and then having to ferret out what remedial steps must be taken to make the HLK client system capable of performing the test. I find that the URL links in the HLK manager & studio are frequently broken or refer to documentation topics that aren’t helpful. The entire UI for the HLK looks “so 30 years” ago that it’s not funny. Not being able to have a single HLK Controller at the current highest version which can support all current & down-level HLK clients is a huge pain-in-the-*ss, too, which results in VM bloat and consumes a lot of extra resources on my VM host. I’d love to hear a rational explanation as to why I cannot have a single Win2K25 HLK Controller which can support all of the HLK clients installed on Windows Server 2016, 2019, 2022, 2025 and Windows 10 & 11 (various feature updates).
Thanks Peter and all the others, can't agree more!
Why, out of the blue, without any notification, do we have to do this "mysterious credentialing process" in the first place? Even we have a valid hardware dashboard account for years? Why do we have to upload our IDs and facial photos to some mysterious 3rd party identity provider? That's a serious privacy issue! (Fun fact: I got validated but with the wrong postal address, so it’s just worthless compliance without any additional security).
I thought that's why we need EV Codesigning Certificates, remember EV stands for Extended Validation. We already paid a lot of money for our validation at another 3rd party provider! What's next: Uploading fingerprint scans, confirm our gender and religious preferences?
Why is the Microsoft Authenticator app, which is required for this painful process, not respecting Android 3 button navigation and hides the submit button behind the general OS navigation controls so you don't see it and you can't submit?
We all have to write Windows kernel drivers extremely careful with triple checking and testing everything so we don't crash Windows with a BSOD. That's hard work, every single day! Why can't we get the same respectful treatment from Microsoft, a company that earn more billions than ever?
I’ve already filled out the survey a while ago but just realised I have something to add, @Paul_Eze - currently going through the process of converting our build system to use the WDK Nuget package (but without the nuget). I see that redist files are missing from these packages, specifically we rely on sourcing offreg.dll from somewhere. We would love to not have to use the MSI installable WDK, but since this redistributable is not in the nuget package, I would still have to set up some other CI job or process that extracts this file from an administrative install of the WDK (or something similar) and repackages it with our in house package manager.