none
INFGate Post-Build Event Configuration Error in VS2013Pre Print Driver Template RRS feed

  • Question

  • The print driver template in VS2013Pre appears to be wrong when it comes to running INFGate in the post-build event given the template is also using StampInf.  The post-build event command line tells INFGate to inspect the original pre-StampInf version of the INF file, rather than the post-StampInf version of the INF file.  The silver lining to this cloud was that figuring this out gave me a big education in StampInf and INFGate.

    Current post-build event command line in template is:

    "$(WDKContentRoot)$(INFGateToolPath)INFGate.exe" V4PrintDriver.inf /WDK

    Correct command line should be:

    "$(WDKContentRoot)$(INFGateToolPath)INFGate.exe" $(IntDir)V4PrintDriver.inf /WDK

    This is more that a bit difficult to figure out given the StampInf configuration settings under VS don't include any hints about where StampInf is finding its source file and writing its target file.  It was necessary to read through the verbose build output to see what was happening.

    UPDATE:

    The above "fix" is the right idea, but leads to a cascade of file reference problems.  INFGate gets mad that the .inf file references the -manifest.ini file which isn't in the $(IntDir). Copying the -manifest.ini file to $(IntDir) then triggers a complaint that the .gpd file referenced in the -manifest.ini file isn't there.

    Here's the post-build event that currently has INFGate happy, and which is a bit more generic:

    COPY $(TargetName).gpd $(IntDir)
    COPY $(TargetName)-manifest.ini $(IntDir)
    "$(WDKContentRoot)$(INFGateToolPath)INFGate.exe" $(IntDir)$(TargetName).inf /WDK

    It works for the print driver template.  Not sure how messy it'll become as a developer starts adding things beyond the starting template.  It requires making sure all the files that are part of cascading references get copied into $(IntDir) for INFGate can find them.


    -- kburgoyne


    • Edited by kburgoyne Friday, July 19, 2013 12:25 AM Update
    Thursday, July 18, 2013 11:50 PM

Answers

  • Hi kburgoyne,

    Thanks for your detailed reply. A few comments:

    1. The print driver template included in the WDK only supports building a v4 print driver. These drivers do not run on Windows 7 unless they are installed to a Windows 8/8.1 or Windows Server 2012/Windows Server 2012 R2 machine and shared out. In other words, Windows 7 cannot run v4 print drivers locally.
    2. I have not been able to repro any issues associated with INFGate failing to properly validate a pre-StampINF'd version of the driver. It should work adequately in the default configuration.
    3. You should add the certificate that signed your driver to your certificate store to get signing issues out of the way. The tool "certmgr" will help you with this. If you configure remote deployment, this will happen automatically on the client you target. You could even set up a VM to be your target machine. Example commands:
      • .\CertMgr.exe -add certname.cer -c -s -r localMachine root
      • .\CertMgr.exe -add certname.cer -c -s -r localMachine TrustedPublisher
    4. Print drivers don't use WudfUpdate01011.dll, so you are right not to reference it in the INF. This is included in the base driver templates as UMDF and KMDF drivers use it; sorry for the confusion.
    5. When you try to install a driver using the Add Printer Wizard, also make sure you're going to the right directory, since the INF gets copied to many places. For x64, you'll want <project directory>\x64\Win8Debug\<projectname>\*.inf.

    Thanks!

    Justin

    • Marked as answer by kburgoyne Tuesday, July 23, 2013 1:07 AM
    Monday, July 22, 2013 10:39 PM
  • Thanks for reporting this. I'll open a bug and we'll have a look.
    Friday, July 19, 2013 5:53 PM

All replies

  • Thanks for reporting this. I'll open a bug and we'll have a look.
    Friday, July 19, 2013 5:53 PM
  • I've reached the point of bashing my head against the wall trying to get the template XPS print driver running.  The driver is being installed into the driver store.  I can confirm that from numerous different directions: It's in the driver store folder, the various log files show it being processed and stored, and it appears in the list of drivers available when installing a printer.  Given what should be the simplicity of this driver, I've been avoiding getting all the remote debugging mess working just yet.  I've just been trying to get the template driver installed via "have disk".

    The event log seems to be telling me the problem is an HRESULT of file not found.  Of course, saying "what" file would be far too helpful.  :-)

    The installation log complains about the driver files not matching the CAT file, but there is one line that also hints this just might be because of the test certificate.  There is also a line saying the installation is proceeding because I said (via the UI) that an unsigned driver was okay.  So I'm ASSUMING that's not the issue.  But lacking having everything successfully run while that condition exists, I can't be positive it's not an issue.

    Has anyone successfully built and run the template driver, AS INCLUDED, using VS2013Pre and WDK8.1Pre?  The issue with INFGate complaining about the pre-Stampinf file suggests maybe not.

    To be specific.  I'm trying to build a Win8 Debug x64 version (NOT Win8.1) of the driver using VS2013Pre and WDK8.1Pre.  I'm trying to install and run it on Win7Pro x64.  The Win7Pro system has all the latest updates installed.  I *believe* from the XPS printer driver documentation that such a driver should install under Win7.  Am I correct?

    Considering that I can get a build with no errors or warnings, and the installer will get as far as installing the driver into the driver store, I am assuming I have the "basics" correct.  To confirm, ClassVer in the INF is set to "4.0".

    I have a very big question about "WudfUpdate_01011.dll".  INFGate seems to want to assert that it should not be used with a print driver.  INFGate certainly rejects many of the INF directives that the online documentation says should be added to the INF file for WudfUpdate_01011.dll.  However the build is dumping it into the package folder.  It's a very confusing state of affairs.  Right now I'm including it in the package and the INF file says to copy it, but the INF file does not contain any of the directives associated with a CoInstaller because INFGate doesn't like the key ones.  So basically the DLL is just being copied (confirmed by the log files) but not really referenced -- just like the original template INF doesn't make any effort to use it.

    Would it be possible for somebody to test out the XPS print driver template that's with VS2013Pre and create a Win8 Debug x64 version of it.  Then make available both the binary package and the source that produced the binary?  It would be very useful for confirming that a "properly built" version of the driver will install, thereby eliminating that variable from the problem.  It would also provide a "known good" source of files to compare against.


    -- kburgoyne

    Saturday, July 20, 2013 6:04 PM
  • Hi kburgoyne,

    Thanks for your detailed reply. A few comments:

    1. The print driver template included in the WDK only supports building a v4 print driver. These drivers do not run on Windows 7 unless they are installed to a Windows 8/8.1 or Windows Server 2012/Windows Server 2012 R2 machine and shared out. In other words, Windows 7 cannot run v4 print drivers locally.
    2. I have not been able to repro any issues associated with INFGate failing to properly validate a pre-StampINF'd version of the driver. It should work adequately in the default configuration.
    3. You should add the certificate that signed your driver to your certificate store to get signing issues out of the way. The tool "certmgr" will help you with this. If you configure remote deployment, this will happen automatically on the client you target. You could even set up a VM to be your target machine. Example commands:
      • .\CertMgr.exe -add certname.cer -c -s -r localMachine root
      • .\CertMgr.exe -add certname.cer -c -s -r localMachine TrustedPublisher
    4. Print drivers don't use WudfUpdate01011.dll, so you are right not to reference it in the INF. This is included in the base driver templates as UMDF and KMDF drivers use it; sorry for the confusion.
    5. When you try to install a driver using the Add Printer Wizard, also make sure you're going to the right directory, since the INF gets copied to many places. For x64, you'll want <project directory>\x64\Win8Debug\<projectname>\*.inf.

    Thanks!

    Justin

    • Marked as answer by kburgoyne Tuesday, July 23, 2013 1:07 AM
    Monday, July 22, 2013 10:39 PM
  • Thanks, Justin.  Just today I managed to reach the conclusion that V4 drivers won't work under Win7.  This really isn't documented explicitly anywhere that I've found on the developer web pages that talk about building V4 drivers.  I actually went looking specifically for some declaration of where V4 and V3 drivers work.

    I've backed off the V4 driver and have successfully built and installed the XPSDrvSmpl sample driver instead.

    I restarted a project using the print driver template, and I guess I concur on the INFGate/Stampinf issue.  I thought I had done this why trying to figure out how to address the issue I was seeing.  However if I start back with the template again and follow the instructions for editing the INF very literally, the only complaint is that there should be a "[Standard]" section if the driver is for pre-XP.  I can actually add a "[Standard]" section and make the error go away without introducing any other errors.

    Thanks for the CertMgr info.

    After following the online instructions for editing the INF file in the template, I don't really see a reason why the template shouldn't just already include all those edits. There is a WHOLE LOT to be said for the template successfully building and deploying right from scratch before the developer touches it. It provides a baseline against which the developer can play the "what did I change that broke it?" game when making changes to the template.


    -- kburgoyne

    Tuesday, July 23, 2013 1:07 AM