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

Home NTDEV

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/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Building drivers with Visual Studio 2022

RourkeRourke Member Posts: 70

Is vs2022 supported for building drivers at this time and if not is there an idea when it might be? It is surprising the WDK download page has no mention of vs2022 either way as guidance for developers.

vs2022 is the first visual studio ever that is 64-bits. VS can run in a web browser so you can develop code without installing anything. Quite a few other nice features included.

«1

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784

    There will be a new WDK that works specifically, and solely, with VS 2022. As of this writing, it has not yet been released (VS 2022 was only released today)… but I expect it to be released soon.

    The new WDK will bring with it new features as well as some new restrictions. Having said that, I’m expect we here at OSR will be sticking with the VS 2019 Windows 11 WDK for “a while.”

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,163

    vs2022 is the first visual studio ever that is 64-bits.

    That has exactly zero impact on a developer's life. It's an implementation detail, not a feature.

    Driver writers generally do not want to live on the cutting edge, because the cost of even a small compatibility problem is so high.

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

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,470
    via Email
    Do yourself a favor and switch to the latest EWDK toolset for building
    drivers. These releases are all 'LTS' and do not suffer from the plague of
    chronic iteration update syndrome that has enveloped most software
    development.

    You can even rid yourself of the massively bloated Visual Studio and use
    something reasonable like vscode or emacs or whatever source editor floats
    your boat.

    Mark Roddy
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784

    The EWDK can be a massive simplification, and is greatly under appreciated and under utilized.

    Having said that, if your Solutions include both drivers and (anything but the simplest) user-mode code, the EWDK is not a solution that’ll work for you.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,470
    via Email
    So in the case where, for example, you have .net projects and driver
    projects, just separate those into two 'solutions' and build them with
    their appropriate toolsets. The build requirements for .net and the rest of
    modern userland is vastly different from the requirements for legacy c/c++
    driver and service development. Mixing those two is generally a Real Bad
    Idea.

    Mark Roddy
  • RourkeRourke Member Posts: 70
    edited November 10

    @Tim_Roberts said:

    vs2022 is the first visual studio ever that is 64-bits.

    That has exactly zero impact on a developer's life. It's an implementation detail, not a feature.

    It seems you are only thinking in terms of address space, but not considering x64 speed improvements. People who don't examine machine code or were not there at the time may not know that when AMD invented x64, they didn't just add address space. They also added a bunch of brand new CPU registers to the instruction set. Everyone knows the more you can do in registers the quicker your code will be. And 64-bit wide registers also offer more performance advantages over 32-bit registers. Thus, it is no surprise that going 64-bits MS boasts faster loading and better UI performance, attributes people here have complained of on numerous occasions. Thus, vs2022 being 64-bits offers a compelling feature for driver developers who are tired of waiting 10 seconds for their 10K driver project to load.

    Post edited by Rourke on
  • craig_howardcraig_howard Member Posts: 226

    Visual Studio is slower than a turtle stampeding through molasses on a cold winter day not because it is 32bit, it's because they insist on creating impossibly sized data structures as "features" and then dig through those for every project/ solution load. It's not uncommon for a project .vs file to be hundreds of megabytes, sometimes gigabytes in size.

    Moving to 64bit, or 128bit, or 256bit won't affect solution/ project load times one bit because those huge "feature" databases live on the disk that gets read back and forth; the biggest performance increase you can do is get a fast SSD or a memory cache such as PrimoCache. Same with build times; the bottleneck isn't in the address space, it's in the disk thrashing and same solution; fast SSD or memory cache

    Given MS's track record as of late with releasing development studio's (such as this [ https://community.osr.com/discussion/292924/rtlstringcchprintfexw-vs-snwprintf ] or the bug that OSR found with ExAllocatePool2 where a block of memory that was supposed to be cleared wasn't and for software releases in general, like Win11 being released with expired cert's on some of it's programs, I'm looking forward to VS2022 about as expectantly as I am the next change in the tax laws ...

    VS2019 has been out for almost four years now and is still getting nearly weekly updates as they fix things; I'm glad that you're going to be using VS2022 so that you can step on all the landmines rather than me. I'll probably shift to it a) when it has a feature that actually makes a difference and b) after a few dozen updates are under it's belt ...

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784

    We (OSR) are usually among the earliest of adopters, so we can let the community know “how it goes” and… well… just cuz it gives us something new to play with.

    But we’re going to be holding off moving to VS 2022 for “a while.”

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MBond2MBond2 Member Posts: 389

    The fact that MSFT release frequent updates to VS 2019 does not really imply that it is any buggier than any other software. It simply means that they release frequent updates.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,470
    via Email
    " The fact that MSFT release frequent updates to VS 2019 does not really
    imply that it is any buggier than any other software."

    The entire industry is obsessed with continuously releasing updates to
    everything. It isn't that VS is particularly buggy, instead software
    engineering has been infected with a process-virus formerly known as
    'agile'.

    Mark Roddy
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784

    What Mr. Roddy said.

    This continuous release shit is a curse. Maybe it’s awesome for some amusing web app. But when it impacts your fundamental tools, and causes you to have to reboot your machine once a week as an added bonus, it’s ridiculous.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • RourkeRourke Member Posts: 70

    Nothing is more disruptive than windows updates. Updates can break fundamental contracts with device drivers and invalidate testing without notice. Updates rudely shut off machines without giving the user a chance to stop it from happening resulting in data loss of running apps. How is this acceptable? Windows updates also have the audacity to turn on a machine arbitrarily if they so choose. Again, how is this acceptable? Windows updates as a whole are unwelcome and show a lack of care and lack of ability to get it right the first time.

    VS updates on the other hand are welcome. They often add improvements that are noticeable and worthwhile. Over the last year for instance they slowly rolled out c++20 language features rather than waiting a year and dumping them all at once. Thus, we were able to start benefitting early on each incremental improvement. Unlike Windows, VS updates are totally optional, come with clear and easy to read release notes, and are performed only by specifically clicking if and when you want to update.

    This is a very strange thread. Microsoft announced they made vs2022 faster, something everyone wished for, and oddly that angered a lot of folks to jump in and start bashing away.

    I also want to add a voice that not everyone likes the bad old days of non-visual studio development or the EWDK incarnation of this dinosaur methodology. Hey, some may prefer going back to a Dos prompt and running edlin. More power to you. Most I would imagine have moved forward and tapped into many productivity advantages developing drivers using VS. I have done both and am firmly in the latter group.

  • MBond2MBond2 Member Posts: 389

    I agree completely except for the word 'engineering'. Engineering is not being done when a new release updates the icons and the colour scheme.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,470

    "I also want to add a voice that not everyone likes the bad old days of non-visual studio development or the EWDK incarnation of this dinosaur methodology. Hey, some may prefer going back to a Dos prompt and running edlin. More power to you. Most I would imagine have moved forward and tapped into many productivity advantages developing drivers using VS. I have done both and am firmly in the latter group."

    I kind of like VSCode a lot. I see no reason why I need Visual Studio at all for driver or service development. And if I was writing web/cloud app/stack shit the bloaty studio is also about the last tool I would opt for. The point is that what ide you are fond of really ought to not depend on what tools you are building with.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784

    @Rourke that’s a classic “straw man” argument, you know? We complain about VS updates, and you counter that Windows Update is terrible. Awesome point.

    It is hard to argue, I think, that having a big, powerful, IDE that does “everything” is not convenient. It certainly is. As I have said many times before, I am totally addicted to ReSharper for C++ and my code is better for it.

    But I’m sick to death of the constant updates, of never being able to count on the behavior or usability of the strange, obscure, and annoying pile that is Code Analysis, and the random breakage of vital components in my tool chain. I’m tired of the constant regressions in the IDE, where parsing breaks, chroma-coding fails, or some weird situation or another requires that I exit and restart the IDE for a given Solution.

    I don’t like building my drivers with arbitrary, ever changing, versions of the compiler… a version which is not the same one that was used to build the operating system. I don’t like headers and libs that are “shared” changing arbitrarily.

    The WDK is saddled with this mess, and trying to get what should be little things fixed requires negotiation with the behemoth that is “the people who own VS.”

    Having tried vscode, the only things I can say in its favor are it’s extensible, and it’s not vim.

    In short, I think MSFT has fucked-up VS and CA… making it all things to all people but not really ever fully working for any one use. And the WDK get layered, like peanut butter, on top of this pile. And it makes it hard for me to get my work done.

    Is the VS editor, with ReSharper, better than CodeWright or SlickEdit (what I used to use before VS)? Tough call, but probably. Does that make it a joy to use on a daily basis? Not even close.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Max1338Max1338 Member Posts: 1

    @Mark_Roddy
    Are you using EWDK with VSCode ? If so would you mind telling me what I need to configure so that VSCode has access to the additional headers etc. ? As currently it automatically falls back to my VS22 install for includes and the compiler.

    PS: I am currently trying to get my hands into Driver development and test some stuff. I had to update to VS22 to get some .NET features that are not available in Rider yet and also VS is super slow and creates super big index files etc. So I am not super familiar with the whole WDK environment.

  • craig_howardcraig_howard Member Posts: 226

    One very large problem with the constant stream of updates is that it makes the whole regression testing thing much more difficult ... if there is a new problem found, is it the fault of the driver or a new "feature" of the OS? Before you immediately say "driver", let me remind folks of the break that required _NO_CRT_STDIO_INLINE to fix, or the "allocate and clear" function that the OSR folks found didn't exactly "allocate and clear". Now I get to have to verify that the compiler isn't broken in addition to verifying the driver isn't broken ...

    The new "update daily" thing is especially vexing with a device driver in the medical or industrial automation space, where you need to be able to reproduce that exact binary that produced the driver a bug was found in, sometimes years after it was shipped, to do proper regression testing. Back before Windows began to upgrade incessantly (and, as pointed out, if you like it or not) and VS joined the upgrade of the week club regression testing was relatively easy: use a VM to build the final production driver, once it gets signed box up that image and spin it up as needed

    Now, however, you need to watch the machine carefully because as soon as it starts up it will phone home and try to update itself, polluting the image. No problem, you say, simply air-gap the machine and that indeed fixes the problem ... until you try to debug it and need to get at the MS symbol server, which required the internet and oh look, there's another update forcing its way onto the system ...

    I'm already getting folks asking "when are you going to start using VS2022" and my response is a curt "when VS2022 has a capability that VS2019 does not and which I need to make forward progress on the project" ...

    ... sigh ...

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,470

    @Max1338 said:
    @Mark_Roddy
    Are you using EWDK with VSCode ? If so would you mind telling me what I need to configure so that VSCode has access to the additional headers etc. ? As currently it automatically falls back to my VS22 install for includes and the compiler.

    PS: I am currently trying to get my hands into Driver development and test some stuff. I had to update to VS22 to get some .NET features that are not available in Rider yet and also VS is super slow and creates super big index files etc. So I am not super familiar with the whole WDK environment.

    There are two issues here:
    1. building your code using the EWDK in VSCode.
    2. 'intellisense' for editing your code inside VSCode.

    Not sure which one you are asking about, maybe both? Anyway, I'm -slowly- working on a github repo that will doc how to do both of these things, and also how to use github to build your drivers either using github build agents or your own build agents.

    The short answer to (1) is 'write a simple bat or psh script to run msbuild within the EWDK build environment'. (2) is more complicated.

  • RourkeRourke Member Posts: 70

    @craig_howard said:
    One very large problem with the constant stream of updates is that it makes the whole regression testing thing much more difficult

    Windows updates make the situation you describe far more difficult and severe. VS updates are optional, windows updates are often force fed onto machines without notice and are known to break drivers quite badly, even if such drivers follow all best practices and have been fully tested and certified a week ago.

    I'm already getting folks asking "when are you going to start using VS2022" and my response is a curt "when VS2022 has a capability that VS2019 does not and which I need to make forward progress on the project"

    All I can say is I feel sorry for you. I for one look forward to every single vs update and often find in them great ways to improve productivity. The language and features just keep getting better. Productivity and driver quality go up.

  • craig_howardcraig_howard Member Posts: 226

    @Rourke ... one aspect of writing drivers for medical devices and for industrial applications that involve human safety as well as drivers used by the military is that every part of the supply chain needs to be certified by various governmental agencies ... for medical it's the FDA, for industrial human safety it's OSHA, for military it's the NRO.

    Each of these agencies has a vetting process that the tools used need to pass to be allowed to use, and the reason for that is blindingly apparent when you consider the number of supply side malware incursions in the open source domain, both at the library level as well as at the tool level (for apple products last year).

    If you compile your USB headphone driver with a tool that contains malware you will feel embarrassed; if you compile your driver which is running an insulin pump, or controlling an assembly line with humans nearby, or will be installed on a laptop going overseas and it contains malware then you are likely going to go to prison (that's not hyperbole, that's the way the law is written)

    As a result, Visual Studio needs to go through a submission process to each of these agencies which can take weeks at best, usually months. Every time one of these "great ways to improve productivity" where "languages and features are just keep getting better", without regard to the allocate and clear function that actually didn't that whole process has to start from scratch ...

    Again, when VS2022 has a capability that VS2019 does not and which I need to make forward progress on the project, thus justifying going through the vetting process I'll be more than happy to upgrade ...

    I feel quite glad that your industry does not have the kind of process auditing requirements and supply side vetting that my industries are subject to ... that would be the difference between driving on the streets of London and driving on a salt flat in Utah ...

    :)

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784

    @craig_howard … weeeeellll, in theory, maybe.

    In the real world, I have never… not once… found the “supply chain” for driver-related tools to have any vetting process at all. Our company has written, quite literally, many dozens of drivers for industrial, medical, and military devices. For vendors in the US and throughout the EU. Not once has a client or prime contractor told me what version of VS or the WDK to use. Haven’t even been asked or indicated that they cared (beyond something like “can I use VS 16.6 instead of 16.7, because I haven’t updated yet.”). Not once. Never happened.

    Shit, dude….I’m writing a driver right now for an invasive piece of medical equipment. I update VS anytime I want. This client , who are tops at what they do and absolute leaders in their field, couldn’t care less if I use the WDK or the EWK. Why would they? They know medicine and hardware stuff. They don’t know Windows drivers. That’s what they pay US for.

    Now, for US Govt military related work, there’s a nasty shitload of stupid stuff about where you can store your code and such and what security measures you take. But the tool chain itself? No. It’s simply not controlled.

    And think about it. Who would control or vet this supply chain for industrial devices? The answer is “nobody.”

    And the whole “go to prison” thing? Nah. No way. Not unless you lie on one of those terminally ridiculous audit forms that ask you about your security procedures. That is a federal offense.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784

    I for one look forward to every single vs update

    Oh, to be young again!

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • craig_howardcraig_howard Member Posts: 226
    edited December 2

    @Peter_Viscarola_(OSR) said:
    @craig_howard … weeeeellll, in theory, maybe.

    In the real world, I have never… not once… found the “supply chain” for driver-related tools to have any vetting process at all. Our company has written, quite literally, many dozens of drivers for industrial, medical, and military devices. For vendors in the US and throughout the EU. Not once has a client or prime contractor told me what version of VS or the WDK to use. Haven’t even been asked or indicated that they cared (beyond something like “can I use VS 16.6 instead of 16.7, because I haven’t updated yet.”). Not once. Never happened.

    Shit, dude….I’m writing a driver right now for an invasive piece of medical equipment. I update VS anytime I want. This client , who are tops at what they do and absolute leaders in their field, couldn’t care less if I use the WDK or the EWK. Why would they? They know medicine and hardware stuff. They don’t know Windows drivers. That’s what they pay US for.

    Ah, @Peter_Viscarola_(OSR) , you're living the dream! Me, I'm writing drivers to support class 2 medical devices, robotic control systems and drivers for custom hardware used by the govt and LE, all of which are covered under a little bit tighter guidelines than "we couldn't care less"

    For the FDA it's [ https://daytontechguide.com/wp-content/uploads/2018/10/20-industry-requirements-for-medical-manufacturing-industry.pdf ]. The portion of the federal code that covers my stuff is 21 CFR 820.3(l), which requires manufacturers (that would be me, manufacturing something used in the overall medical device) establishing a "Quality System" (pg 13+). That QS is covered under ISO 13485, a massive tome [ https://www.iso.org/iso-13485-medical-devices.html ] of which I have to pay particular attention to clause 4.1.6 [ https://13485store.com/iso-13485-requirements/iso-13485-documentation-requirements/ ] which covers, among other things, the tools that I use in the production of the driver ... that would be Visual Studio 2019 and it's brethern

    You probably missed it in my posting, but I never stated that the regulatory agency would specify the tool(s) I use ... I specifically stated "As a result, Visual Studio needs to go through a submission process to each of these agencies which can take weeks at best, usually months" and most of that is spent satisfying clause 4.1.6 [ https://www.iso.org/obp/ui#iso:std:iso:13485:ed-3:v1:en ] by yours truly. Specifically,

    __4.1.6 The organization shall document procedures for the validation of the application of computer software used in the quality management system. Such software applications shall be validated prior to initial use and, as appropriate, after changes to such software or its application.
    The specific approach and activities associated with software validation and revalidation shall be proportionate to the risk associated with the use of the software.
    Records of such activities shall be maintained (see 4.2.5)._

    Every single time a part of the toolchain changes, it's a new submission of 4.1.6 stuff for me ... that's what I said in my original post, that's what remains today and you're really lucky that you aren't running into that ...

    Robotic systems and systems which can affect human life are covered under a different part of federal code [ https://www.osha.gov/otm/section-4-safety-hazards/chapter-4 ], and essentially have the same reporting requirements of the class 2 medical device. The main difference between the FDA and the OSHA guidelines is that OSHA also requires you to make a risk assessment of the tools you use (which after the VS2019 "allocate and clear" function debacle y'all spotted is not quite the checkbox it used to be) which again requires lot's of paperwork ... all of which again needs to be redone for every single toolchain change.
    _

    Now, for US Govt military related work, there’s a nasty shitload of stupid stuff about where you can store your code and such and what security measures you take. But the tool chain itself? No. It’s simply not controlled.

    You're talking about SKIF rooms, which is something I don't do since I don't have the right clearances ... but most military and LE organizations follow the guidelines in NIST 800.53 [ https://en.wikipedia.org/wiki/NIST_Special_Publication_800-53 ] as a baseline, most adding a few layers of paperwork such as NIST 800.171. The main thing here is becoming "NIST 800.53 compliant" which again entails validating what you're using

    And think about it. Who would control or vet this supply chain for industrial devices? The answer is “nobody.”

    FDA controls the medical device supply chain very nicely, OSHA controls the industrial robotic device supply chain nicely, the various LE and govt agencies control their own supply chains. They are all quite capable and able to shut you down at a moment's notice ...

    And the whole “go to prison” thing? Nah. No way. Not unless you lie on one of those terminally ridiculous audit forms that ask you about your security procedures. That is a federal offense.

    Exactly ... every single document you produce and submit to the FDA, to OSHA, to the various govt and LE agencies are covered under federal law and if things go south or during an ISO audio of the client someone thinks you are omitting something or lying about something you get a visit from the FBI. You have to be very careful about what you submit to the govt and what you say to investigators, just like with a tax return, to make sure it's as accurate and as truthful as possible or you go away for a very long time.

    If on the various forms you state "I use Visual Studio 2022 but I have no idea if it works or not, I just installed the update and started using it" you're being truthful, but you won't be doing any current or future business for the company. If you state "I use Visual Studio 2022 and I have carefully examined it and tested the programs it generates for both quality, suitability of purpose and generally accepted privacy and security guidelines" you'll be allowed to continue your work, but you had better actually do that testing and be able to document it and that takes time and money ... and again, for every single update ...

    To be honest I'm actually astonished that in all the work that OSR has done it's never run into the vagarities of FDA class 2 medical, or OSHA robotics compliance, or the NIST hell-scape ... you have truly lived a blessed life!

    Peter

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,163
    edited December 2

    Not once has a client or prime contractor told me what version of VS or the WDK to use. Haven’t even been asked or indicated that they cared (beyond something like “can I use VS 16.6 instead of 16.7, because I haven’t updated yet.”). Not once. Never happened.

    It has certainly happened to me. I wrote an AVStream driver for an ultrasound probe that is used inside live blood vessels. I delivered version 1 with the Vista WDK. When I wanted to move to the better 7600 WDK for an update, I was told that would trigger a complete FDA recertification, something they did not want to undergo at that time. Rare, sure, but it does happen.

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

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784
    edited December 2

    We could discuss our differing realities all week, I bet…. And they really are fascinating. I’d love to do so some time over a beer or two or six.

    We’ve done drivers for Class 2 medical devices (as I said, I’m writing a driver for one right now), for devices for DoD contractors both prime and others further “downstream” (my favorite being the C3 system for an unmanned aerial vehicle… to be clear, this thing is 40 feet long and flies at over 200mph), and industrial type devices of every size and shape.

    This qualification of which you speak is real, but it’s simply not our reality. The burden of qualification falls on the actual manufacturer, and (except for some rare instances) doesn’t impact us…. one little bitty sub-contractor in the process. So, I’m sure somebody is doing this compliance work… but it’s not us. Remember… we are rarely the ones who do the final build of our software before it’s put into some medical or robotic or defense device. Our clients for these things are ultimately the ones who run some build of VS and produce the driver binaries.

    It’s not that we don’t take these projects seriously. We certainly do. And it’s not like we aren’t willing to do whatever is required by our clients. Because we are. It’s just that we’re not asked to do so — I said “never” before, but it turns out that’s not true. We have been dragged into the mire that is NIST 800, once, by an enormous DoD prime contractor, whose policy was that every one of THEIR suppliers had to meet NIST 800 mumble something. I think the project ended before we ever completed the process, which I remember being wildly impractical. And years ago we WERE asked for a quality manual by a medical device manufacturer… I remember writing it in a couple of afternoons… and we even had an on-site inspection. It certainly didn’t address any changes in our tool chain.

    Also, I have to ask: To what extent can you really validate your compiler? I’d say, unless you’re very good at compilers, not at any reasonable level at all. So, why go there?

    And where does it stop? Are you going to validate the microcode in your CPU (cuz that gets updated by WU)? The firmware in your SSD? The operation of Windows Explorer?

    An interesting tangent here is that we’re seeing more and more very detailed, difficult, complex, and annoying requirements around everything from facility security to cyber security from every big company with which we deal. Again, regulations about where we store our code, whether the server room is locked, what sort of endpoint protection we run…. We had one client who required that we have a “fire suppression system” installed in our server room. I kid you not. And “security audits” and details of how we manage our WiFi are common requirements. This is for us to do work for “ordinary” big Silicon Valley tech companies.

    But nobody, so far, has told me which version of VS or the WDK to use. Or which version of Windows I’m running on my dev box.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Don_BurnDon_Burn Member - All Emails Posts: 1,753

    I never like disagreeing with Peter, but in this case I have to. I also have done multiple medical devices, in all cases I worked with the firm to provide a packaged environment with all the items necessary to build the driver including the WDK and the compiler. At least two of the firms had gotten to the point where they had a standalone system not connected to the network as their build system. One of these firms is still shipping product in a Windows 7 embedded environment, because since then they have not seen a stable system from Microsoft. Note: the firm on Win7 has takes as much as 10 years to get their device approved world wide, because of all the various testing requirements individual countries place on the equipment.

    I am one of those compiler guys having run multiple teams years ago both as the lead for code generation, and for the lead for the compiler products at different firms. I also along with Mark Roddy worked at a fault tolerant firm that signed contracts guaranteeing 3 minutes of downtime in a year (and that included installing updates). Bottom line this stuff is hard.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784

    @Don_Burn ... Hi Don! I don't think you're disagreeing with me at all. I didn't hear you say that you had to personally check and validate every update to the WDK or VS. You had to give THEM some specs, or a zip archive, or a VM, that they could use to build the driver. Sure. Whatever. But it's the CLIENT who was responsible for the qualification and compliance. YOU didn't have to validate that the compiler worked properly, right?

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Don_BurnDon_Burn Member - All Emails Posts: 1,753

    Actually, I helped them validate that the driver would work correctly given a specific toolset, and helped them create the specific environment (both compiler and system) that they could rely on. They then locked that down for the product, and even if I came back to help them with a bug it was the same environment even though years may have passed.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,784

    That all sounds entirely reasonable.

    But you didn't validate that the compiler worked. Or establish a Quality System with a written plan. Or have to comply with 21 CFR 820.3(l).

    All you're talking about is choosing an environment, helping your customer use that same environment, and then sticking to that environment for future bugs. That's a lot different to what Mr. @craig_howard was talking about. I think.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • craig_howardcraig_howard Member Posts: 226

    @Peter_Viscarola_(OSR) said:
    That all sounds entirely reasonable.

    But you didn't validate that the compiler worked. Or establish a Quality System with a written plan. Or have to comply with 21 CFR 820.3(l).

    All you're talking about is choosing an environment, helping your customer use that same environment, and then sticking to that environment for future bugs. That's a lot different to what Mr. @craig_howard was talking about. I think.

    Peter

    Yep ... like I said, y'all have lived a blessed life ... were that I could simply say "here's what I'm using and a VM that uses it to build the thing" or "here's the magic binary, it was made by elves in our workshop" ...

    Somehow y'all have managed to get your upstream client to do all of the certification and submission stuff for you, but that's a big risk for them to be honest. If they get audited, or there's a problem with your driver then they will be asked to back up the paperwork which they filed on your behalf to satisfy the various regulatory agencies with your paperwork, and somebody at your upstream client is going to be very, very uncomfortable.

    "Trust me, it's all good" just doesn't fly with the FDA, OSHA or agencies that follow NIST ... again, blessed life y'all have been leading ... would LOVE to be able to to that!

    As for validating the compiler, it's actually easier than it sounds ... you get a version of the compiler that has been vetted, and compile the SDK and WDK samples supplied with that version against it (all of them). You then take the new version of the compiler and run the exact same SDK and WDK samples of the earlier version against it. You now have two sets of binaries, run both sets through VirusTotal and do a few binary diff's here and there if the sample sizes are wildly different to see what has changed. Document what you did, explain any false positives or big binary differences and you have now validated your compiler ...

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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!
Writing WDF Drivers 24 January 2022 Live, Online
Internals & Software Drivers 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online
Developing Minifilters 23 May 2022 Live, Online