Static Driver Verifier build issue

Ooh!! Great idea. That’s a good divide and conquer. Thanks Scott.

Yes it seems to run okay on a template project. I’ll start looking at the settings of my project and see what’s different.

Thanks for helping narrow it down.

cheers,

Chris

xxxxx@pleora.com wrote:

I’m having a quirky problem with running SDV on my project. I’m using VS2017 and the latest WDK.

The build phase complains about failing even though I can build everything just fine either through the IDE or using MSBuild directly. The error messages are fairly opaque but dialing up the debug and looking at some logs has shown me the cause but not the solution.

It seems like the link phase is building the output into an ‘odd’ directory. That is, I have a project folder of ebUniversalProForU3V which is where everything should take place. At some phase of the build, it winds up creating and using a ebUniversalProForU3Vx64 folder and putting the .sys, .inf, .pdb files in there.

Are you able to post your vcxproj?  Perhaps one of us can spot something.

If ebUniversalProForU3V is the project folder, where do you want the
binaries?  The default project files will put the intermediate (.obj)
and final (.sys) files into:
  ebUniversalProForU3V\Debug
  ebUniversalProForU3V\Release
  ebUniversalProForU3V\x64\Debug
  ebUniversalProForU3V\x64\Release

Personally, I hate this, so I always modify the vcxproj to use Debug,
Release, Debug64, and Release64.  That means I have some experience with
tweaking vcxproj files.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Hi Tim,

The weird x64 suffix seems to be a red herring. When I made a template project to test the SDV it actually did the exact same thing and still worked just fine:

xxxxx@cwarkentin MINGW64 ~/Documents/Visual Studio 2017/Projects/USB Driver1
$ ls
USB Driver1/ USB Driver1.sln USB Driver1x64/ x64/

Here’s the project file. One other thing that got me wondering. I saw another post within this mailing list about SDV where the person said it wasn’t working when there were still static analysis warnings in the project. I still have a few (benign) warnings that I haven’t cleaned up. Could that be it?

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




Debug
Win32


Release
Win32


Debug
x64


Release
x64



{8C3E8345-1FED-4719-A9F2-0DC3DA7EE410}
{8b1800b9-d017-4029-9785-13ef5e5b328e}
Converted Driver Project
ndislwf.vcxproj
12.0
Debug
Win32
ebUniversalProForEthernet
$(LatestTargetPlatformVersion)



WindowsKernelModeDriver10.0
Driver
WDM
Desktop


WindowsKernelModeDriver10.0
Driver
WDM
Desktop


WindowsKernelModeDriver10.0
Driver
WDM
Desktop


WindowsKernelModeDriver10.0
Driver
WDM
Desktop


S:\sw\win-x86_64..\res\Certs\TestCertificate.pfx
S:\sw\win-x86_64..\res\Certs\MSCV-VSClass3.cer
E=xxxxx@pleora.com, CN=Pleora Technologies Inc., O=Pleora Technologies Inc., L=Ottawa, S=Ontario, C=CA | B56C24DACDD3FEF21FDD0E431318BBCF6B678663


Off


Off


Off


Off



Windows7
true


Windows7
false


Windows7
true


Windows7
false







DbgengKernelDebugger
ndislwf
$(IntDir);$(ProjectDir);$(IncludePath)
AllRules.ruleset
true


DbgengKernelDebugger
ndislwf
$(IntDir);$(ProjectDir);$(IncludePath)
AllRules.ruleset
true


DbgengKernelDebugger
ndislwf
$(IntDir);$(ProjectDir);$(IncludePath)
AllRules.ruleset
true


DbgengKernelDebugger
ndislwf
$(IntDir);$(ProjectDir);$(IncludePath)
AllRules.ruleset
true
$(SolutionDir)$(Platform)



Level4
false
…;.;S:\sw\win-x86_64..\inc;S:\sw\win-x86_64..\Includes;S:\sw\win-x86_64..\swcommon\inc;S:\sw\win-x86_64..\swcommon\Includes;%(AdditionalIncludeDirectories)
%(PreProcessorDefinitions);NDIS_WDM=1;POOL_NX_OPTIN=1;NDIS630=1;WIN32;PT_DEBUG=1;OS_TAG_ENABLED;PT_KERNEL=1;PT_NDIS=1;NDIS_SUPPORT_NDIS620=1;NDISLWF=1;DIS_USE_MAP=1;DIS_SUPPORT_PIT=1;DIS_SUPPORT_PIG=1;PCAP_FILTER_SUPPORT=1;PIG_LOGTOBUFFER=1;PIG_QUEUESENDPACKETS=1;GDR_LOCK_WAITER_ACCESS=1;GTR_LOCK_WAITER_ACCESS=1;GDR_PACKETS_POOL=1;GDR_ONLY_PROCESS_RESEND_DURING_MAINTENANCE=1;GTR_SUPPORT_CANCEL=1
%(DisableSpecificWarnings);4201;4214
precomp.h
NotUsing


%(AdditionalIncludeDirectories);…;.;



%(AdditionalDependencies);ndis.lib




Level4
false
…;.;S:\sw\win-x86_64..\inc;S:\sw\win-x86_64..\Includes;S:\sw\win-x86_64..\swcommon\inc;S:\sw\win-x86_64..\swcommon\Includes;%(AdditionalIncludeDirectories)
%(PreProcessorDefinitions);NDIS_WDM=1;POOL_NX_OPTIN=1;NDIS630=1;WIN32;PT_DEBUG=1;OS_TAG_ENABLED;PT_KERNEL=1;PT_NDIS=1;NDIS_SUPPORT_NDIS620=1;NDISLWF=1;DIS_USE_MAP=1;DIS_SUPPORT_PIT=1;DIS_SUPPORT_PIG=1;PCAP_FILTER_SUPPORT=1;PIG_LOGTOBUFFER=1;PIG_QUEUESENDPACKETS=1;GDR_LOCK_WAITER_ACCESS=1;GTR_LOCK_WAITER_ACCESS=1;GDR_PACKETS_POOL=1;GDR_ONLY_PROCESS_RESEND_DURING_MAINTENANCE=1;GTR_SUPPORT_CANCEL=1
%(DisableSpecificWarnings);4201;4214
precomp.h
NotUsing


%(AdditionalIncludeDirectories);…;.;



%(AdditionalDependencies);ndis.lib




Level4
false
…;.;S:\sw\win-x86_64..\inc;S:\sw\win-x86_64..\Includes;S:\sw\win-x86_64..\swcommon\inc;S:\sw\win-x86_64..\swcommon\Includes;%(AdditionalIncludeDirectories)
%(PreProcessorDefinitions);NDIS_WDM=1;POOL_NX_OPTIN=1;NDIS630=1;WIN32;PT_DEBUG=1;PT_64=1;OS_TAG_ENABLED;PT_KERNEL=1;PT_NDIS=1;NDIS_SUPPORT_NDIS620=1;NDISLWF=1;DIS_USE_MAP=1;DIS_SUPPORT_PIT=1;DIS_SUPPORT_PIG=1;PCAP_FILTER_SUPPORT=1;PIG_LOGTOBUFFER=1;PIG_QUEUESENDPACKETS=1;GDR_LOCK_WAITER_ACCESS=1;GTR_LOCK_WAITER_ACCESS=1;GDR_PACKETS_POOL=1;GDR_ONLY_PROCESS_RESEND_DURING_MAINTENANCE=1;GTR_SUPPORT_CANCEL=1
%(DisableSpecificWarnings);4201;4214
precomp.h
NotUsing


%(AdditionalIncludeDirectories);…;.;



%(AdditionalDependencies);ndis.lib




Level4
false
…;.;S:\sw\win-x86_64..\inc;S:\sw\win-x86_64..\Includes;S:\sw\win-x86_64..\swcommon\inc;S:\sw\win-x86_64..\swcommon\Includes;%(AdditionalIncludeDirectories)
%(PreProcessorDefinitions);NDIS_WDM=1;POOL_NX_OPTIN=1;NDIS630=1;WIN32;PT_DEBUG=1;PT_64=1;OS_TAG_ENABLED;PT_KERNEL=1;PT_NDIS=1;NDIS_SUPPORT_NDIS620=1;NDISLWF=1;DIS_USE_MAP=1;DIS_SUPPORT_PIT=1;DIS_SUPPORT_PIG=1;PCAP_FILTER_SUPPORT=1;PIG_LOGTOBUFFER=1;PIG_QUEUESENDPACKETS=1;GDR_LOCK_WAITER_ACCESS=1;GTR_LOCK_WAITER_ACCESS=1;GDR_PACKETS_POOL=1;GDR_ONLY_PROCESS_RESEND_DURING_MAINTENANCE=1;GTR_SUPPORT_CANCEL=1
%(DisableSpecificWarnings);4201;4214
precomp.h
NotUsing


%(AdditionalIncludeDirectories);…;.;



%(AdditionalDependencies);ndis.lib




6.2.0.4575


6.2.0.4575


6.2.0.4575


6.2.0.4575























































































































































xxxxx@pleora.com wrote:

The weird x64 suffix seems to be a red herring. When I made a template project to test the SDV it actually did the exact same thing and still worked just fine:

xxxxx@cwarkentin MINGW64 ~/Documents/Visual Studio 2017/Projects/USB Driver1
$ ls
USB Driver1/ USB Driver1.sln USB Driver1x64/ x64/

Here’s the project file.

There’s nothing in your vcxproj that sets either the IntDir or the
OutDir, so that must be getting inherited from other settings files.

I don’t think you told us what build errors you actually see.

It drives me nuts that vcxproj files have so much unnecessary
duplication.  I’ve actually written a tool to optimize my vcxproj files.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Yeah. These are quasi generated files too. We build the drivers as part of a much larger cmake project and do some transforms on vcxproj templates to set them up relative to the source code in a throwaway build folder.

Unfortunately the error isn’t very informative. ‘-1’. Running from the command line it ends up with this:

[INFO] 1 of 2 jobs remaining. Avg(s): 36.00. Std.Dev(s): 0.00[DEBUG] scheduler found for local
[DEBUG] Executing: InterceptedBuild
[DEBUG] cumulative exit code is 1
[FATAL ERROR] Action: InterceptedBuild, failed.
C:\Program Files (x86)\Windows Kits\10\build\windowsdriver.Sdv.targets(136,9): error MSB3073: The command “staticdv /ch
eck /devenv /debug” exited with code -1. [S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEtherne t\ebUniversalProForEthernet.vcxproj]
Done Building Project “S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProFor
Ethernet.vcxproj” (sdv target(s)) – FAILED.

Build FAILED.

“S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj” (sdv
target) (1) ->
(sdv target) ->
C:\Program Files (x86)\Windows Kits\10\build\windowsdriver.Sdv.targets(136,9): error MSB3073: The command “staticdv /
check /devenv /debug” exited with code -1. [S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEther net\ebUniversalProForEthernet.vcxproj]

0 Warning(s)
1 Error(s)

The smvbuild.log shows the linker error. It’s frustrating because it doesn’t seem to say anything beyond ‘link failed.’

Task “Link”
C:\Program Files (x86)\Windows Kits\10\TOOLS\SDV\smv\bin\link.exe /ERRORREPORT:QUEUE /OUT:“S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\x64\ebUniversalProForEthernet.sys” /VERSION:“10.0” /INCREMENTAL:NO /NOLOGO /WX /SECTION:“INIT,d” “C:\Program Files (x86)\Windows Kits\10\lib\10.0.16299.0\km\x64\BufferOverflowK.lib” “C:\Program Files (x86)\Windows Kits\10\lib\10.0.16299.0\km\x64\ntoskrnl.lib” “C:\Program Files (x86)\Windows Kits\10\lib\10.0.16299.0\km\x64\hal.lib” “C:\Program Files (x86)\Windows Kits\10\lib\10.0.16299.0\km\x64\wmilib.lib” ndis.lib /NODEFAULTLIB /MANIFEST:NO /DEBUG /PDB:“S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\x64\ebUniversalProForEthernet.pdb” /SUBSYSTEM:NATIVE,“6.01” /Driver /OPT:REF /OPT:ICF /ENTRY:“GsDriverEntry” /RELEASE /IMPLIB:“S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\x64\ebUniversalProForEthernet.lib” /MERGE:“_TEXT=.text;_PAGE=PAGE” /MACHINE:X64 /PROFILE /guard:cf /kernel /IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,4218,4218,4235 /osversion:10.0 /pdbcompress /debugtype:pdata x64\Release\WFT6_Filter.res
x64\Release\DIS_Hardware.obj
x64\Release\DIS_PlugIn.obj
x64\Release\DPCAP_Filter.obj
x64\Release\GDR_API.obj
x64\Release\GDR_Missing.obj
x64\Release\GDR_Request.obj
x64\Release\GDR_Resend.obj
x64\Release\GDR_ResourceManager.obj
x64\Release\GTR_API.obj
x64\Release\GTR_Buffer.obj
x64\Release\GTR_Resend.obj
x64\Release\LOG_Circular.obj
x64\Release\NET_KMNRXPacket.obj
x64\Release\NET_KMNUtil.obj
x64\Release\NET_RXPacketManager.obj
x64\Release\OS_GENMemoryPool.obj
x64\Release\OS_KMNEvent.obj
x64\Release\OS_KMNInit.obj
x64\Release\OS_KMNLock.obj
x64\Release\OS_KMNMemoryMap.obj
x64\Release\OS_KMNRWLock.obj
x64\Release\OS_KMNSemaphore.obj
x64\Release\OS_KMNThread.obj
x64\Release\OS_KMNTimer.obj
x64\Release\OS_KMShareMemory.obj
x64\Release\OS_WINOptimizedMemcpy.obj
x64\Release\sprintf_mod.obj
x64\Release\PCAP_Filter.obj
x64\Release\PIG.obj
x64\Release\PIT.obj
x64\Release\WFT6_CpuUsage.obj
x64\Release\WFT6_Device.obj
x64\Release\WFT6_Filter.obj
x64\Release\WFT6_Global.obj

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(673,5): error MSB6006: “link.exe” exited with code 1. [S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj]
Done executing task “Link” – FAILED.
Done building target “Link” in project “ebUniversalProForEthernet.vcxproj” – FAILED.
Done Building Project “S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj” (rebuild target(s)) – FAILED.

Build FAILED.

“S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj” (rebuild target) (1) ->
(PrepareForBuild target) ->
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppBuild.targets(377,5): warning MSB8004: Output Directory does not end with a trailing slash. This build instance will add the slash as it is required to allow proper evaluation of the Output Directory. [S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj]

“S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj” (rebuild target) (1) ->
(InfVerif target) ->
S:\sw\swcommon\Libraries\EbTransportLayerLib\WFT6\ebUniversalProForEthernet.inf(43-43): warning 1205: Section [ebUniversalProForEthernet.copyfiles.sys] referenced from DelFiles and CopyFiles directive. [S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj]

“S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj” (rebuild target) (1) ->
(ClCompile target) ->
s:\sw\swcommon\libraries\ebtransportlayerlib\os\os_kmnrwlock.c(18): warning C4100: ‘aLock’: unreferenced formal parameter [S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj]

“S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj” (rebuild target) (1) ->
(Link target) ->
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(673,5): error MSB6006: “link.exe” exited with code 1. [S:\sw\win-x86_64\Drivers\eBUSUniversalProForEthernet\ebUniversalProForEthernet\ebUniversalProForEthernet.vcxproj]

3 Warning(s)
1 Error(s)

Hmm…rooting around deeper in the logs under the smv folder I found an smvlink2.log with this:

slamlink {
slamlink invoked with args [–lib]
scan {
objfiles:
libfiles:
outfile: slam.lib
scan }
slam: error: slamlink: at least one obj or lib file must be given as input
Unexpected exception in slamlink at phase 0
Unexpected exception in slamlink: Failure(“slamlink: at least one obj or lib file must be given as input”)
error at slamlink }

I’m now looking at the commandline to link.exe above where all the object files are on subsequent lines. I wonder if that’s it.

I went back to the template project and looked at its link line and it has this:

C:\Program Files (x86)\Windows Kits\10\TOOLS\SDV\smv\bin\link.exe /ERRORREPORT:QUEUE /OUT:“S:\Documents\Visual Studio 2017\Projects\USB Driver1\USB Driver1x64\Release\USBDriver1.sys” /VERSION:“10.0” /INCREMENTAL:NO /NOLOGO /WX /SECTION:“INIT,d” “C:\Program Files (x86)\Windows Kits\10\lib\10.0.16299.0\km\x64\BufferOverflowFastFailK.lib” “C:\Program Files (x86)\Windows Kits\10\lib\10.0.16299.0\km\x64\ntoskrnl.lib” “C:\Program Files (x86)\Windows Kits\10\lib\10.0.16299.0\km\x64\hal.lib” “C:\Program Files (x86)\Windows Kits\10\lib\10.0.16299.0\km\x64\wmilib.lib” “C:\Program Files (x86)\Windows Kits\10\lib\wdf\kmdf\x64\1.15\WdfLdr.lib” “C:\Program Files (x86)\Windows Kits\10\lib\wdf\kmdf\x64\1.15\WdfDriverEntry.lib” usbdex.lib ntstrsafe.lib “C:\Program Files (x86)\Windows Kits\10\lib\10.0.16299.0\km\x64\wpprecorder.lib” /NODEFAULTLIB /MANIFEST:NO /DEBUG /PDB:“S:\Documents\Visual Studio 2017\Projects\USB Driver1\USB Driver1x64\Release\USBDriver1.pdb” /SUBSYSTEM:NATIVE,“10.00” /Driver /OPT:REF /OPT:ICF /ENTRY:“FxDriverEntry” /RELEASE /IMPLIB:“S:\Documents\Visual Studio 2017\Projects\USB Driver1\USB Driver1x64\Release\USBDriver1.lib” /MERGE:“_TEXT=.text;_PAGE=PAGE” /MACHINE:X64 /PROFILE /guard:cf /kernel /IGNORE:4198,4010,4037,4039,4065,4070,4078,4087,4089,4221,4108,4088,4218,4218,4235 /osversion:10.0 /pdbcompress /debugtype:pdata x64\Release\Device.obj
x64\Release\Driver.obj
x64\Release\Queue.obj
lib is x64\Release
lib is C:\Program Files (x86)\Windows Kits\10\lib\10.0.16299.0\km\x64
lib is C:\Program Files (x86)\Windows Kits\10\lib\wdf\kmdf\x64\1.15
lib is S:\Documents\Visual Studio 2017\Projects\USB Driver1\USB Driver1x64\Release

And now I’m seeing the first line in the link line is a ‘res’ file. That doesn’t seem right. Investigating.

Yes, that could definitely be it.

In MY experience, if my project doesn’t build clean, it won’t necessarily build at all under SDV and the error(s) reported by SDV may or may not be helpful.

Peter
OSR
@OSRDrivers

Thanks Peter. The res file seems also to be a red herring. I’ll experiment with cleaning/suppressing the warnings and see if that helps. Frustrating tool.

I agree that it CAN be. Sadly. VERY frustrating.

Yet, when it WORKS… it can catch some AMAZING things. I was an SDV basher for a *very* long time. Then it finally reached a point where, for my projects at least, it suddenly started to add value. It’s been a difficult transition over the past few versions – Here at OSR we’ve found some pretty frustrating bugs.

Anyhow… good luck and keep us apprised of your progress,

Peter
OSR
@OSRDrivers

Thanks. I had an idea last night that I’d like to try to make an empty standalone project and then dump the source files into it and see if it works from there. Should narrow things down to my larger solution environment or the source code itself.

So creating a new project out of all the existing sources seems to do the trick and SDV runs. Now I can carefully consider the differences between the projects and hopefully get to the bottom of it.

Oddly almost all my results are ‘Give Up’ so I’ll have to figure out what that means. Also odd but it claims 0 defects found and yet nullcheck returned Error. I guess there’s a learning curve to this tool.

Thanks for all the help so far. Much appreciated after a couple days of banging my head against it.

I’m getting lead down some very strange rabbit holes trying to get SDV running but I think my project is going to be much stronger in the end.

I’ve been looking at diffs of the working and non-working vcxproj and trying to make them converge. Suddenly my original project won’t build properly in VS anymore either with a bunch of complaints like this:

1>ApiValidation : warning : API SetupOpenLog in setupapi.dll is not a supported universal API. WdfCoinstaller01011.dll calls this API.
1>ApiValidation : warning : API SetupPromptReboot in setupapi.dll is not a supported universal API. WdfCoinstaller01011.dll calls this API.
1>C:\Program Files (x86)\Windows Kits\10\build\WindowsDriver.common.targets(1770,5): error MSB3721: The command "“C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64\ApiValidator.exe” -DriverPackagePath:S:\sw\win-x86_64\x64\Release\ -SupportedApiXmlFiles:“C:\Program Files (x86)\Windows Kits\10\build\universalDDIs\x64\UniversalDDIs.xml” -ModuleWhiteListXmlFiles:“C:\Program Files (x86)\Windows Kits\10\build\universalDDIs\x64\ModuleWhiteList.xml” -ApiExtractorExePath:“C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64"” exited with code -1.

What’s weird is that the working project is ALSO a universal driver (that’s why I copied the setting) and it’s ALSO running the API validater and it’s using the exact same INF file with the coinstaller specified. It doesn’t have any of these errors which doesn’t make any sense.

This got me questioning coinstallers in general and leads me to https://www.osr.com/nt-insider/2016-issue1/bye-bye-co-installers/. So if I’m building on Windows 10 but targeting Windows 7 I should still be able to remove the coinstaller as long as I’m using KMDF 1.11?

Turns out the inf file had a variable for coinstaller version so that explains the lack of APIValidator warnings.

Still leaves me wondering if I can get rid of it though and whether KMDF version is behind my SDV problems.

VICTORY! (sort of)

I figured it out by working backwards until I broke the original project. It turns out that it needs the wdfcoinstaller DLL in the right place in order to link properly. I guess it’s looking for it in the build output folder so for SDV it’s not there since it’s a different location.

This brings up a question though. Our build seems to do some wacky stuff by copying the coinstaller DLL into there as part of the build process. It feels awkward and hacky but I don’t really know what is the right way to do it. Is there any best practice for getting that DLL to a place where it can be signed and packaged with the sys file?

xxxxx@pleora.com wrote:

This brings up a question though. Our build seems to do some wacky stuff by copying the coinstaller DLLinto there as part of the build process. It feels awkward and hacky but I don’t really know what is the right way to do it. Is there any best practice for getting that DLL to a place where it can be signed and packaged with the sys file?

Why does it feel awkward?  If your INF mentions the co-installer, then
that DLL is literally part of your driver package, and needs to be
copied into the package folder.  Is this being done as part of the
vcxproj file?  There are build tasks for copying files like this.

Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Yay! I?m glad you found the issue. Good old SDV…

You can use a driver ?package? project to agglomerate all the build products you need (sys file, DLL, INF, certificate file) into one place. It?s actually quite handy.

Peter
OSR
@OSRDrivers

@TimRoberts it was feeling awkward mostly because I didn’t understand at the time that it’s actually inf2cat that was copying the coinstaller. That feels more sane than when I thought we had some weird script doing it.

@PeterV We’re using a driver package project but I’m not entirely sure that it’s done the way that it SHOULD be. It seems like it does nothing on its own but just has a big fat post-build script that copies everything around and signs them and such. I think it’s leftover from our legacy circa 2012 projects.

I’m still left with the problem of getting SDV to have access to the coinstaller. The ‘normal’ build process puts it where it belongs but SDV seems to build everything elsewhere and I don’t see how I can convince it to get the coinstaller as well.

Ha! I was getting a sense of deja-vu and I’ve been down this road before.

https://osronline.com/showthread.cfm?link=272884

Almost 2 1/2 years ago I had done some work on revitalizing these projects that you had given some guidance with. I’ve been on completely unrelated work (embedded FPGA, non-windows) for a couple years and am just coming back and trying to page this all back into my head.

In any event, the big push now is to integrate our legacy projects into VS2017, HLK, driver certification, etc. I’m taking them back to first principles and trying to make them fit into current driver best practices but keep hitting weird road blocks.

Thanks again for all the help. I’ll keep plugging away and reading the docs.