Building drivers with Visual Studio 2022

NTDEV
7

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

8

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 …

9

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

10

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.

11

" 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

1 Like
12

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

13

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.

14

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

15

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

1 Like
16

@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

17

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

18

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 …

19

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

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

21

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

22

@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

23

I for one look forward to every single vs update

Oh, to be young again!

Peter

1 Like
24

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

25

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.

26

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