Is there any authoritative documentation out there about the network
device installer? I’ve read the DDK, lots of INFs, msdn, a couple
list members’ websites, usenet, etc., and haven’t found a reference yet
that is authoritative on the art of writing INFs. In particular, I’m
revisiting the infs for an IM driver I worked on last year, and I still
have lots of unanswered questions. I’m just not comfortable with “adapt
the sample driver infs” as a way to write production code… when it
breaks, I’m at a loss.
Thanks.
-sd
> have lots of unanswered questions. I’m just not comfortable with "adapt
the sample driver infs" as a way to write production code…
Why?
Usually, all INFs for the same device class have the same structure and differ in several string values only.
Max
On Mon, May 20, 2002 at 03:27:59PM +0400, Maxim S. Shatskih wrote:
> have lots of unanswered questions. I’m just not comfortable with “adapt
> the sample driver infs” as a way to write production code…
Why?
Usually, all INFs for the same device class have the same structure and differ in several string values only.
I’m having trouble with three different installations of our IM driver.
I’m getting a really wierd crash deep inside netcfgx.dll on add, and a
bluescreen (bugcheck ce) on removal. Only happening on a few boxes.
My point isn’t that I’m having crashes, my point is that I’m pretty
powerless to fix them since I don’t completely understand the system.
Copy/paste does work, but it doesn’t lead to understanding.
-sd
> I’m getting a really wierd crash deep inside netcfgx.dll on add, and a
bluescreen (bugcheck ce) on removal. Only happening on a few boxes.
If some problem is occuring deep inside your netcfgx.dll … probably you
need to a closer look the notifier object that you have implemented … may
be somewhere some operation is taking place on dangling pointers … may be
something else … but most probably something wrong is taking place through
your notifier object …
My point isn’t that I’m having crashes, my point is that I’m pretty
powerless to fix them since I don’t completely understand the system.
Copy/paste does work, but it doesn’t lead to understanding.
-sd
You are currently subscribed to ntdev as: xxxxx@quark.co.in
To unsubscribe send a blank email to %%email.unsub%%
On Tue, May 21, 2002 at 09:36:13AM +0530, Arup Banerjee wrote:
> I’m getting a really wierd crash deep inside netcfgx.dll on add, and a
> bluescreen (bugcheck ce) on removal. Only happening on a few boxes.
If some problem is occuring deep inside your netcfgx.dll … probably you
need to a closer look the notifier object that you have implemented … may
That’s just it - I don’t have a notify object at all. My driver is
based on the DDK’s passthru sample, and it doesn’t need a notify object.
I opened up a case with microsoft for this. It looks like it’s crashing
because ndis is calling back into the driver after it unloads. Not sure
why just yet… still fishing around in windbg.
As for the user mode dump, the stack i’m getting now is basically:
MSVCRT!wcscpy
netcfgx!UpdateLanaConfigUsingAnswerfile
snetcfg!HrInstallNetComponent
…but i’ve seen a few variations, like crashing in
UpdateFilterBindingsIfNecessary (approx.). At the top of the dump is
always a call to wcscpy() with a null argument (source i think).
> That’s just it - I don’t have a notify object at all. My driver is
based on the DDK’s passthru sample, and it doesn’t need a
notify object.
I’m copy pasting few lines from the Passthru inf …netsf.inf
HKR, Ndi, ClsID, , {df2e4f67-e93a-11d1-bb14-0000f8779051}
HKR, Ndi, ComponentDll, , sfilter.dll
what you see " sfilter.dll " is the Notifier Object dll and
{df2e4f67-e93a-11d1-bb14-0000f8779051}
is the object’s ClsID
I opened up a case with microsoft for this. It looks like
it’s crashing
because ndis is calling back into the driver after it
unloads. Not sure
why just yet… still fishing around in windbg.
As for the user mode dump, the stack i’m getting now is basically:
MSVCRT!wcscpy
netcfgx!UpdateLanaConfigUsingAnswerfile
snetcfg!HrInstallNetComponent
The above calls are Notifier Object’s call(specific to the Pasthru sample
:))) which are non-existent in your case.
…but i’ve seen a few variations, like crashing in
UpdateFilterBindingsIfNecessary (approx.). At the top of the dump is
always a call to wcscpy() with a null argument (source i think).
You are currently subscribed to ntdev as: xxxxx@quark.co.in
To unsubscribe send a blank email to %%email.unsub%%
On Tue, May 21, 2002 at 10:47:22AM +0530, Arup Banerjee wrote:
> That’s just it - I don’t have a notify object at all. My driver is
> based on the DDK’s passthru sample, and it doesn’t need a
> notify object.
I’m copy pasting few lines from the Passthru inf …netsf.inf
HKR, Ndi, ClsID, , {df2e4f67-e93a-11d1-bb14-0000f8779051}
HKR, Ndi, ComponentDll, , sfilter.dll
what you see " sfilter.dll " is the Notifier Object dll and
{df2e4f67-e93a-11d1-bb14-0000f8779051}
is the object’s ClsID
Sorry, I was unclear. I removed notify object support from the INFs
because I don’t need a notify object. As you can see at the top of that
same file, there are instructions for removing it.
How are u taking care of upper edge bindings … ??? what all it has to
bind to ? …check if any entries are created under
HKLM\system\ccontrlset\class\xx72-yyyy\urid\Linkage …
-----Original Message-----
From: Steve Dispensa [mailto:xxxxx@positivenetworks.net]
Sent: Tuesday, May 21, 2002 11:19 AM
To: NT Developers Interest List
Subject: [ntdev] Re: NDIS, bindings, Infs
On Tue, May 21, 2002 at 10:47:22AM +0530, Arup Banerjee wrote:
>
> > That’s just it - I don’t have a notify object at all. My
driver is
> > based on the DDK’s passthru sample, and it doesn’t need a
> > notify object.
>
>
> I’m copy pasting few lines from the Passthru inf …netsf.inf
>
> HKR, Ndi, ClsID, , {df2e4f67-e93a-11d1-bb14-0000f8779051}
> HKR, Ndi, ComponentDll, , sfilter.dll
>
> what you see " sfilter.dll " is the Notifier Object dll and
> {df2e4f67-e93a-11d1-bb14-0000f8779051}
> is the object’s ClsID
Sorry, I was unclear. I removed notify object support from the INFs
because I don’t need a notify object. As you can see at the
top of that
same file, there are instructions for removing it.
You are currently subscribed to ntdev as: xxxxx@quark.co.in
To unsubscribe send a blank email to %%email.unsub%%
Steve,
I share your frustration as I have been experiencing similar issues. You
may already be aware, but I’ll mention a couple things anyway:
-
netcfg writes to the setupapi logfile: %systemroot%\setupapi.log. Don’t
get your hopes up, the amount of information is limited.
-
Regarding the blue screen during uninstall, I don’t have the links
handy, but a google search revealed some problems others were having
trying to uninstall their NDIS IM drivers. First, (since sfilter.dll was
mentioned, I am assuming win2k) NDIS does not call the unload handler.
Second, NDIS removes a driver after unbinding from the last adapter the
driver was bound to. I actually experienced this problem first hand. I now
perform any cleanup previously implemented in my unload handler from my
ProtocolUnbindAdapter routine.
You can tweek how verbose the SetUpApi log is by changing the key at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\LogLe
vel. A loglevel of 0x2000ffff will give you quite a bit of logging.
The 0x2000 causes it not to flush the disk on every write. This will
speed up logging. Turn off if you are hitting a blue screen. The next
0xff turns on extensive logging regarding your driver and driver
selection. The last 0xff logs all install events. Another, less noisy
selection would be 0x20006060 or 0x00006060. The amount and quality of
logging was greatly increased in Windows XP.
This may not directly relate to Steve’s original post. But I did think
it might be useful to the group per your first comment.
Bryan S. Burgin
xxxxx@microsoft.com
This posting is provided “AS IS” with no warranties, and confers no
rights
-----Original Message-----
From: Dave McCowan [mailto:xxxxx@okena.com]
Sent: Tuesday, May 21, 2002 4:53 AM
To: NT Developers Interest List
Subject: [ntdev] Re: NDIS, bindings, Infs
Steve,
I share your frustration as I have been experiencing similar issues. You
may already be aware, but I’ll mention a couple things anyway:
-
netcfg writes to the setupapi logfile: %systemroot%\setupapi.log.
Don’t
get your hopes up, the amount of information is limited.
-
Regarding the blue screen during uninstall, I don’t have the links
handy, but a google search revealed some problems others were having
trying to uninstall their NDIS IM drivers. First, (since sfilter.dll was
mentioned, I am assuming win2k) NDIS does not call the unload handler.
Second, NDIS removes a driver after unbinding from the last adapter the
driver was bound to. I actually experienced this problem first hand. I
now
perform any cleanup previously implemented in my unload handler from my
ProtocolUnbindAdapter routine.
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to %%email.unsub%%
On Tue, May 21, 2002 at 07:53:18AM -0400, Dave McCowan wrote:
- Regarding the blue screen during uninstall, I don’t have the links
handy, but a google search revealed some problems others were having
trying to uninstall their NDIS IM drivers. First, (since sfilter.dll was
mentioned, I am assuming win2k) NDIS does not call the unload handler.
Second, NDIS removes a driver after unbinding from the last adapter the
driver was bound to. I actually experienced this problem first hand. I now
perform any cleanup previously implemented in my unload handler from my
ProtocolUnbindAdapter routine.
With a little help from my friends at MS (in the form of some
undocumented debug tracing in the network class installer), I was able
to find the source of both the user-mode and kernel-mode crashes.
Somehow the ENUM\Root<my miniport> entry was deleted, but that was not
reflected in the HKLM\CCS\Control\Network\Config value. I deleted the
value and re-ran the the installation and it worked fine.
Has anyone ever managed to decode that value?
Anyhow, I’m still not completely clear on how the network class
installer makes its decisions, but as was pointed out, copying infs
seems to work.
As for the user-mode dumps, I am told that the state it got into (enum
key not matching network config) is uncommon, so no fix there. They’re
filing a bug on the bluescreen. Also, I’m told that the passthru driver
from the XP ddk has a newly-discovered bug in it wrt coming back from
suspend with new hardware inserted, and a patch should be posted to the
newsgroup shortly.
I’d still appreciate pointers to other documentation about netcfgx, but
otherwise, ttfn…
-sd