WDK 1803 DVL Creation

Is there any magic dust needed to create a Driver Verification Log with WDK 1803?

I had some trouble with SDV initially, but finally fixed that by doing a repair on the WDK install. My driver builds with nary a warning, code analysis is clean (though needs to be ran as part of the build in order to find its tmh files), SDV passes happily, and then I try creating the DVL, which tells me: “Please select a driver project. Driver Verification Log cannot be created for the selected platform tool set: ‘v100’.”

Which would be a reasonable enough thing to say if the platform tool set was v100, I suppose, but the project’s PlatformToolset is WindowsKernelModeDriver10.0 and PlatformToolsetVersion is 141. MSBuildToolsVersion is 15.0, which seems right for VS2017. Granted, TargetVersion is Windows7 and KmdfVersion is at 1.9, because of the legacy systems I need to support.

Any suggestions as to what the DVL generation tool might really be griping about, or which settings I might have messed up?

Thanks,
Dave

Just to make sure we cover the simple stuff:

You select a specific driver project. You set the config to “release” and, oh, x64 let’s say. This will be the same stuff that you’ve used to already run SDV.

Setup this way, you select “Driver / Create Driver Verification Log…” and THAT’s when you get a dialog with the error you’ve indicated? You don’t get the “The Windows Server v.Next Hardware Certification Program requires…” stuff?

Hmmmm… Did you do anything “funny” to create your project file? Like, you know, generate it by hand or edit the hell out of it or anything?

Peter
OSR
@OSRDrivers

(just to make sure it’s not an obvious problem, I *did* generate a DVL using VS 2017 and WDK 1803 just a minute ago… so it’s not TOTALLY broken at least)

Yes. The x64 Release project is selected (good guess :), the same project that SDV had just been run on. When Create Driver Verification Log is selected from the menu, I immediately get a dialog box with the text I described.

The project file did come about a bit funny. This particular driver I inherited goes back most of 20 years and had been built with a SOURCES file, but my predecessor had made a change that made the driver too young to grandfather in to Windows 10 Secure Boot. Time to modernize it and get it signed!

So, with the help of OSR’s MSBUILD 101 article and a vcxproj skeleton generated by VS2017, I put together a project file for it, ran it through the various hoops to earn Microsoft’s blessing, and addressed the issues those tests turned up. I’d thought the success I’d had running these tests had proven out the project file by now, but perhaps not.

I’m assuming I have *something* screwy, or this forum would be lit up with complaints about the tool. I just don’t know enough about what the DVL creator actually does to know where to look for the issue. Before now I’d thought it just archived CA and SDV results, but I expect to discover that was naive on my part.

Live and learn…

Thanks,
Dave

Dave,

Nate from the SDV team here. Our logic for determining when to show that message is very straightforward (we get the “PlatformToolset” value from the project, and if that’s not WindowsKernelModeDriver8.x or WindowsKernelModeDriver10 we throw out the error) so I would suspect something’s odd about your project, especially if it’s been evolved from a very old one.

I would open up your project file(s) in Notepad and double-check that all references to “PlatformToolset” are actually what you expect them to be.

-Nate

Hi Nate, really appreciate your response. For both Debug and Release builds, the PlatformToolset is “WindowsKernelModeDriver10.0” (if I replace that with “WindowsKernelModeDriver10” the project won’t build, and the config GUI shows “WindowsKernelModeDriver10 (not installed)”… the “.0” suffix seems necessary, at least on my machine).

Here’s the entire project file, with some of the .cpp/.h files obfuscated or deleted out of zealous discretion:


<?xml version="1.0" encoding="utf-8"?>




Debug
x64


Release
x64



{BF59CA88-8371-4E97-328B-25001F8C08E4}
{497e31cb-056b-4f31-abb8-447fd55ee5a5}
v4.5
12.0
Debug
Win32
hadar
$(LatestTargetPlatformVersion)
hadar



Windows7
true
WindowsKernelModeDriver10.0
Driver
KMDF
Desktop
NotSet
<kmdf_version_major>1</kmdf_version_major>
<kmdf_version_minor>9</kmdf_version_minor>
<allow_date_time>1</allow_date_time>




Spectre


Windows7
false
WindowsKernelModeDriver10.0
Driver
KMDF
Desktop
NotSet
<kmdf_version_major>1</kmdf_version_major>
<kmdf_version_minor>9</kmdf_version_minor>
<allow_date_time>1</allow_date_time>


Spectre










DbgengKernelDebugger


DbgengKernelDebugger
HadarAnalysisRules.ruleset
true



true
true
driver\hadartrace.h
true
$(IntDir);%(AdditionalIncludeDirectories);inc;$(IntDir);…..\otstk\Common\inc
_WIN64;AMD64;AMD64;%(PreprocessorDefinitions);EVENT_TRACING;WDFBUILD;POOL_NX_OPTIN=1;INSTRUMENTED=1
TraceEvents(LEVEL,FLAGS,MSG,…)
{km-WdfDefault.tpl}.tmh
true


.cpp




Level4
true
/Zc:sizedDealloc- %(AdditionalOptions)



…..\otstk\x64\Debug;%(AdditionalLibraryDirectories)
ntoskrnl.lib;wdmsec.lib;otstk.lib;%(AdditionalDependencies)




true
true
driver\hadartrace.h
true
$(IntDir);%(AdditionalIncludeDirectories);inc;$(IntDir);…..\otstk\Common\inc
_WIN64;AMD64;AMD64;%(PreprocessorDefinitions);EVENT_TRACING;WDFBUILD;POOL_NX_OPTIN=1
TraceEvents(LEVEL,FLAGS,MSG,…)
{km-WdfDefault.tpl}
.tmh
true


.cpp




Level4
true
/Zc:sizedDealloc- %(AdditionalOptions)
true



…..\otstk\x64\Release;%(AdditionalLibraryDirectories)
ntoskrnl.lib;wdmsec.lib;otstk.lib;%(AdditionalDependencies)








Document





















I believe I’ve found a way to break DVL creation in a 8 easy steps. Show your friends! Be popular at parties!*

Prerequisites: the 1803 WDK and VS2017 15.7.4.

  1. Create a new Kernel Mode Driver (KMDF).

  2. In project Properties, select Release x64; in Code Analysis > General, check Enable Code Analysis on Build.

  3. Select Release x64 and build.

  4. Select Driver > Launch Static Driver Verifier and click Start. Meditate while 108 rules verify, or be smarter than me and deselect 107 rules before clicking Start.

  5. Select Driver > Create Driver Verification Log. At this point the usual dialog with Create and Cancel buttons will come up. All is well! Cancel for now.

  6. Select Build > Configuration Manager. In the Platform column of the table, Choose Edit, then remove the Win32 platform. Who uses 32 bits? Honestly.

  7. Select File > Save All. That project file won’t flush itself. (It probably should, though.)

  8. Select Driver > Create Driver Verification Log. If you did everything right, you’ll now get a dialog that says, “Please select a driver project. Driver Verification Log cannot be created for the selected platform tool set: ‘v100’.”

I *hope* this little trick isn’t just unique to my machine, and I hope I’m not doing something unspeakably stupid in deleting an unused configuration. Seemed like a good idea at the time…

Thanks,
Dave

* This will not actually make you popular at parties. Or anywhere, really. Sorry.

Oh, SURE. For those us playing along at home, DEFINITELY put the “deselect 107 rules” bit AFTER saying “click Start”… Then again, I DID get to meditate this morning, which I suppose isn’t that bad.

(Does SDV now *really* say “Give Up” as a result? Is this something new?? Cuz, on the OOB sample KMDF driver I got a BUNCH of “Give Up” results. This isn’t very friendly, and it LOOKS like it’s telling the *user* to Give Up… bad choice)

It took me two tries, but I *did* manage to recreate the behavior you describe. I think it ONLY happens after clicking “save all” (interestingly enough).


Creating Driver Verification Log…

Please select a driver project. Driver Verification Log cannot be created for the selected platform tool set: ‘v100’.

Yay?

Also, interestingly enough, nothing I tried would FIX the problem once it started.

JUST to reassure you (not that you needed it, really): There is absolutely nothing stupid about deleting unused configurations. That’s why you CAN delete them… We do it here, all the time, to ensure our clients don’t mistakenly build a driver that (for some reason) supports only one particular architecture for the WRONG architecture.

Though, I admit: The way we do that is to edit the project file manually.

Nice repro steps!

Let us hope that Mr. Deisinger is still reading this thread, and that he can repro the problem as well.

Peter
OSR
@OSRDrivers

I *was* able to workaround the issue by using Configuration Manager to re-create a Win32 project configuration, copying settings from the x64 project, though File > Save All was again required to flush the project file before attempting DVL creation.

I saw a few of those “give up” messages as well. Spent a somber evening in reflection before finding the courage to boot the machine the next morning.

Dave

It’s been several years since I worked on this, so things may have changed. 
Back in the Win7 era, SDV made unwise assumptions about the format of the
project file.  It depended on the way Visual Studio created them, and could
fail with hand crafted project files (files that were 100% legal msbuild, and
that worked in all other parts of VS).

Including the following block in the vcxproj made SDV happy…

0
0
0
0
0
0
0
0
0
0
0
0

The important thing is to have a PropertyGroup with a Condition for every
possible configuration/platform.  The property name and value are irrelevant. 
I placed this block near the top of the file, right after the
ProjectConfigurations ItemGroup.  Not sure the placement matters.

–John

-------- Original Message --------
Subject: Re: [ntdev] WDK 1803 DVL Creation
From: xxxxx@osr.com
To: Windows System Software Devs Interest List
Date: 6/28/2018 9:46 AM
>


> Oh, SURE. For those us playing along at home, DEFINITELY put the “deselect 107 rules” bit AFTER saying “click Start”… Then again, I DID get to meditate this morning, which I suppose isn’t that bad.
>
> (Does SDV now really say “Give Up” as a result? Is this something new?? Cuz, on the OOB sample KMDF driver I got a BUNCH of “Give Up” results. This isn’t very friendly, and it LOOKS like it’s telling the user to Give Up… bad choice)
>
>


>
> It took me two tries, but I did manage to recreate the behavior you describe. I think it ONLY happens after clicking “save all” (interestingly enough).
>
> —
> Creating Driver Verification Log…
>
> Please select a driver project. Driver Verification Log cannot be created for the selected platform tool set: ‘v100’.
> —
>
> Yay?
>
> Also, interestingly enough, nothing I tried would FIX the problem once it started.
>
>


>
> JUST to reassure you (not that you needed it, really): There is absolutely nothing stupid about deleting unused configurations. That’s why you CAN delete them… We do it here, all the time, to ensure our clients don’t mistakenly build a driver that (for some reason) supports only one particular architecture for the WRONG architecture.
>
> Though, I admit: The way we do that is to edit the project file manually.
>
> Nice repro steps!
>
> Let us hope that Mr. Deisinger is still reading this thread, and that he can repro the problem as well.
>
> Peter
> OSR
> @OSRDrivers

Thanks for the repro steps and workarounds, everyone! I’ve been out of the office and hadn’t checked this thread in a few weeks, but I just got a question from a partner who’s running into this issue and remembered this thread straight away. =)

I’ll file a bug on our end and look at the root cause when I have some free cycles.