I have pontificated before, and at some length, about the fact that Microsoft has returned to its former position of actively wanting to engage with the 3rd party driver development community. This attitude is as commendable as it is welcomed.
What’s most encouraging is that MSFT folks appear to be listening to the various feedback channels, and taking action on the feedback they receive. Take for example the issue with a recent Windows 7 update: the symbols for the update were published to the MSFT symbol server fully stripped and without the symbols for the data types added back in to them. This made debugging with those symbols (cough cough) “very difficult.” A community member sent email to the debugger feedback alias (did you even know there was a debugger feedback alias? I didn’t), and apparently heard back that the problem was being investigated. So, when I heard about this problem, I made a nuisance of myself and asked a buddy of mine who happens to work in a relevant team at Microsoft if he knew what was up. I expected to have to explain the problem to him in detail, and ask for a favor to get the problem fixed. But much to my surprise, I discovered the relevant folks at MSFT already knew about the problem and were already working on a fix (that entailed a ton of manual work, unfortunately). And, guess what? A couple of weeks later, the fix was implemented and the updated symbols were on the symbol server. Yay!
Yes, that’s just one small example, about a single item. But there are examples that tour concerns are being heard on much larger issues as well. For example, in talking with the WDK program managers I’ve learned that there’s an ongoing demand for better and smoother integration for all facets of development with the WDK within Visual Studio. This includes better integration of the debugger and test system setup. I’ve also heard that community feedback regarding the difficulty in using some of these features lead the WDK team to make significant changes in the Windows 10 WDK in how test system setup is implemented. Now, you can’t prove any of that by me, personally… because I still can’t get test system setup or driver deployment to work from within VS. Not that I want to, to be honest. But now, apparently, some people actually can get this to work. And they can even get it to work with some of the IoT-based platforms, which is pretty cool and even potentially useful.
But before you start singing Kumbaya and propose a big group hug, there’s much that needs improved. For example, how does the community know – as a whole – that our feedback is valued, is being heard, and is being considered for action (or even has been considered and rejected)? A quick look at my examples above demonstrates one of the current mechanisms. The only way the community knew that the fix for the stripped Windows 7 symbols was on the way was because I heard about the problem, asked a buddy of mine about it, and when he gave me the scoop I posted something to our WinDbg forum. And I happen to know about the whole issue of VS integration and deploy, because – well, to be honest – I’ve been complaining about this feature for years and I happen to know some of the right folks to complain to. And I’ve told you about it here.
As the complexity of the WDK increases, as the number of platforms supported by Windows continues to multiply (RPI 2 with Win10 IoT Core, anyone?), and as the integration between the WDK and Visual Studio gets tighter, the chances significantly increase that one of those complex, tightly integrated, things will go wrong on at least one of those platforms. That means that the community’s feedback is even more crucial than ever. And it means that sharing that feedback, and MSFT’s response to that feedback, broadly among the driver development community becomes vital. This prevents the world over from discovering various problems individually and wasting time struggling with them.
Now, to be fair, there are numerous feedback mechanisms that the community uses today to “get the message” to the right folks at MSFT. I mentioned the WinDbg feedback alias, above, as one example. Another similar method is the link at the bottom of every WDK documentation page that says “Send comments about this topic to Microsoft.” That feedback link actually works. Or, at least, it certainly has in the past.
WDK Developer Support has historically been one of the most common, and effective, ways of providing feedback on the driver kit. Staffed by a group of folks that are, in my experience, both knowledgeable and helpful, when you have what seems to be a WDK problem contacting WDK Developer Support remains one of the best options for getting your issue handled. The only problem is, you contacting developer support helps you, but doesn’t really do anything to let others in the community know about your experience.
One of the most effective mechanisms for providing feedback on the WDK and getting status back on that feedback is also probably also one of the least known. That mechanism is Microsoft Connect. You just have to know where to look!
Go to http://connect.microsoft.com/VisualStudio/Feedback and enter “WDK” in the search box. After a while (what seems to be an eternity with the “Please Wait” graphic) you’ll see a list of outstanding WDK issues. See Figure 1 for an example. There’s no tags or standard keywords (why?) so, to be sure you’ve seen all the issues you have to search on “driver” as well.
Connect seems to be reasonably effective, as well, because people seem to get a (semi-intelligent) response within a week or ten days. And I don’t just mean the “Thank you for this report” type feedback. I mean a reply from somebody who actually seems to have read the bug and understand the issue being reported.
Aside from that fact that people got timely feedback, probably the thing that struck me most about Connect is the lack of community-generated comments on the WDK. This either means that everyone is pretty happy with the WDK and that there aren’t many problems found, or that people don’t know about Connect and are providing their feedback through other channels.
Given that Microsoft has demonstrated their interest in our feedback, I think there’s some considerable room for improvement here on all sides. Here are the things that I’d like to see happen:
- There should be a central place where members of the community can report WDK bugs or issues. If that’s Connect, fine. But (Connect is so horribly slow and) it really has to be easier to separate the WDK-related problems from the vast collection of VS problems. Maybe that means there should be a separate (public) feedback program for the WDK. Maybe all that’s needed is a distinguished keyword or tag in Visual Studio’s feedback program that’s added by the MSFT reviewer. But there needs to be something.
- There similarly needs to be a place where community members can see the list of problems or issues that are outstanding in the WDK. It would be most helpful if that list was not confined to just the issues submitted via Connect, but rather included issues found in internal test, issues reported via WDK Developer Support, or other methods. This is key to helping folks make the best use of the kit, and have confidence that issues are being heard and handled.
- The community needs to step-up and report bugs and issues when they find them. They need to ensure that the bugs and issues that are reported are reported clearly, in a way that they can be understood and replicated by whoever reads the bug. It never ceases to amaze me how very terrible, how unclear, and how non-specific some of the bug reports I see are. These are bug reports filed by actual devs. If you’re a dev, and you’re filing a bug report, please think carefully about the data that you would need in order to fix the problem you’re reporting. As the Good Book says “Report bugs unto others as you would have them report bugs unto you.”
While it’s non-traditional, what I’m asking for shouldn’t be impossible. These days, there are numerous companies that have their real, live, honest-to-goodness internal bug tracking system online and accessible by the public. I’m not saying these companies don’t mark some bugs as “Internal Only” – of course they do. But having this level of openness is a real win in terms of establishing a great relationship between a product team and the community they serve.
Hey… A boy can dream, right?
Peter Pontificates is a regular column by OSR Consulting Partner, Peter Viscarola. Peter doesn’t care if you agree or disagree with him, but there’s always the chance that your comments or rebuttal could find its way into a future issue. Send your own comments, rants or distortions of fact to: PeterPont@osr.com.
Corrections:
A previous version of this article incorrectly stated that a community member sent email to the WinDbg Feedback Alias and did not get a reply. He indeed did get a prompt reply indicating that the problem was under investigation. We have updated the text to reflect this correction.
OSR Open Systems Resources, Inc.