wdk rc1015 cannot open include file 'winres.h'. RRS feed

  • Question

  • vs2019 wdk 18362 can not create resource.h  xxx.rc . 

    1) Open VS
    2) Create a new empty KMDF driver project
    3) On solution explorer right-click the project and select Add -> Resource...
    4) A message box reports <<fatal error RC1015: cannot open include file 'winres.h'.>>

    vs team say it's wdk team question.


    Thank you for your feedback. We have determined that this issue belongs to Windows Driver Kit , we have another bug on Windows Driver Kit team to track this issue ,so close this VS feedback as external . Thank you for helping us build a better Visual Studio.

    • Edited by MurRay丶 Tuesday, August 20, 2019 8:36 AM wrong word
    Tuesday, August 20, 2019 1:51 AM

All replies

  • Windows drivers usually don't need any resources besides of version, which is optional. Until you find a proper solution, you can just continue working without the version resource.

    (Or try to stick the version resource onto your .sys file with this - though I haven't touch it many years)

    -- pa

    Tuesday, August 20, 2019 2:27 PM
  • i know, but i think that issues need to be fixed
    Wednesday, August 21, 2019 3:14 AM
  • Thank you for pointing this out, a bug has been filed to investigate and root cause this issue. 
    Thursday, August 22, 2019 5:41 PM
  • hi, have any progress??
    Thursday, August 29, 2019 2:02 AM
  • The bug is still active but has not been addressed.
    Wednesday, September 4, 2019 6:49 PM
  • Hello,

    Looking to understand your situation better could you explain what you are looking to do with a resource in a KM driver, as there isn’t a way to use a resource (thinking bitmap, lang file etc.) in KDMF.

    Friday, September 20, 2019 4:57 PM
  • Hej,

    I see that this extremely annoying bug is still there in VisualStudio 2019. Can it really be so difficult to fix? It worked up to VisualStudio 2013. All WDK add-ons since then just seem to screw something up in the VisualStudio installation. So fixing this problem doesn't really look like rocket science, does it?

    What it is needed for? Well, as noted in a number of posts as replies to other questions I have come across today, "a well-written driver has a version resource". How else can a call to GetFileVersionInfo() or VerQueryValue() succeed? How can you reliably audit a system if you can't extract the version of all important files?

    This issue of not being able to get version info into a driver file seems to be even worse by an additional bug that ntverp.h is not processed in recent VisualStudio versions in the way the documentation states. In fact it seems to be completely ignored! 

    How do other users solve this problem? Are they compiling outside of VisualStudio in some console environment? Is there any description of how to do this?

    Tuesday, June 30, 2020 5:31 PM
  • How else can a call to GetFileVersionInfo() or VerQueryValue() succeed? How can you reliably audit a system if you can't extract the version of all important files?

    Check signatures. Well-written drivers are signed.

    driverquery /SI

    -- pa

    Thursday, July 2, 2020 1:42 PM
  • Yes of course I also sign my drivers, these wouldn't install under Windows 10/x64 otherwise, would they?

    But does simply signing a driver also add a version resource to the *.sys binary, I didn't think so. I would have thought that signing only works on the *.cat file. 

    Now it does seem to be the case that installing a signed driver means that the version identification stored in the *.cat or *.inf file is written to the registry but will a call to GetFileVersionInfo() or VerQueryValue() read this information from the registry? I don't think so. I certainly haven't come across that as a solution anywhere in the Microsoft documentation.

    So the current bug (since Vstudio 2015) breaks the ability to call GetFileVersionInfo() or VerQueryValue() on a driver *.sys file, unless you add the version resource manually to the *.res file yourself of course.

    I do think it would be a great help if Microsoft QS went to the trouble of running at least one of the more complete KMDF driver examples from scratch before releasing a new WDF add-on or new VisualStudio version (e.g. the toaster). Currently, it looks very much like fire and forget!


    Thursday, July 2, 2020 4:07 PM
  • Mr. Gardiner, of course you're right, certificates don't add the classic version resource, though they identify the driver and its publisher.

    While the WDK team is working on a proper solution, you can use some Python module for tweaking PE images, or the simple old utility that I've posted above link. This is my response to the annoyance. They got their work to do, and we got our work to do.


    -- pa

    • Edited by Pavel A Thursday, July 2, 2020 5:20 PM
    Thursday, July 2, 2020 5:15 PM