Hello,
I’m working on NDIS driver, based on kmdf\ndisedge\60 sample, and I have a problem with chkinf tool with new WDK 2008 when running it on the supplied sample inf (a copy of ndisedge.inx file).
The INF file contains the following section:
[Ndisedge.ndi]
*IfType = 6 ; IF_TYPE_ETHERNET_CSMACD
*MediaType = 0 ; NdisMedium802_3
*PhysicalMediaType = 0 ; NdisPhysicalMediumUnspecified
Characteristics = 0x84 ; NCF_PHYSICAL | NFC_HAS_UI
BusType = 15 ; if you specify NCF_PHYSICAL, you must specify bustype
AddReg = Ndisedge.Reg, ParamsPromiscuous
CopyFiles = Ndisedge.CopyFiles
I run the chkinf command as following:
C:\WinDDK\6001.18001\tools\chkinf\i386>…\chkinf.bat /A /L my.log c:\WinDDK\6001.18001\src\kmdf\ndisedge\60\ndisedge.inf
ChkInf: Copyright (c) 1998-2003 Microsoft Corporation. All rights reserved.
Version: v. 2.5 Created: 10/23/2002
Processing c:\WinDDK\6001.18001\src\kmdf\ndisedge\60\ndisedge.inf -> .\htm\c#+WinDDK+6001@18001+src+kmdf+ndisedge+60+__ndisedge.htm
Module “NET” Loaded
Beginning VerifyModel (NET)…
LearnModel …
sectionName=Msft.NT$ARCH$
Invoking Net::ExpandModelSection…
LearnModels -> AddSection Msft.NT$ARCH$
CheckModel …
Calling VerifyModel … NDISEDGE.NDI
Beginning VerifyModel (NDISEDGE.NDI)…
Beginning GetRegLines ()…
Beginning GetRegLines ()…
Elapsed time : 00h 00m 00s
C:\WinDDK\6001.18001\tools\chkinf\i386>type my.log
c:\WinDDK\6001.18001\src\kmdf\ndisedge\60\ndisedge.inf: FAILED
NTLOG REPORT--------------
Total Lines: 144 |
Total Errors: 2 |
| Total Warnings: 3 |
| Line 13: ERROR: (E22.1.1004) Provider listed is Microsoft, but should be the organization who wrote this INF. |
| Line 41: ERROR: (DE22.19.4001) BusType does not match the NetCard model. |
| Line 0: WARNING: (W22.1.9998) NOTE: The ChkInf tool does not verify the WDF sections and directives of the INF file. |
| Line 125: WARNING: (W22.1.2083) Section [NDISEDGE.NDI.WDF] not referenced |
| Line 127: WARNING: (W22.1.2083) Section [NDISEDGE_WDFSECT] not referenced |
C:\WinDDK\6001.18001\tools\chkinf\i386>
I also tested it with WDK Vista (6000), there it’s working fine.
How should I change the INF file to make chkinf happy?
Thanks,
S.
Sort Answer: Yes.
Medium Answer: These all look to be reasonable error reports to me. I mean, why would you include Microsoft as the provider when they’re not? Why would you include a section in your INF that you don’t use?? Why NOT fix the errors, you know?
Longer Answer: ChkInf can be a real pain in the ass sometimes. Usually, however, what it tells you is basically correct, as long as it understands the type of driver you’re writing. You’re writing a network driver, and it mostly knows about those.
If you want to logo your driver, you’ll HAVE to fix any chkinf problems before you can submit. If you don’t care about the logo, and your INF file appears to be working, and in your considered judgment what you’re doing in your INF is OK, then you can ignore what chkinf tells you (hey, it’s a PERL script that’s only as smart as the guy who wrote it).
Peter
OSR
Hello Peter,
My question was not clear enough, sorry for that. As I mentioned, I used the ndisedge.inx as a reference, that’s why I supplied the output of that file here.
I do understand why there is the error related to incorrect driver vendor and unused sections.
My problem is with the error related to [Ndisedge.ndi] section, which I placed. Here it is again:
[Ndisedge.ndi]
*IfType = 6 ; IF_TYPE_ETHERNET_CSMACD
*MediaType = 0 ; NdisMedium802_3
*PhysicalMediaType = 0 ; NdisPhysicalMediumUnspecified
Characteristics = 0x84 ; NCF_PHYSICAL | NFC_HAS_UI
BusType = 15 ; if you specify NCF_PHYSICAL, you must specify bustype
AddReg = Ndisedge.Reg, ParamsPromiscuous
CopyFiles = Ndisedge.CopyFiles
The problematic error is:
Line 41: ERROR: (DE22.19.4001) BusType does not match the NetCard model
Since that is a USB NDIS driver, the only logical value for BusType is PNPBus ( = 15).
As I also mentioned, this DOES work with older version of WDK (WDK Vista), but doesn’t work with newer WDK (WDK 2008): the same INF file DOESN’T CAUSE that error to occur.
Also: the BusType parameter is required here.
If you want to logo your driver, you’ll HAVE to fix any chkinf problems
I understand that, that’s why I wonder why chkinf doesn’t pass the same sample it did in previous version of DDK. As I could notice, the DTM tools use the newer version of chkinf.
Thanks,
S.
Because, just like every other piece of software on the planet, chkinf is updated with each release. Now, understand: That doesn’t NECESSARILY mean that it gets smarter or more accurate. But that is certainly the hope of its developers.
Have you tried LEAVING OUT the BusType argument? I’m soooo not Mr Network (anymore) but I seem to recall that this argument hasn’t be actually required for several years.
Peter
OSR
> Have you tried LEAVING OUT the BusType argument?
Yes, I tried that, and got an error that it is required for NCF_PHYSICAL.
It should work somehow, otherwise how do NDIS drivers pass WHQL?
Thanks,
S.
Sounds like you need to have a look through the perl script and see what’s necessary to make it happy.
Tried that yet??
Peter
OSR
I have a question about this use of Microsoft as the provider. If you are
creating an in-box driver inf, should it have Microsoft as the provider?
Also since in-box drivers don’t use catalog files for signatures but the
layout.inf file, should chkinf complain?
wrote in message news:xxxxx@ntdev…
> Sort Answer: Yes.
>
> Medium Answer: These all look to be reasonable error reports to me. I
> mean, why would you include Microsoft as the provider when they’re not?
> Why would you include a section in your INF that you don’t use?? Why NOT
> fix the errors, you know?
>
> Longer Answer: ChkInf can be a real pain in the ass sometimes. Usually,
> however, what it tells you is basically correct, as long as it understands
> the type of driver you’re writing. You’re writing a network driver, and
> it mostly knows about those.
>
> If you want to logo your driver, you’ll HAVE to fix any chkinf problems
> before you can submit. If you don’t care about the logo, and your INF
> file appears to be working, and in your considered judgment what you’re
> doing in your INF is OK, then you can ignore what chkinf tells you (hey,
> it’s a PERL script that’s only as smart as the guy who wrote it).
>
> Peter
> OSR
>
>
I compared the scripts from WDK 6000, where it pass, and WDK 6001, where it fails. There are some differences in net.pm (for other scrips, the differences seems irrelevant).
I need the driver to pass WHQL. Are you saying me that I am allowed to changed the part-of-DTM-package scripts in order to pass it? Is that an official response of ORS? Is it documented any where?
Isn’t WHQL requirement to pass the tests with the scripts as they are?
As I could understand, changing or replacing the scripts is not an option.
Thanks,
S.
I think the suggestion was to diff the perl scripts to figure out what
changed and how to then change your inf file so that checkinf would shut up.
Modifying the checkinf perl scripts would be a real bad idea.
By the way if the 6001 chkinf fails a microsoft sample driver inf file I
would consider that a bug that the WDK team ought to fix.
On Sun, Jul 27, 2008 at 3:29 PM, wrote:
> I compared the scripts from WDK 6000, where it pass, and WDK 6001, where it
> fails. There are some differences in net.pm (for other scrips, the
> differences seems irrelevant).
>
> I need the driver to pass WHQL. Are you saying me that I am allowed to
> changed the part-of-DTM-package scripts in order to pass it? Is that an
> official response of ORS? Is it documented any where?
> Isn’t WHQL requirement to pass the tests with the scripts as they are?
> As I could understand, changing or replacing the scripts is not an option.
>
> Thanks,
> S.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Mark Roddy
> By the way if the 6001 chkinf fails a microsoft sample driver inf file I would consider
that a bug that the WDK team ought to fix.
That’s what I’m saying - the same Microsoft sample that passed with 6000 chkinf fails with 6001 chkinf.
My question is: since the chkinf that is supplied with DTM tools is just the same as 6001, how do people pass WHQL for NDIS drivers?
Thanks,
S.
xxxxx@gmail.com wrote:
As I could understand, changing or replacing the scripts is not an option.
Short answer:
http://www-03.ibm.com/ibm/history/exhibits/attic2/attic2_207.html
SCNR. 
DUDE! Put in some effort. Stop typing messages to NTDEV and examine the chkinf perl script to see what you need to put in your INF file to make it happy.
Yes. But the process of, oh, just about everything for an actual “in-box, shipped on the DVD” driver is different.
Peter
OSR
Hello,
Here is what I could see from reading the perl scripts:
-
The net.pm script has been fixed from WDK 6000 to retrieve the list of models to check. In WDK 6000 it didn’t retrieve the list correctly (LearnModules() routine returned ‘Msft,NTx86’ instead of ‘Msft.NTx86’), and CheckBusType() routine was never called.
-
The ndisedge.inf sample has a HwId which cannot be categorized by CheckBusType() route, and fails. Since CheckBusType() was never called from chkinf for WDK 6000, the sample has passed there.
-
The HwId is assumed by net.pm scipt to be upper-case (!). That’s the change I needed to do in my INF file.
Regards,
S.
And there, my friends, is an argument for making source code available. The INF was right… the expected CASE was wrong.
Of course, next release they’ll change the script to look for something else. Sic transit gloria mundi…
Peter
OSR
xxxxx@osr.com wrote:
And there, my friends, is an argument for making source code
available. The INF was right… the expected CASE was wrong.
Of course, next release they’ll change the script to look for
something else. Sic transit gloria mundi…
Or: Legal will realize someone looked at the script. Then they will have
the system modified to use encrypted binary files instead of plain text.
After this they will submit the binary format of the script as a
6000-page ISO standards proposal. 