Many years ago, I had built an INF file template for an audio KS driver that can be customized by changing the [Strings] section only. Resulting INF files are successfully installed in all Windows versions from XP to latest Win10. inf2cat from WDK 7600.16385.1 reports no errors in such files.
But if I try to use inf2cat from latest WDKs (including WDK 10.0.15063), it fails:
22.9.10: %driverfile% in [devinst.drivermodules] is missing from [SourceDisksFiles] section in myproject\mydriver.inf; driver may not sign correctly until this is resolved.
The same inf2cat behavior is observed on SysDev portal on driver signing submission.
Related sections in the INF file:
=================
[SourceDisksFiles.x86]
%DriverFile% = 222, \x86
[SourceDisksFiles.amd64]
%DriverFile% = 222, \x64
[DevInst.DriverModules]
%DriverFile%
If I replace %DriverFile% with actual driver file name, new inf2cat show no errors.
Obviously, new inf2cat does not expand string variables while checking source file sections.
Where to report this inf2cat bug?
On 05/12/17 11:47 AM, xxxxx@muzychenko.net wrote:
Many years ago, I had built an INF file template for an audio KS driver that can be customized by changing the [Strings] section only. Resulting INF files are successfully installed in all Windows versions from XP to latest Win10. inf2cat from WDK 7600.16385.1 reports no errors in such files.
But if I try to use inf2cat from latest WDKs (including WDK 10.0.15063), it fails:
Since it worked with the older inf2cat this seems unlikely, but you
might double-check that all your line endings are consistently CRLF.
Earlier this year I had trouble getting stampinf to expand macros and
finally realized it doesn’t grok LF. It squashed all lines to be part
of the first line which was a comment, and macros are not replaced in
comments.
-Nathan
>you might double-check that all your line endings are consistently CRLF.
Thank you for the suggestion but all line endings in the file are really CR/LF (just checked to be sure). Moreover, there are empty lines before and after each of lines in my example. Even more, I had cross-tested it, replacing %DriverFile% with actual file name, running inf2cat, replacing file name with %DriverFile% back, and running inf2cat again.
xxxxx@muzychenko.net wrote:
> you might double-check that all your line endings are consistently CRLF.
Thank you for the suggestion but all line endings in the file are really CR/LF (just checked to be sure). Moreover, there are empty lines before and after each of lines in my example. Even more, I had cross-tested it, replacing %DriverFile% with actual file name, running inf2cat, replacing file name with %DriverFile% back, and running inf2cat again.
No, there’s no need to check anything else. Remember, the complete
source code for ChkInf is included in the WDK. I just checked, and
indeed it does not expand strings within a CopyFiles section.
From the beginning of time ;), perhaps the biggest flaw in the INF world
is that there has never been a definitive syntax description. It’s all
just crap that has accreted over the decades without any consistency or
centralized control. The sections do not all follow the same rules, and
there is no place that definitively states where %strings% are allowed
and where they are not. It’s clearly not a general purpose macro
language, so without rules, we just have to guess.
Thus, the authors of ChkInf could argue that they are following the
documentation, because the documentation does not state whether this is
supposed to work or not. The fact that the operating system DOES seem
to expand strings suggests that ChkInf ought to do so as well.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
This is part of the reason ChkInf was deprecated a few years ago ??? It is probably the least reliable source of INF truth that MS released.
However, InfVerif can be used as the de facto source of INF truth. It internally uses the OS INF parser, so it has no divergence at all. InfVerif will point out if there are any %string% tokens in the file that do not get replaced (and FYI, they will be replaced anywhere in the file as long as there is a match in [strings]).
Also interesting, we re-wrote the INF parser in Win8, and it is *way* more consistent and coherent than it was before that point. You won’t find the same sort of differences between how various things get handled any more. Unfortunately, inf2cat was implemented before the new parser, and works much more closely to how ChkInf works. We’re working on switching inf2cat over.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: Wednesday, December 6, 2017 10:00 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] inf2cat 22.9.10: the tool does not expand a variable
xxxxx@muzychenko.net wrote:
>> you might double-check that all your line endings are consistently CRLF.
> Thank you for the suggestion but all line endings in the file are really CR/LF (just checked to be sure). Moreover, there are empty lines before and after each of lines in my example. Even more, I had cross-tested it, replacing %DriverFile% with actual file name, running inf2cat, replacing file name with %DriverFile% back, and running inf2cat again.
No, there’s no need to check anything else. Remember, the complete source code for ChkInf is included in the WDK. I just checked, and indeed it does not expand strings within a CopyFiles section.
From the beginning of time ;), perhaps the biggest flaw in the INF world is that there has never been a definitive syntax description. It’s all just crap that has accreted over the decades without any consistency or centralized control. The sections do not all follow the same rules, and there is no place that definitively states where %strings% are allowed and where they are not. It’s clearly not a general purpose macro language, so without rules, we just have to guess.
Thus, the authors of ChkInf could argue that they are following the documentation, because the documentation does not state whether this is supposed to work or not. The fact that the operating system DOES seem to expand strings suggests that ChkInf ought to do so as well.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
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:>
The most significant problem for me is that latest inf2cat versions are used to check INF files on SysDev driver signing submission. It marks INF file that is fully compatible with all Windows versions from Win2000 to Win10 as invalid, so there is no way to get MS signature for a driver with such INF file.
On Dec 6, 2017, at 6:33 PM, xxxxx@muzychenko.net wrote:
>
> The most significant problem for me is that latest inf2cat versions are used to check INF files on SysDev driver signing submission. It marks INF file that is fully compatible with all Windows versions from Win2000 to Win10 as invalid, so there is no way to get MS signature for a driver with such INF file.
Yes, we know, but it’s easy to work around. A simple script to do the macro substitution, and off you go.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Of course, workaround is easy, but the aftertaste… 
Not only that MS forced me to submit each driver release to SysDev for signing, but cannot even process a valid INF file.