wdfcoinstaller not being copied during build

NTDEV
1

I’ve inherited a driver project and unfortunately don’t have a lot of background in driver development. Forgive me if my terminology is off but this problem is a little weird and I’ve run out of ideas.

It’s a KMDF USB driver in a Visual Studio 2012 solution with a driver project and a package project. We’ve been porting all of our other code to a new build system but this one has been pretty much left alone and just dropped into the new build as-is.

When I first started working with it I was having a problem that the driver would build but the packaging would fail. Using ProcMon to trace a working build I determined that at some point in the build, MSBuild would copy the wdfcoinstaller dll of the appropriate version into the build output directory and then the packaging script calling stampinf, makecat, etc. would do it’s magic. When the wdfcoinstaller dll isn’t there, makecat complains and the build fails.

The script looks like this:

pushd $(PackageDir)
$(STAMPINF_TOOL) -f ebUniversalProForU3V.inf -d * -v $(EBUS_VERSION_MAJOR).$(EBUS_VERSION_MINOR).$(EBUS_VERSION_SUB).$(EBUS_VERSION_BUILD)
copy $(SolutionDir)\ebUniversalProForU3V.cdf .
$(MAKECAT_TOOL) -v ebUniversalProForU3V.cdf
del ebUniversalProForU3V.cdf
$(SIGN_TOOL) sign /ac “$(CO_CERTIFICATE_RELEASE)” /s my /n Pleora /t http://timestamp.verisign.com/scripts/timestamp.dll ebUniversalProForU3V.sys
$(SIGN_TOOL) sign /ac “$(CO_CERTIFICATE_RELEASE)” /s my /n Pleora /t http://timestamp.verisign.com/scripts/timestamp.dll ebUniversalProForU3V.cat
popd

and produces this output:

2>C:\Program Files (x86)\Windows Kits\8.0\build\WindowsDriver8.0.common.targets(1338,5): error : Verification Error: Driver package has no driver version.
2>C:\Program Files (x86)\Windows Kits\8.0\build\WindowsDriver8.0.common.targets(1338,5): error : INF file S:\sw\Drivers\ebUniversalProForU3V\ebUniversalProForU3V\x64\Win7Debug\ebUniversalProForU3V.inf fails validation.
2> Done Adding Additional Store
2> Successfully signed: S:\sw\Drivers\ebUniversalProForU3V\x64\Win7Debug\ebUniversalProForU3V.cat
2>
2> Stamping .\ebUniversalProForU3V.inf [Version] section with DriverVer=01/08/2016,5.2.2.3717
2> 1 file(s) copied.
2> opened: ebUniversalProForU3V.cdf
2> attribute: OSAttr
2> processing: File1
2> processing: File2
2> NOT processed: member file does not exist (.\WdfCoinstaller01011.dll)
2>Failed : CryptCATCDFEnumMembersByCDFTagEx. Last error : 0x00000002
2>
2> Errors found in parsing the CDF file
2> Done Adding Additional Store
2> Successfully signed and timestamped: ebUniversalProForU3V.sys
2>
2> Done Adding Additional Store
2> Successfully signed and timestamped: ebUniversalProForU3V.cat

I don’t know what I did but at some point it started working for me. The driver built properly and everything was good. So here’s what’s weird. At some point in the last couple weeks, it started failing for me again. The project builds fine on our build machine and some other developers machines. My machine and another one of our devs get the failure. I traced it with ProcMon and I see MSBuild (and devenv) actually opening up wdfcoinstaller01011.dll in the ddk directory but it never does the copy.

There’s a bunch of things I don’t understand about how this project is laid out. The driver project seems to do a bunch of things like calling stampinf and such already and the packaging project seems like it’s repeating things. I’m not sure why it’s manually calling things like stampinf and makecat in a script when it seems like the project itself has the ability to do all these things.

Anyway, I’m at the end of my rope so I hope someone can at least give me an idea of something to try. I had installed the driver on my dev machine at one point which installed the coinstaller in the underlying OS so I thought that might be it but uninstalling it didn’t seem to help. Any other ideas?

cheers,

Chris

2

xxxxx@pleora.com wrote:

I’ve inherited a driver project and unfortunately don’t have a lot of background in driver development. Forgive me if my terminology is off but this problem is a little weird and I’ve run out of ideas.

It’s a KMDF USB driver in a Visual Studio 2012 solution with a driver project and a package project. We’ve been porting all of our other code to a new build system but this one has been pretty much left alone and just dropped into the new build as-is.

When I first started working with it I was having a problem that the driver would build but the packaging would fail. Using ProcMon to trace a working build I determined that at some point in the build, MSBuild would copy the wdfcoinstaller dll of the appropriate version into the build output directory and then the packaging script calling stampinf, makecat, etc. would do it’s magic. When the wdfcoinstaller dll isn’t there, makecat complains and the build fails.

The script looks like this:

Are you running this script IN ADDITION TO the packaging that Visual
Studio does? You might consider not doing that.

The complaint is that your INF does not have a DriverVer line in the
[Version] section. The “stampinf” line will add or replace the
DriverVer line, but as you can see in the log, your stamping is not
happening until after the Visual Studio verification step.

In the short term, therefore, the quick answer is to add a dummy
DriverVer line to the [Version] section in your INF. That should stop
the complaints. You can see what the format has to be.

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

3

First of all, thank you very much. Adding a dummy version entry to the inf file seems to do the trick for me. Apparently failing the validation causes the skipping of the wdfcoinstaller copy.

Are you running this script IN ADDITION TO the packaging that Visual
Studio does? You might consider not doing that.

I would love to but I don’t understand why it is the way it is and don’t want to change what I don’t understand. This is product that has been shipped for years. Is it necessary to have separate building and packaging projects in the solution? When I look at the package project properties there are all sorts of sections like “Driver Install”, “StampInf”, etc. that are all disabled and instead there’s just this script in post-build.

The complaint is that your INF does not have a DriverVer line in the
[Version] section. The “stampinf” line will add or replace the
DriverVer line, but as you can see in the log, your stamping is not
happening until after the Visual Studio verification step.

So I skipped a bit of the initial output but here’s a more detailed description of the steps. I’m trying to understand this process a bit better. Perhaps I don’t quite get what stampinf does.

It actually seems to run twice. Once just before the driver is built and then again at the start of the packaging process. Succeeds both times and copies of the inf file are put into the various build output folders. Question though. They still have the dummy version in them. Should stampinf not edit that dummy section with the version that was given it on the command line?

The driver version seems to be correct when I right click on it but shouldn’t the inf file have the same version?

4

xxxxx@pleora.com wrote:

I would love to but I don’t understand why it is the way it is and don’t want to change what I don’t understand. This is product that has been shipped for years.

Well, there’s something to be said for “if it ain’t broke, don’t fix it”.

Is it necessary to have separate building and packaging projects in the solution? When I look at the package project properties there are all sorts of sections like “Driver Install”, “StampInf”, etc. that are all disabled and instead there’s just this script in post-build.

Remember that there was a big change from the Windows 7 WDK to the
Windows 8 WDK. In the past, you had to write your own scripts to do WDK
builds, and many of them were quite elaborate. With WDK 8 and the
integration with Visual Studio, now things that used to be scripted are
embedded in Visual Studio project files. Because of unfamiliarity, many
people reinvented what VS was already doing.

So I skipped a bit of the initial output but here’s a more detailed description of the steps. I’m trying to understand this process a bit better. Perhaps I don’t quite get what stampinf does.

It actually seems to run twice. Once just before the driver is built and then again at the start of the packaging process. Succeeds both times and copies of the inf file are put into the various build output folders. Question though. They still have the dummy version in them. Should stampinf not edit that dummy section with the version that was given it on the command line?

Yes, that’s its purpose. It leaves the dummy version in the source
directory, then copies that to the output directory and runs stampinf.
Stampinf will replace the DriverVer, fix up some symbols (like $ARCH$),
fills in the KMDF version, and one or two other things. Perhaps you
need to double-check the script to see what paths it is using.

The driver version seems to be correct when I right click on it but shouldn’t the inf file have the same version?

That depends on your internal processes. It’s not necessary for the
driver binary version (SYS) and the driver package version (INF) to be
the same.

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