Building drivers with Visual Studio 2022

@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.

1 Like

@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.

@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 …

:slight_smile:

@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

I for one look forward to every single vs update

Oh, to be young again!

Peter

1 Like

@“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

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.

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

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.

@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

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.

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)” 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 …

I have validated compilers for various purposes, it is a lot more than what you suggested. Bottom line when I did that work it took a lot of work and several months. Been there done that a “real validation” is a lot more than you check, your steps were the type of thing we did for an initial check to see if we should spend the time to do the work.

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

But… does it really have to be “on our behalf”? I mean, THEY’re the manufacturer. THEY’RE building the ultimate driver binary image. THEY test it in their system and warrant that it works and doesn’t unintentionally kill people. We’re just a little bitty sub-contractor to a giant corporation that has a vast pile of people who spend their lives understanding and worrying about quality, and testing, and compliance. Does this validation/testing/compliance/documentation thing fall all the way back on every supplier? Microsoft? The people who make the SSD? The people who make the memory chips in the SSD? The people who make the silicon wafers that are used to make the memory chips in the SSD?

I’m not trying to argue, I’m genuinely trying to understand how our objective realities can be so very different. And understand why WE would be required to file compliance plans, when (say) Microsoft is not.

Peter

@“Peter_Viscarola_(OSR)” I understand what you’re saying, and again it’s really good that you don’t have to deal with this … so I’ll summarize what I was explained to me when I tried the same argument to wiggle out of this …

Imagine that you manufacture a syringe, which is defined as a class 2 medical device [ https://www.qualio.com/blog/fda-medical-device-classes-differences ]. The syringe is made up of three parts; the needle, the barrel and the plunger. Under FDA guidelines as a class 2 medical device each of those components needs to satisfy four conditions:

  • Is the component being manufactured to within the tolerances of the medical device; is the needle sharp, is the barrel round, is the plunger able to mate properly with the barrel, etc. and what quality control measures are being taken to ensure that the needle really is sharp, the barrel really is round and that the plunger really does mate properly with the barrel
  • Is the component being manufactured able to do what the medical device requires of it; is the needle able to penetrate skin, is the plunger able to be depressed without leaking, does the barrel fully expel the liquid when the plunger is fully depressed
  • Are the materials used in the components themselves acceptable to the intended purpose and operating environment of the medical device; is the needle made of plastic/ steel/ aluminum, is the plunger made of nontoxic plastics which are nonreactive to whatever might be in the syringe, is the barrel also made of nontoxic plastics, etc.
  • Is the manufacturing process for the syringe which assembles the needle, plunger and syringe done in a predictable, reproducible way which does not introduce any contaminants or defects to the product; is the needle press extruded from a billet and cut with a grinder, is the plunger assembled by hand or machine, is the barrel extruded from a billet or hot formed on a press, etc. If there are humans involved in the process, what procedures do they follow to ensure that contaminants like hairs or dandruff are not introduced, etc

All medical devices have to submit paperwork to the FDA to answer to these four conditions for each individual component used in the medical device, so the syringe manufacturer needs to submit papers to the FDA documenting each of these four conditions for the individual components integral to the functioning of the device; the needle, the barrel and the plunger. The suppliers of those parts will be requested by the medical company to submit paperwork answering each condition, and those are all bundled together, audited by the device company and submitted to the FDA for approval.

This is a good thing, it ensures that syringes are made with needles that don’t break, are sharp enough to do the job, have plungers that don’t melt or crumble in use and barrels that don’t leak all over the place or introduce air bubbles and aren’t made of materials that will contaminate the injected liquid

Imagine if the needle manufacturer, or the plunger manufacturer or the barrel manufacturer simply said “trust us, the needle won’t break and it’s sharp enough … the plunger won’t crumble and won’t contaminate the liquid … the barrel won’t leak and also won’t contaminate things” … would you as a patient be comfortable with those assurances?

If the device driver that you’re writing and supplying to the medical device company is an integral part of the device necessary for it’s proper operation then federal law states that it too needs to be documented as to the four conditions. For a device driver (following the four conditions), the medical device company needs to submit to the FDA papers attesting to and stating:

  • Is the device driver being written using an established manufacturing process (using Visual Studio or WDK and not the open source Watcom compiler) and accepted development methodologies (like KMDF, not some framework downloaded off of GitHub), and if there are external libraries used what is done to ensure that they aren’t harboring malware
  • Does the device driver do exactly what it’s supposed to do, including nothing more than what it’s supposed to do (that means no back doors or secret codes)
  • Has the driver been tested on all potential software and hardware platforms expected to be encountered in normal use
  • Can the driver binaries be reliably reproduced as needed, and what safeguards are in place to ensure that

This is also a good thing … you really don’t want the device driver that is responsible for delivering an insulin infusion to a patient in ICU to be written by some hourly WeWork fellow based in Turkey using the Watcom compiler using some driver framework he downloaded from GitHub over his summer break.

That said, they still need to submit the same paperwork to the FDA as the manufacturer of a syringe needs for it’s components. All of the companies that I work with give me that task for a very simple reason, they don’t know my process and they are unwilling to make guesses that might have to be proven in court. When you tell your client “… I mean, THEY’re the manufacturer. THEY’RE building the ultimate driver binary image. THEY test it in their system and warrant that it works and doesn’t unintentionally kill people. We’re just a little bitty sub-contractor to a giant corporation” what you’re really telling them to say on those four conditions are:

  • We have no idea how the driver is being written or what is being used to compile it, but we trust that the OSR folks will use the right stuff
  • We have no idea if the thing actually does what it’s supposed to do other than when we run it it seems to work, and have no idea if it’s doing something else but the OSR folks said it’s all good
  • We were told that it runs on what we wanted it to run on and it seems to work on the machines around here we put it on
  • We were given the sources and a build recipe, and Bob from accounting is able to use that to build the driver

Apparently your clients are comfortable with that, which means they don’t realize how uncomfortable someone is going to be if the FDA audits them or god forbid there’s an incident and a liability attorney sits them down for discovery (or an FBI agent sits them down for an interview). Remember, the FDA can shut their entire product line down and require a recall with just a few strokes of a pen if they don’t like the answers they are going to get for those four conditions. Companies that I work with want to be absolutely sure that there’s no chance of that, so rather than make “trust me” documents they hand it off to me to fill out since I can answer those four conditions much more precisely (and more importantly, it’s me facing down the discover lawyer or FBI agent explaining things rather than them)

Again, astonished that none of this has come up for OSR … I’ve been running into this stuff for years …

Yeah, but your talking across purposes. All of those regulations have to be followed, but to use your example, do you have to certify the machine that makes the machine that makes the needles? When do you stop in that chain of validation? What about the power plant that makes the electricity that runs the machine that makes the machine that makes the part? How about the quality of the coal that powers that plant? Or maybe it is hydro and are your going to vet the raindrops that fall to make sure that they will be adequate to spin the turbines?

In legal terms, at least in my jurisdiction, the point at which you stop is when you get to common availability. The legal terms vary, but the point is that once you start using tools, parts, equipment etc. that are available to everyone and also used by ‘everyone’ working in the same space, your particular liability ends and the manufactures or suppliers of those tools parts etc. must maintain them to the standards of that particular industry. You still must ensure that they are the right things to use, given the common standards in that industry, and your particular problem domain. And when there do not exist any commonly available tools etc. that are fit, adapt from there

but it sounds like a lot of loudly agreeing overall

@MBond2 Correct on the common availability … if you are using tools and techniques that are commonly used within the industry then you’re good … and you don’t need to track down and document the needle extruder manufacturer AS LONG AS that device is “commonly used” by other needle manufacturers. Suppose though that the common practice was “extrude and grind the tip”, but the manufacturer used a “sinter and grind the tip” method … the needle supplier would need to document what they were doing using the “sinter and grind” method to satisfy the four conditions because it’s not a “commonly available” technique

Completing the circle on this thread, VS2019 has been out there for quite awhile and is commonly used; I don’t need to validate that tool. VS2022 is not yet “out there” and is not yet commonly used, so if I want to use that then I do need to vette it. Same with the weekly updates of VS2019 … version 16.04 has been “out there” for long enough to be commonly available, the version just released yesterday not so much and so needs vetting if I want to use it …

That’s why I will generally stay at least six months (sometimes a year) behind the bleeding edge … not only does it give time for bugs to appear, it allows the tool to move into the common availability category and I can simply note that and move on …

This entire conversation sounds eerily similar to the “Functional Safety” certification we had to deal with when I was at ARM.  Because the process was so arduous and expensive, we only sought certification on certain LTS releases of the compiler tool chain. 

I say “tool chain” because it wasn’t only the compiler, but the linker, librarian, ALL runtime libraries, etc.  If you’re going for SIL 1, that means we had to be able to account for every single line of machine code as to the exact line of source code caused it to be generated.  Even with TUV certifications, our partners who used the compiler had to do their own certifications of our compiler as used in their product.  Their certifications were based upon the machine code executed by the processor, NOT the C/C++ source code run through the compiler to generate it.

I’m glad I was not dealing with supporting Functional Safety toolchain issues and could hand those off to the experts in that area within the group.

Greg

On Fri, 03 Dec 2021 00:13:33 +0000 (UTC), craig_howard wrote:

OSR https://community.osr.com/

craig_howard commented on Building drivers with Visual Studio 2022

@MBond2 Correct on the common availability … if you are using tools and techniques that are commonly used within the industry then you’re good … and you don’t need to track down and document the needle extruder manufacturer AS LONG AS that device is “commonly used” by other needle manufacturers. Suppose though that the common practice was “extrude and grind the tip”, but the manufacturer used a “sinter and grind the tip” method … the needle supplier would need to document what they were doing using the “sinter and grind” method to satisfy the four conditions because it’s not a “commonly available” technique

Completing the circle on this thread, VS2019 has been out there for quite awhile and is commonly used; I don’t need to validate that tool. VS2022 is not yet “out there” and is not yet commonly used, so if I want to use that then I do need to vette it. Same with the weekly updates of VS2019 … version 16.04 has been “out there” for long enough to be commonly available, the version just released yesterday not so much and so needs vetting if I want to use it …

That’s why I will generally stay at least six months (sometimes a year) behind the bleeding edge … not only does it give time for bugs to appear, it allows the tool to move into the common availability category and I can simply note that and move on …

[Peter wrote] “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.”

Then this looks like one of interesting features of the new VS. If it can “run in the browser”, the system where the toolchain runs is separated from your Windows system. The back-end can be container made with LTS of the OS, LTS of toolchain and so on. Windows updates won’t taint it.
MS has not invented this, of course: take for example Eclipse Che, ARM/Keil Studio Cloud… Well, now they too.