WDK and VS 2019 -- Can't Open Driver Project Properties

So, let me just say: I am soooo not loving Visual Studio 2019. It’s more buggy than a cheap hotel in Times Square.

My latest fun: Suddenly, I can not open the properties page for a driver project anymore. When I try, I get:

Anybody else see this? Why does VS 2019 hate me so much?

I’ve tried removing and reinstalling the WDK… no help. I’ve tried disabling and enabling the WDK Extension in VS. No success.

My colleagues can open the project properties… But I can’t. Perhaps it’s a conflict with one of the (other many) extensions I have installed? How on earth do I even go about debugging this??

Before I try to chase-up my friends on the WDK team and claim they have a bug, I want to be sure that this isn’t a solved problem. Or something unique on my system…

Thanks,

Peter

I. Hate. Visual Studio 2019.

Within two minutes of posting the above… I “fixed” it… by repeatedly fooling with the Solution properties and UNchecking the “Deploy” check boxes… which (if I have the settings and then go back to look at them) always get re-checked.

Moral of the story: “When something goes wrong in VS or the WDK, just keep randomly changing things until it works.”

So… I dunno. Maybe this nonsense thread will help somebody.

Peter

I remain a dinosaur for all of my Windows coding. I edit with gvim (or sometimes VSCode, if I’m in the mood) and do builds from a command line. I’ve become expert at creating and maintaining vcxproj and csproj files by hand.

Maybe the situation would be different if I used it regularly so the DLLs were cached, but when I launch a Visual Studio IDE, it takes quite literally two and a half MINUTES before the thing is up and able to accept mouse clicks. That’s just stupidly unacceptable for a mission-critical tool. I can make a debugging run with windbg, edit the file with gvim, make a change, msbuild a new executable, and try out the fix before the IDE has finished loading.

Do I miss Intellisense? Probably, but it’s not worth the price.

I remain a dinosaur for all of my Windows coding.

…and…

when I launch a Visual Studio IDE, it takes quite literally two and a half MINUTES before the thing is up and able to accept mouse clicks. That’s just stupidly unacceptable

Yes, I agree. That would be stupidly unacceptable and I’d use something different as well.

I just timed it on my system. From double-clicking a solution file to having the file open in VS 2019 where I can start to edit: 4.5 seconds.

Do you remain a dinosaur for your development system hardware as well? :smiley:

Do I miss Intellisense? Probably, but it’s not worth the price.

For ME, it’s not just Intellisense. It’s all the other value-added stuff I can get with VS. After years of using Visual Assist X, I actually switched back to using ReSharper for C++ because it has additional checks. Like, it runs both Clang Tidy and Clang Static Analyzer on my code. It’s caught a lot of cool little stuff for me. For example, I didn’t realize that this:

BUS_INTERFACE_STANDARD  BusInterface = { 0 };

…should be this:

BUS_INTERFACE_STANDARD  BusInterface = { };

I’ve never claimed to be proficient in C, so don’t lecture me.

Anyhow, I also enjoy being reminded to be all modern and stuff with encouragement to use “constexpr” each time I #define some literal value.

Gad! It’s back to failing again, and no random changing of the Solution parameters seems to be able to fix it.

I dunno… Off to whine to the WDK team I guess.

Peter

I also experienced this problem. I discovered someone had reported it to Microsoft. So it is quite widespread. Microsoft’s asked if uninstalling and reinstalling the WDK and VS fixed it. The user said yes and Microsoft basically brushed their hands and smiled, marked it as “not a bug”, and chose to ignore it leaving it there for all of us to run into. Reinstall worked for me as well, but it is quite annoying to run into a known problem that costs crucial development time and see a decision to just leave it there and do nothing has been made.

@Rourke : Thanks! I appreciate hearing this!

Do you have a link to this conversation where the problem is “known”? Because I just talked to the Program Manager who owns the WDK and she didn’t seem to know about it… and one of the leads didn’t say anything about it being known.

I tried removing and reinstalling the WDK, and that didn’t help. I did not, however, remove and reinstall the VS integration… which apparently is a separate step. I’m going to try that.

No way I’m removing VS. I don’t want to have to reinstall and reconfigure all my damn add-ins…

Peter

Unfortunately it appears uninstalling VS is the key to resolving this. Here is a link:

https://developercommunity.visualstudio.com/content/problem/542057/vs2019wdk-kmdfs-project-property-pages-cannot-be-o.html

Note it is marked “not a bug”–genius.

Thank you, Mr. Rourke. Much appreciated.

The WDK team is now aware of the problem and is trying to reproduce it. Naturally, their first question was “What did you change that resulted in this no longer working” and I had to tell them “I don’t know”. I felt like one of my own customers (“I dunno… it worked on Tuesday and then sometime later it stopped working. I dunno what I did!”). So, of you, or anyone you know, has a specific set of repro steps… please share them.

I updated to 16.2.1 (Released today!) and this did not help.

I removed the WDK and the WDK connector to VS and re-installed it. It did not help.

Next… I edited my Solution file and removed the lines that referred to deployment. That did not help.

THEN… I edited my solution file to return the deploy lines, as follows:

And I can now successfully open my project properties again. A ridiculous bit of hackery, but hey… a man’s gotta do what a man’s gotta do!

Peter

I’ve waited to see what would happen and find the outcome puzzling but not surprising. Despite being discussed here, despite the WDK team directly being made aware of it, and despite numerous new comments about it on the linked official problem report the issue status remains “not a bug” without so much as a peep. I mean even if you aren’t going to fix it, at least admit there is a problem and set the status to open right? It’s strange how glaring WDK problems get no service. Like how the debugger is a minefield of problems most people can’t get to work which is common knowledge in the driver community. Problem reports are ignored. Most companies are concerned about their customers and so I’m just not sure what to make of this.

The status is NOT “not a bug” — The owning team is aware of the issue, and as I understand it is still struggling due to lack of a repro. I may have that specific status wrong, but nobody I know is saying “not a bug.”

The problem is, however, extremely vexing. Because I don’t want to reinstall VS and all it’s add-ins, I did a VS install with the WDK in a VM, just so I could change project properties and test with different CA settings. Very, very, annoying.

Peter