VS2017/WDK10 - can STAMPINF be turned off?

I’ve just started using WDK10 with Visual Studio 2017 running under Windows 7. (SDK 10.0.17134.12 and WDK 10.0.17134.1)

There appears to be no way of turning off the automatic STAMPINF operation.

I have 14 drivers (projects) in my “solution” and the final INF file I produce will be used by all 14, so I don’t want individual INF files. To get round this, I’ve just copied this same INF into each project. It appears that when the target is Windows 10 that lots of INF content checking for invalid fields takes place.

Also for Windows 10 targets the Signability test fails when there is more than one driver in the INF file. For all SYS files other than the one it’s dealing with, it complains that it can’t find them despite all being in the same output folder with the INFs. I would expect a second build pass to locate them.

Is there a way of turning off the STAMPINF operation for Windows 10 targets?

Richard.

I think you are referring to inverif as stampinf doesn’t really do syntax validation on an INF. Errors reported by infverif should be fixed even if the tool is only running on a win10 target.

d

-----Original Message-----
From: xxxxx@lists.osr.com On Behalf Of xxxxx@compuserve.com
Sent: Friday, August 31, 2018 7:44 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] VS2017/WDK10 - can STAMPINF be turned off?

I’ve just started using WDK10 with Visual Studio 2017 running under Windows 7. (SDK 10.0.17134.12 and WDK 10.0.17134.1)

There appears to be no way of turning off the automatic STAMPINF operation.

I have 14 drivers (projects) in my “solution” and the final INF file I produce will be used by all 14, so I don’t want individual INF files. To get round this, I’ve just copied this same INF into each project. It appears that when the target is Windows 10 that lots of INF content checking for invalid fields takes place.

Also for Windows 10 targets the Signability test fails when there is more than one driver in the INF file. For all SYS files other than the one it’s dealing with, it complains that it can’t find them despite all being in the same output folder with the INFs. I would expect a second build pass to locate them.

Is there a way of turning off the STAMPINF operation for Windows 10 targets?

Richard.


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

xxxxx@compuserve.com wrote:

I’ve just started using WDK10 with Visual Studio 2017 running under Windows 7. (SDK 10.0.17134.12 and WDK 10.0.17134.1)

There appears to be no way of turning off the automatic STAMPINF operation.

I have 14 drivers (projects) in my “solution” and the final INF file I produce will be used by all 14, so I don’t want individual INF files. To get round this, I’ve just copied this same INF into each project. It appears that when the target is Windows 10 that lots of INF content checking for invalid fields takes place.

Also for Windows 10 targets the Signability test fails when there is more than one driver in the INF file. For all SYS files other than the one it’s dealing with, it complains that it can’t find them despite all being in the same output folder with the INFs. I would expect a second build pass to locate them.

Is there a way of turning off the STAMPINF operation for Windows 10 targets?

Basically, you can’t use the automatic packaging when you have a
multi-project INF like that.  I like putting 32-bit and 64-bit drivers
in the same INF, and even there I had to disable the
process, although that was a lot easier than the case you’re describing.

I suspect you will need to create a separate vcxproj that just does the
INF file. You may need to edit the vcxproj files by hand to achieve
this, so you can add targets to copy the built drivers into your
intermediate directory, then add /> to trigger the INF process.

Alternatively, you can create a batch file that does the msbuilds, and
then constructs the driver package by hand, copying the pieces into place.


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

The last time I had to do this was with VS2013 when I prepared a 32-bit INF and a 64-bit INF containing info for all 14 drivers. I had a batch file for each OS which:

  1. Copied the 32-bit INF file and 64-bit INF file to “Unsigned32bit” and “Unsigned64bit” folders
  2. Ran STAMPINF on these two INFs using “-a x86” and “-a amd64” respectively.
  3. Copied the appropriate SYS files from where they were built to these “Unsigned” folders.
  4. Copied the SYS and stamped INF files again to “Signed32bit” and Signed64bit" folders
  5. For each driver in these folders, I ran SIGNTOOL.
  6. For each folder I ran INF2CAT, and then SIGNTOOL on the cat.
  7. The two “Signed” folders now contain the deliverable output.

It’s a little bit different from the above as each OS has its own subfolder. The final output folder structure was:

V63Signed\Win7\x32
V63Signed\Win7\x64
V63Signed\Win8\x32
V63Signed\Win8\x64
V63Signed\Win8.1\x32
V63Signed\Win8.1\x64

Had hoped I could dispense with the BAT files for Visual Studio 2017 but I suppose this method is clearer. Hoping that I don’t run into any Attestation signing (which is new to me) problems later.

Richard.

You can exclude the inf file from the build. This worked for me.