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

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category, below.

WDK 1803 DVL Creation

Dave_RuskeDave_Ruske Posts: 17
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

Comments

  • Peter_ViscarolaPeter_Viscarola Posts: 6,651
    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)

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dave_RuskeDave_Ruske Posts: 17
    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
  • Dave_RuskeDave_Ruske Posts: 17
    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"?>
    <Project DefaultTargets="Build" ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ItemGroup Label="ProjectConfigurations">
    <ProjectConfiguration Include="Debug|x64">
    <Configuration>Debug</Configuration>
    <Platform>x64</Platform>
    </ProjectConfiguration>
    <ProjectConfiguration Include="Release|x64">
    <Configuration>Release</Configuration>
    <Platform>x64</Platform>
    </ProjectConfiguration>
    </ItemGroup>
    <PropertyGroup Label="Globals">
    <ProjectGuid>{BF59CA88-8371-4E97-328B-25001F8C08E4}</ProjectGuid>
    <TemplateGuid>{497e31cb-056b-4f31-abb8-447fd55ee5a5}</TemplateGuid>
    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
    <MinimumVisualStudioVersion>12.0</MinimumVisualStudioVersion>
    <Configuration>Debug</Configuration>
    <Platform Condition="'$(Platform)' == ''">Win32</Platform>
    <RootNamespace>hadar</RootNamespace>
    <WindowsTargetPlatformVersion>$(LatestTargetPlatformVersion)</WindowsTargetPlatformVersion>
    <TargetName>hadar</TargetName>
    </PropertyGroup>
    <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
    <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
    <TargetVersion>Windows7</TargetVersion>
    <UseDebugLibraries>true</UseDebugLibraries>
    <PlatformToolset>WindowsKernelModeDriver10.0</PlatformToolset>
    <ConfigurationType>Driver</ConfigurationType>
    <DriverType>KMDF</DriverType>
    <DriverTargetPlatform>Desktop</DriverTargetPlatform>
    <CharacterSet>NotSet</CharacterSet>
    <KMDF_VERSION_MAJOR>1</KMDF_VERSION_MAJOR>
    <KMDF_VERSION_MINOR>9</KMDF_VERSION_MINOR>
    <ALLOW_DATE_TIME>1</ALLOW_DATE_TIME>
    <OverrideTargetVersionDefines>
    </OverrideTargetVersionDefines>
    <OverrideDefaultRuntimeLibrary>
    </OverrideDefaultRuntimeLibrary>
    <SpectreMitigation>Spectre</SpectreMitigation>
    </PropertyGroup>
    <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
    <TargetVersion>Windows7</TargetVersion>
    <UseDebugLibraries>false</UseDebugLibraries>
    <PlatformToolset>WindowsKernelModeDriver10.0</PlatformToolset>
    <ConfigurationType>Driver</ConfigurationType>
    <DriverType>KMDF</DriverType>
    <DriverTargetPlatform>Desktop</DriverTargetPlatform>
    <CharacterSet>NotSet</CharacterSet>
    <KMDF_VERSION_MAJOR>1</KMDF_VERSION_MAJOR>
    <KMDF_VERSION_MINOR>9</KMDF_VERSION_MINOR>
    <ALLOW_DATE_TIME>1</ALLOW_DATE_TIME>
    <OverrideDefaultRuntimeLibrary>
    </OverrideDefaultRuntimeLibrary>
    <SpectreMitigation>Spectre</SpectreMitigation>
    </PropertyGroup>
    <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
    <ImportGroup Label="ExtensionSettings">
    </ImportGroup>
    <ImportGroup Label="PropertySheets">
    <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
    </ImportGroup>
    <PropertyGroup Label="UserMacros" />
    <PropertyGroup />
    <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <DebuggerFlavor>DbgengKernelDebugger</DebuggerFlavor>
    </PropertyGroup>
    <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
    <DebuggerFlavor>DbgengKernelDebugger</DebuggerFlavor>
    <CodeAnalysisRuleSet>HadarAnalysisRules.ruleset</CodeAnalysisRuleSet>
    <RunCodeAnalysis>true</RunCodeAnalysis>
    </PropertyGroup>
    <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    <ClCompile>
    <WppEnabled>true</WppEnabled>
    <WppRecorderEnabled>true</WppRecorderEnabled>
    <WppScanConfigurationData Condition="'%(ClCompile.ScanConfigurationData)' == ''">driver\hadartrace.h</WppScanConfigurationData>
    <WppKernelMode>true</WppKernelMode>
    <AdditionalIncludeDirectories>$(IntDir);%(AdditionalIncludeDirectories);inc;$(IntDir);..\..\otstk\Common\inc</AdditionalIncludeDirectories>
    <PreprocessorDefinitions>_WIN64;_AMD64_;AMD64;%(PreprocessorDefinitions);EVENT_TRACING;WDFBUILD;POOL_NX_OPTIN=1;INSTRUMENTED=1</PreprocessorDefinitions>
    <WppTraceFunction>TraceEvents(LEVEL,FLAGS,MSG,...)</WppTraceFunction>
    <WppGenerateUsingTemplateFile>{km-WdfDefault.tpl}*.tmh</WppGenerateUsingTemplateFile>
    <WppDllMacro>true</WppDllMacro>
    <WppIgnoreExclamationmarks>
    </WppIgnoreExclamationmarks>
    <WppFileExtensions>.cpp</WppFileExtensions>
    <WppSearchString>
    </WppSearchString>
    <WppPreprocessorDefinitions>
    </WppPreprocessorDefinitions>
    <WarningLevel>Level4</WarningLevel>
    <TreatWarningAsError>true</TreatWarningAsError>
    <AdditionalOptions>/Zc:sizedDealloc- %(AdditionalOptions)</AdditionalOptions>
    </ClCompile>
    <Link>
    <AdditionalLibraryDirectories>..\..\otstk\x64\Debug;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
    <AdditionalDependencies>ntoskrnl.lib;wdmsec.lib;otstk.lib;%(AdditionalDependencies)</AdditionalDependencies>
    </Link>
    </ItemDefinitionGroup>
    <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
    <ClCompile>
    <WppEnabled>true</WppEnabled>
    <WppRecorderEnabled>true</WppRecorderEnabled>
    <WppScanConfigurationData Condition="'%(ClCompile.ScanConfigurationData)' == ''">driver\hadartrace.h</WppScanConfigurationData>
    <WppKernelMode>true</WppKernelMode>
    <AdditionalIncludeDirectories>$(IntDir);%(AdditionalIncludeDirectories);inc;$(IntDir);..\..\otstk\Common\inc</AdditionalIncludeDirectories>
    <PreprocessorDefinitions>_WIN64;_AMD64_;AMD64;%(PreprocessorDefinitions);EVENT_TRACING;WDFBUILD;POOL_NX_OPTIN=1</PreprocessorDefinitions>
    <WppTraceFunction>TraceEvents(LEVEL,FLAGS,MSG,...)</WppTraceFunction>
    <WppGenerateUsingTemplateFile>{km-WdfDefault.tpl}*.tmh</WppGenerateUsingTemplateFile>
    <WppDllMacro>true</WppDllMacro>
    <WppIgnoreExclamationmarks>
    </WppIgnoreExclamationmarks>
    <WppFileExtensions>.cpp</WppFileExtensions>
    <WppSearchString>
    </WppSearchString>
    <WppPreprocessorDefinitions>
    </WppPreprocessorDefinitions>
    <WarningLevel>Level4</WarningLevel>
    <TreatWarningAsError>true</TreatWarningAsError>
    <AdditionalOptions>/Zc:sizedDealloc- %(AdditionalOptions)</AdditionalOptions>
    <EnablePREfast>true</EnablePREfast>
    </ClCompile>
    <Link>
    <AdditionalLibraryDirectories>..\..\otstk\x64\Release;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
    <AdditionalDependencies>ntoskrnl.lib;wdmsec.lib;otstk.lib;%(AdditionalDependencies)</AdditionalDependencies>
    </Link>
    </ItemDefinitionGroup>
    <ItemGroup>
    <FilesToPackage Include="$(TargetPath)" />
    </ItemGroup>
    <ItemGroup>
    <ClCompile Include="driver\drventry.cpp" />
    <MessageCompile Include="driver\hadarmc.mc">
    <FileType>Document</FileType>
    </MessageCompile>
    <ClCompile Include="driver\kernelnew.cpp" />
    <ClCompile Include="driver\hadar.cpp" />
    </ItemGroup>
    <ItemGroup>
    <ClInclude Include="driver\hadar.h" />
    <ClInclude Include="driver\hadartrace.h" />
    <ClInclude Include="driver\hadarmc.h" />
    <ClInclude Include="driver\drventry.h" />
    <ClInclude Include="inc\kernelnew.h" />
    <ClInclude Include="resource.h" />
    </ItemGroup>
    <ItemGroup>
    <Inf Include="hadar.inf" />
    </ItemGroup>
    <ItemGroup>
    <ResourceCompile Include="hadar.rc" />
    </ItemGroup>
    <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
    <ImportGroup Label="ExtensionTargets">
    </ImportGroup>
    </Project>
  • Dave_RuskeDave_Ruske Posts: 17
    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.
  • Peter_ViscarolaPeter_Viscarola Posts: 6,651
    <quote>
    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.
    </quote>
    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)

    <quote>
    I *hope* this little trick isn't just unique to my machine
    </quote>

    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.

    <quote>
    I hope I'm not
    doing something unspeakably stupid in deleting an unused configuration
    </quote>

    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

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dave_RuskeDave_Ruske Posts: 17
    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
    >
    > 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.
    >
    > 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)
    >
    >
    > I *hope* this little trick isn't just unique to my machine
    >
    >
    > 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.
    >
    >
    > I hope I'm not
    > doing something unspeakably stupid in deleting an unused configuration
    >
    >
    > 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.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!