Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


20.04 WDK is borked if you need to submit a DVL.

Mark_RoddyMark_Roddy Member - All Emails Posts: 4,336

Just a heads up: WDK 10.0.19041.1, the latest released WDK, has a runtime error feature when attempting to create a driver verification log for HCK certification. This is doc'd by MSFT here: https://social.msdn.microsoft.com/Forums/en-US/96c770a9-19a3-42d0-8d0e-bd200285d980/hardware-development-kits-for-windows-10-version-2004?forum=wdk "DVL generation fails with System.IO.FileNotFoundException".

For now, stay with the 19.03 WDK.

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,854
    edited June 14

    LOL... Nobody here as been able to get SDV to work AT ALL. For any project. In the 2004 WDK.

    I’m sure glad we’re not using razzle anymore and we have VS integration. Everything works so well together and is so very thoroughly tested.

    Peter

    Post edited by Peter_Viscarola_(OSR) on

    Peter Viscarola
    OSR
    @OSRDrivers

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,336
    via Email
    I'm pushing everyone here to move off of Visual Studio as a driver dev ide
    and to use the EWDK with Code instead. The ancient DdkBuild is slowly
    getting resurrected as a powershell script that integrates with VSCode and
    runs from, good grief, a command line too, invoking the actual build engine
    (msbuild) and bypassing the now truly awful Visual Studio.

    Mark Roddy
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,336

    Oh and I'm fine with SDV running 0 tests. We just need the log.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,451

    Yes. Maybe it's different if you live in the IDE and the DLLs are cached, but for me, I can bring up gvim (or VSCode), make a change, compile it, find an error, go back into the editor, fix the error and compile it again in the time it takes Visual Studio to bring up its splash screen.

    VSCode is making me a believer. I can't believe I'm being lured away from gvim by a web app.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,854
    edited June 8

    I'm pushing everyone here to move off of Visual Studio as a driver dev ide and to use the EWDK with Code instead.

    As much as the quality of VS is a shameful and horrific moving target (just what you want for a tool that you rely on to make a living, right?), I can't live without ReSharper... or at least Visual Assist X. Yes... even in C++. These tools just provide too many nicely integrated helps and checks for me. And the clang-tidy checks are awesome. I'm "one of those people" who just glory in the dots and squiggles and underlines and lightbulbs and shit that "help" you write better code.

    Having said ALL that... I've never heard anybody say they hated VSCode. I've heard a LOT of people say that VS pisses them off. Heck, VS pisses ME off.

    Peter

    (Tim: Double-clicking a driver solution in VS 2019 to having an editable code window in VS: Less than 9 seconds by actual count. On my HOME machine. And this is not a project on which I'm actively working. Yes, this is on an SSD. I don't know why you get such bad performance.)

    Peter Viscarola
    OSR
    @OSRDrivers

  • Michal_VodickaMichal_Vodicka Member - All Emails Posts: 89

    I don't know why you get such bad performance.

    I have bad VS performance, too. Maybe not so bad as Tim but bad enough. It takes tens seconds, maybe a minute, I've never bothered to measure it as I use it only if there is no other possibility. VS 2017 and it was so since the very beginning even before installing WDK.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,451

    I just ran VS 2015 for the first time in several weeks. The splash screen comes up in 2 or 3 seconds (so I exaggerated), but it was 3 minutes before the IDE was ready to accept clicks. That's not really fair, so I killed it and tried again immediately. The splash screen was up at 0:03, the main window painted at 0:50, and the menu responded to clicks at 1:05. On a processor that's doing 3 billion operations a second, that's a heck of a lot of computing.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,854

    it was 3 minutes before the IDE was ready to accept clicks

    THAT is frightening, and frankly unusable.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,300

    OK, timing Visual Studio launch times beats working...When the WDK first came with VS2015 I found it to be horribly slow and decided that I was way more efficient with SlickEdit and the command line. Newer versions are much better though and I've completely lost my passion for that argument.

    For example, I just double clicked a solution with two projects and VS2019 was entirely usable in 12 seconds. This system isn't anything terribly special: Xeon Bronze 3104 1.7GHz, 16GB RAM, 1TB SanDisk Ultra SSD.

    -scott
    OSR

  • Michal_VodickaMichal_Vodicka Member - All Emails Posts: 89

    Hey, Scott, you're very experienced developer. You know well "works for me" or "can't reproduce" isn't an argument. It always depends. On something which can be very simple or really strange. I've seen crazy things and I'm sure you did, too. Everybody involved in this discussion is able to find it out but why bother? It takes time and usually a lot of time. Personally, I'd try it only if I have to use VS every day. Which isn't a case, fortunately.

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,300

    I in no way condone, support, or suggest anyone try to root cause their VS performance issues. I am also in no way suggesting that the everyone else is wrong and VS is the greatest piece of software ever written. Just throwing in my experience that while VS being slow used to be high on my list of reasons to dislike VS it is now no longer in the top 10 :)

    This thread did inspire me to at least install VSCode and see what the fuss was all about. It installs with Dark Mode as the default theme though so it might be a bit to hip for me...

    I think I have now finished the derailment of this thread. Stay healthy everyone!

    -scott
    OSR

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,336
    via Email
    It isn't really a derailment Scott.

    Let's start with the fact that the WDK continues to be an afterthought
    appendage to visual studio, so that crap like the screwed up release of the
    20.04 WDK just flies under whatever quality gates are in place.

    The WDK, and in fact C/C++ development are not the focus of VS anymore, and
    haven't been for quite a while, and it shows. If you are developing for C#
    VS is the right tool. I no longer think that is even remotely true for
    C/C++.

    The EWDK goes back to what was really good about the last few releases of
    the pre-vs-integration WDK: a self-contained toolchain released on a
    'slow-lane' release cycle, well suited for CI/CD integration (and even
    k8-erization), and easily integrated with any code editor/ide.

    Mark Roddy
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,451

    VSCode is pretty hip, for better or for worse. It is an Electron app, which means it is a Javascript web application running inside the Chrome browser. The window itself is owned and managed by Chrome. Ordinarily, that would cause me to laugh heartily at the foolishness, but I have to admit they've suckered me in. I find myself reaching for it instead of gvim. I really like the whole project view, and I like that features are discoverable.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,300

    @Mark_Roddy said:
    It isn't really a derailment Scott.

    Let's start with the fact that the WDK continues to be an afterthought
    appendage to visual studio, so that crap like the screwed up release of the
    20.04 WDK just flies under whatever quality gates are in place.

    +1

    There was a released update to VS2019 that was seriously hosed for building drivers. It was great fun to feel like I was the first person who had ever tried building a driver using that particular toolchain...

    The EWDK goes back to what was really good about the last few releases of
    the pre-vs-integration WDK: a self-contained toolchain released on a
    'slow-lane' release cycle, well suited for CI/CD integration (and even
    k8-erization), and easily integrated with any code editor/ide.

    The EWDK is a great thing. We ended up not using it for CI because it choked on the user mode components of the driver projects we were working on at the time. I don't at all remember the details but probably worth going back and seeing if things are different these days.

    -scott
    OSR

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,854

    The EWDK goes back to what was really good about the last few releases of the pre-vs-integration WDK

    I agree that the EWDK is a good thing. Nobody could argue that.

    However, the EWDK is still missing what I valued as the best features of the old (pre-VS-integration) WDK. That is the synchronization of the tool chain with that used to build a given OS release, FREEZING that tool chain in place for the lifetime of a Windows version, and the extensive testing that tool chain received, from end to end, before it found its way into the WDK.

    The old WDK included build tools and a compiler and linker that had been tested tens of thousands of times (at least) before release, because it was exercised every day, by every MSFT dev, every time they built something for Windows. And there was ONE actual, specific, guy whose responsibility it was to worry over the features and options in the stable compiler and stable linker, and be certain that those features worked properly to build a working OS (sometimes with secret-sauce in the form of undocumented switches and options, but we'll ignore this for now). AND there were people who tested the "about-to-be-released" set of OS-version-specific headers/libs with the stable compiler and stable linker to be sure everything worked together, and produced working drivers for Windows.

    When a version of Windows was about to be released, the entire tool chain that was used to build that version of Windows was frozen... and THAT was the tool chain that was distributed in the WDK and used to build drivers for that version of Windows forever.

    THESE days... you get a random compiler, a random linker, a random set of build tools, and some headers and libs that correspond to SOMEthing I'm sure but I have no idea what. And these tools are improved and gain features at a random rate, and for random reasons. Yes... the EWDK removes this last bit of random change. And that can avoid a source of annoyance and frustration of the "my build environment stopped working sometime between Monday and today" sort, which DOES... I admit... happen frequently.

    But when I long for the old days, I long for the long tested, well-proven, One True and Everlasting Tool Chain, for use forever for a given version of Windows.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,854

    And then we have this:

    fatal error C1252: Circular or missing dependency between plugins: 'PREfast Drivers Plugin' requires GUID '{EB170136-3433-4C16-AE1D-8998BA5CAB16}'.

    Which is (at least part of) what started this whole mess. Command line, EWDK, or in VS... can't run SDV no how, no way.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MBond2MBond2 Member Posts: 128

    Have you ever worked with MDAC? All of these complaints are old hat; not that they may not be valid, just that you know, evey other paradigm of devleopement has handled this same problem at some point

  • RourkeRourke Member Posts: 53

    Did it ever occur to anyone to report one of these glaring problems to Microsoft and have an expectation they would make a fix?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,854

    Did it ever occur to you that some of us talk with the folks at MSFT regularly?

    Did you read the link Mr. Roddy posted? Did you not see that it’s BY a MSFT person, who is kindly keeping the community informed of existing WDK issues?

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,336
    via Email
    Actually it isn't just the 20.04 wdk. At least the prior release also has
    the busted dvl.exe. At the moment the only thing working for me is the EWDK
    from last year.

    And yes I did obviously check to see if this was a known issue. Not that
    msft makes it particularly easy to figure that out. (Nor do other closed
    source software companies.)

    Mark Roddy
  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,336

    It isn't just start times. It is, in no particular order, and off the top of my head:

    • poor integration with VStudio, for example the WDK continues to not be available like normal components from the installer.
    • over-complicated project templates that make standardized settings for large projects more difficult than they need to be.
    • ridiculous rev locking. I get why I can't build up-rev WDK projects with down-rev VS, but I should be able to build, without modification, down rev WDK projects with up-rev VS.
    • steering developers to wrong approaches - like for example the awful driver debugging in VS and the awful workflow of that interface.
    • arbitrary UI changes - in VS2019 the 'Driver' menu option disappeared from the top menu and migrated to the drop down Extensions menu.
    • gargantuan size of VS. Even the allegedly stripped down toolset of the EWDK occupies 2G.
    • we've moved back to a commandline/api world, and away from over-complicated all-purpose gui behemoth apps
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,854

    Mr. @Mark_Roddy ... there is nothing in your list that I do not agree with.
     
    I mean, I personally couldn't care less about the size of VS or about where they put the "Driver" menu. But your complaints are certainly valid.
     
    What I want and value most, above all those things, is an easy, powerful, and helpful coding interface. This is probably because I am either lazy or stupid... but when I create a function:

         void
         fred(int bob) {
    
         // rest of code here 
    
         }
    

     
    I love it when my editor tells me that I should probably make it:

         void
         fred(const int & bob) { 
    
         // rest of code here
    
         }
    

    That's, of course, a ridiculous simplification... but I hope you get my point.
     
    For this kind of help, and an interface that lets me move easily from KM C/C++ to UM C/C++ to UM C# to UM Python or whatever... I'm personally willing to ignore, if not forgive, a great deal.
     
    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MBond2MBond2 Member Posts: 128

    but clearly it should be like this so the warnings will have been effecive at improving your style

    void
    fred(int const bob) {

     // rest of code here
    
     }
    
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA