Srv2016 WLK: INF file requirements

NTDEV
1

Hi,

I have some questions about the Windows Logo Requirements of Srv2016, in particular on the INF files.

  1. What is the mandatory tool to do the INF file testing for the Logo? old CHKINF? or new InfVerif?

CHKINF does much more warnings then InfVerif. InfVerif only warns that my INF has a custom uninstall section, which I invoke from my C app using SetupAPI calls. This warning alone is strange, since FltMgr minifilters use exactly the same and InfVerif does NOT warn on them, but CHKINF warns much more.

  1. Do warnings from CHKINF mean - test not passed? or only errors are important?

  2. My driver is:

  • UpperFilter for the inbox MS’s class
  • and also a PnP bus driver, with root enumerated parent and some raw children on it.
  • all in the same service and the same binary.
    I need the SPSVCINST_ASSOCSERVICE flag to properly service my root parent.
    Unfortunately, CHKINF flags an error on this flag, due to considering the driver as filter (due to UpperFilters in the INF)
    What is the solution for this? 2 INF files? but they should install the same service. Is it good?

  1. Yet another issue is my raw child devnodes. I copy-pasted the code snippet from the INF of VolSnap.sys to handle them.
    Nevertheless, CHKINF issues a warning on them due to they not containing anything.
    How to work this around? Will the inbox VolSnap.inf pass CHKINF?

  2. What is the proper way of installing a class UpperFilter from the INF file? If I use the explicit registry path of “\CurrentControlSet\Control\Class{guid}”, then CHKINF gives a warning.

  3. What is the proper way of UNinstalling a class UpperFilter from the INF file? For now, I use the custom [MyUninstall] section which does the registry update, and invoke it from my custom C app using SetupDi APIs. But again, CHKINF gives a warning.

I’ve looked at some class filters present on my system, for instance, Creative’s sound stuff. But they seem to just have no uninstall at all, which is absolutely unsuitable for us since we need to provide the customers with the clean full uninstall.

  1. FltMgr minifilters definitely have INF-based install, and also uninstall too. Their recommended uninstall sequence is exactly what I’ve described in #6, with probably “rundll32” to be used to execute the uninstall INF section. And how funny! CHKINF does NOT cause any warnings on their uninstall INF section. Why is this?

  2. What is the general recommended solution to the above issues? 2 INF files? or moving all functionality, except the PnP one, to the custom C app, and avoiding INFs at all costs? but well, item 4 is a PnP issue, and cannot be worked around this way.

Needless to say: everything works for all Windows versions with the existing INF file. I just need the certifiable INF file.

Surely, if there is some HLK-compatible way to just silence the warnings in CHKINF, then it will be good, since I will only have the _ASSOCSERVICE error, which can be silenced by eliminating the UpperFilter install from the INF and moving the logic to the C code of the install app, so that the UpperFilter stuff will not be present in the INF at all.

Also I would be grateful if somebody will describe some other ways of solving the issue.

Max

2

> What is the mandatory tool to do the INF file testing for the Logo? old CHKINF? or new InfVerif?

Currently they are both required, as ChkInf has a few necessary tests that InfVerif couldn’t cover at the time of the last HLK release. ChkInf will be removed in an upcoming release.

InfVerif only warns that my INF has a custom uninstall section, which I invoke from my C app
using SetupAPI calls. This warning alone is strange, since FltMgr minifilters use exactly the same and InfVerif does NOT warn on them, but CHKINF warns much more.

Warnings in InfVerif indicate that the INF parser sees something that it can’t determine whether or not it’s a problem. A section that isn’t referenced anywhere in the INF could be a custom section you’re invoking later (as in this case), or it could be a typo somewhere. The parser doesn’t know your intent, so it’s issuing a warning as a heads up. There are some classes where InfVerif knows specific usage patterns, so this error may not appear in all cases.

Do warnings from CHKINF mean - test not passed? or only errors are important?

For the sake of passing the test, just errors matter.

Unfortunately, CHKINF flags an error on this flag, due to considering the driver as filter (due to UpperFilters in the INF). What is the solution for this?

Can you share your INF? It’s hard for me to advise without seeing it exactly. Ideally the check should be preventing you from putting the same driver as both a filter and function driver on the same stack, although it looks like ChkInf doesn’t check that it’s the same stack.

Nevertheless, CHKINF issues a warning on them due to they not containing anything

It’s fine to ignore this warning.

What is the proper way of installing/UNinstalling…

There’s no proper way really. This looks fine to me.

All that said, I don’t see a conceptual problem with what you’re doing. If I can see your INF, I can advise on specific details and the SPSVCINST_ASSOCSERVICE issue.

3

Thanks!

Can I email the INF to you privately?

Max

wrote in message news:xxxxx@ntdev…
> > What is the mandatory tool to do the INF file testing for the Logo? old CHKINF? or new InfVerif?
>
> Currently they are both required, as ChkInf has a few necessary tests that InfVerif couldn’t cover at the time of the last HLK release. ChkInf will be removed in an upcoming release.
>
>> InfVerif only warns that my INF has a custom uninstall section, which I invoke from my C app
> using SetupAPI calls. This warning alone is strange, since FltMgr minifilters use exactly the same and InfVerif does NOT warn on them, but CHKINF warns much more.
>
> Warnings in InfVerif indicate that the INF parser sees something that it can’t determine whether or not it’s a problem. A section that isn’t referenced anywhere in the INF could be a custom section you’re invoking later (as in this case), or it could be a typo somewhere. The parser doesn’t know your intent, so it’s issuing a warning as a heads up. There are some classes where InfVerif knows specific usage patterns, so this error may not appear in all cases.
>
>> Do warnings from CHKINF mean - test not passed? or only errors are important?
>
> For the sake of passing the test, just errors matter.
>
>> Unfortunately, CHKINF flags an error on this flag, due to considering the driver as filter (due to UpperFilters in the INF). What is the solution for this?
>
> Can you share your INF? It’s hard for me to advise without seeing it exactly. Ideally the check should be preventing you from putting the same driver as both a filter and function driver on the same stack, although it looks like ChkInf doesn’t check that it’s the same stack.
>
>> Nevertheless, CHKINF issues a warning on them due to they not containing anything
>
> It’s fine to ignore this warning.
>
>> What is the proper way of installing/UNinstalling…
>
> There’s no proper way really. This looks fine to me.
>
>
> All that said, I don’t see a conceptual problem with what you’re doing. If I can see your INF, I can advise on specific details and the SPSVCINST_ASSOCSERVICE issue.
>

4

Yep, go for it. You’ll probably have to rename it to .in_ or .txt to get through any e-mail filters.