How does windows find the correct device driver?

"Haggis" wrote in message
...



"Bazzer Smith" wrote in message
...

"mdp" wrote in message
...
Bazzer Smith wrote:
I have been having a load of trouble trying to install an ethernet
card 10/100 NIC thingy, I have an installation disk but that didn't
seem to work properly so I have been trying to do it 'manually' too,
by downloading various drivers which look 'likely suspects'.

Anyway at first when I booted up with the new card in it would detect
it and go to driver installation dialogue and I would point it to
where the driver I wanted to try was. Invariably it would find it,
try to install it, and then fail.
However now when I try the procedure again after making some
adjustment, or just wanting to try it again it doesn't seem to find
the drives in places it had previously found them. It is almost as if
it had remembered "oh that one didn't work before so I will ignore
it!!"
Either that or it deleted then or something.

So.. what I want to know is how windows associates a driver
with a device. I mean if there were a load of drivers in a folder,
which one would it pick, and how does it make it's decision?

The device is question is an ethernet card which has rtl8139(d)
on the chip, however before it detected it as an rtl8129 when
I used the installation disk setup with it, so I aint too sure and I
am a bit confused.

Another point is that initially when I used the installation disk
and some time with out it, when it did find a driver it was happy
with it would prompt me to put my original windows disk in so it
could get some more 'stuff' (drivers etc...). However it never
found what it wanted untill I unzipped a load of the .cab files
(mainly net??.cab), then it did find them (it wanted about 40+
files), it would then say some files were older versions of the files
and ask if I wanted to replace the existing version, I would say no,
this would continue untill it got to telnet.exe (IIRC), I would say
no don't replace it, then my system would hang/crash.
After that I clicked yes to replace telnet.exe to see it that helped
but it didn't.
Now however I said earlier, it will never find the first driver so
I can't get to that stage anymore.
I am at a loss to figure out what is going on and I would reallly
appreciate any advice, especally from folks who understand
what is going on and what to do,as the whold thing seems to be pretty
inconsistant and I can't seem to go back too 'square one'.

My computer still works find though (am using it now), but I
just can't for the life of me get windows to install a drive for the
card.


TIA.

Shouldn't be that hard. Realtek has the drivers he

http://www.realtek.com.tw/downloads/...&Software=True

As far as where how Windows finds the driver, find the entry in the ENUM
key corresponding to your device, then look up (e.g. Google) to see what
info Windows is obtaining from the device.


I think you may have misunderstood me a little, how does windows know
what information to put in the ENUM key, bacially how does it know what
type of device I have plugged into a slot.

Or to put it another way how does windows know what to put int
the EMUN keys in the registry, when you plpug a new device in?



http://www.microsoft.com/technet/arc....mspx?mfr=true

More here from Google:

http://www.google.com/search?hl=en&l...um+98+registry






if you boot into "safe mode" then remove all references of the NIC in
device manager , it should start the process over when you reboot (and let
you select the location you want)

I will try that but I may need some futher help/advice.


you probably have a few ghost entries in there messing with you :

ps. when it asked for the win98 cd to load additional files ...point it
at c:\windows or c:\windows\system (alternate , if its not found in one ,
try the other)
it should find what it needs already there...

Thanks I tried something similar to that, I unzipped some of
the cab files into a folder, I probably should have done it as you
said but anyway it dis seem to find what it wanted but it still
resulted in failure!!

hth

"Ingeborg" wrote in message
...
"Bazzer Smith" wrote in
:


I think you may have misunderstood me a little, how does windows know
what information to put in the ENUM key, bacially how does it know
what type of device I have plugged into a slot.

Or to put it another way how does windows know what to put int
the EMUN keys in the registry, when you plpug a new device in?


All plug&play devices have a standard way to give a product- and a
vendorID
(both 16 bits) to the OS. The ENUM key is a munged version of these.

I want to be able to see this key cos on the card it says 8139 but i think
it said 8129 in the device manager. ANyway I tried drivers for both
with little success.
It can't find a driver anywhere for love nor money now :O(

"Ingeborg" wrote in message
...
"Bazzer Smith" wrote in
:


I think you may have misunderstood me a little, how does windows know
what information to put in the ENUM key, bacially how does it know
what type of device I have plugged into a slot.

Or to put it another way how does windows know what to put int
the EMUN keys in the registry, when you plpug a new device in?


All plug&play devices have a standard way to give a product- and a
vendorID
(both 16 bits) to the OS. The ENUM key is a munged version of these.

I want to be able to see this key cos on the card it says 8139 but i think
it said 8129 in the device manager. ANyway I tried drivers for both
with little success.
It can't find a driver anywhere for love nor money now :O(

"Bazzer Smith" wrote in
:


"Ingeborg" wrote in message
...
"Bazzer Smith" wrote in
:


I think you may have misunderstood me a little, how does windows
know what information to put in the ENUM key, bacially how does it
know what type of device I have plugged into a slot.

Or to put it another way how does windows know what to put int
the EMUN keys in the registry, when you plpug a new device in?


All plug&play devices have a standard way to give a product- and a
vendorID
(both 16 bits) to the OS. The ENUM key is a munged version of these.

I want to be able to see this key cos on the card it says 8139 but i
think it said 8129 in the device manager. ANyway I tried drivers for
both with little success.
It can't find a driver anywhere for love nor money now :O(



Try Everest, you can download it at www.oldversion.com, it will tell
you which NIC you have. It can also give the VID and PID, which is called
Device ID here.

Maybe I should tell you some more about plug&play; The device gives its
VID :PID to windows, and windows asks for the driver. You'll have to
point to a directory where a .inf file resides. When there's no .inf file
in the directory the OK button will be disabled
This .inf file contains scripts for one or more VID:PID's. When windows
can find the right VID:PID it will execute the script, which installs the
driver. When the .inf file doesn't contain the right VID:PID combination
it will tell you it can't find the right driver in that place.

"Bazzer Smith" wrote in
:


"Ingeborg" wrote in message
...
"Bazzer Smith" wrote in
:


I think you may have misunderstood me a little, how does windows
know what information to put in the ENUM key, bacially how does it
know what type of device I have plugged into a slot.

Or to put it another way how does windows know what to put int
the EMUN keys in the registry, when you plpug a new device in?


All plug&play devices have a standard way to give a product- and a
vendorID
(both 16 bits) to the OS. The ENUM key is a munged version of these.

I want to be able to see this key cos on the card it says 8139 but i
think it said 8129 in the device manager. ANyway I tried drivers for
both with little success.
It can't find a driver anywhere for love nor money now :O(



Try Everest, you can download it at www.oldversion.com, it will tell
you which NIC you have. It can also give the VID and PID, which is called
Device ID here.

Maybe I should tell you some more about plug&play; The device gives its
VID :PID to windows, and windows asks for the driver. You'll have to
point to a directory where a .inf file resides. When there's no .inf file
in the directory the OK button will be disabled
This .inf file contains scripts for one or more VID:PID's. When windows
can find the right VID:PID it will execute the script, which installs the
driver. When the .inf file doesn't contain the right VID:PID combination
it will tell you it can't find the right driver in that place.

"Ingeborg" wrote in message
...
"Bazzer Smith" wrote in
:


"Ingeborg" wrote in message
...
"Bazzer Smith" wrote in
:


I think you may have misunderstood me a little, how does windows
know what information to put in the ENUM key, bacially how does it
know what type of device I have plugged into a slot.

Or to put it another way how does windows know what to put int
the EMUN keys in the registry, when you plpug a new device in?


All plug&play devices have a standard way to give a product- and a
vendorID
(both 16 bits) to the OS. The ENUM key is a munged version of these.

I want to be able to see this key cos on the card it says 8139 but i
think it said 8129 in the device manager. ANyway I tried drivers for
both with little success.
It can't find a driver anywhere for love nor money now :O(



Try Everest, you can download it at www.oldversion.com, it will tell
you which NIC you have. It can also give the VID and PID, which is called
Device ID here.

Thanks a lot, I am getting somewhere at last.


Maybe I should tell you some more about plug&play; The device gives its
VID :PID to windows, and windows asks for the driver. You'll have to
point to a directory where a .inf file resides.

When there's no .inf file
in the directory the OK button will be disabled

I noticed that!

This .inf file contains scripts for one or more VID:PID's. When windows
can find the right VID:PID it will execute the script, which installs the
driver. When the .inf file doesn't contain the right VID:PID combination
it will tell you it can't find the right driver in that place.

What appeared to happen with me was that originally when I pointed
to a directory if would try the driver and inevitable fail to install it
correctly. Now however it doesn't seem to find the drivers there
IIRC (but it does show a OK button I believe) but when I click it
it says (IIRC) no driver found. It is as if it remembered the driver
there failed and it is unwilling to even contemplate trying to install it
again!!
(Is that how it might operate?).

But thanks I will get that prog and see if that throws any light on the
(rather confused) situation :O)

This originate from a previous thread in alt.comp.hardware 5/5/2006
entitled :-
"Problems installing network card (ethernet 10/100 NIC PCI)"

But thanks once again, I will have another go at trying to install it
later.

When tended to happen when it did the find driver was it then prompted
me for my wiindows disk so if could get another pile of 'stuff'
(drivers etc..?), which initially failed untill I unpacked some .cab files.
However when it did find then it would usually lock up after it found
telnet.exe, and even when I (somehow) got past that it would still
fail to install the driver.

Unfortunately the picture is pretty confused as I tried many different
things
and had various different types of failure, probably due to different
drivers etc being installled and the basic setup being changed.

Also from the 'manual' supplier it seems they could not install the
NIC either, it shows a screenshot where it can't find the driver
on the windows CD and advises you to click OK, which just
results in the same message.

"Ingeborg" wrote in message
...
"Bazzer Smith" wrote in
:


"Ingeborg" wrote in message
...
"Bazzer Smith" wrote in
:


I think you may have misunderstood me a little, how does windows
know what information to put in the ENUM key, bacially how does it
know what type of device I have plugged into a slot.

Or to put it another way how does windows know what to put int
the EMUN keys in the registry, when you plpug a new device in?


All plug&play devices have a standard way to give a product- and a
vendorID
(both 16 bits) to the OS. The ENUM key is a munged version of these.

I want to be able to see this key cos on the card it says 8139 but i
think it said 8129 in the device manager. ANyway I tried drivers for
both with little success.
It can't find a driver anywhere for love nor money now :O(



Try Everest, you can download it at www.oldversion.com, it will tell
you which NIC you have. It can also give the VID and PID, which is called
Device ID here.

Thanks a lot, I am getting somewhere at last.


Maybe I should tell you some more about plug&play; The device gives its
VID :PID to windows, and windows asks for the driver. You'll have to
point to a directory where a .inf file resides.

When there's no .inf file
in the directory the OK button will be disabled

I noticed that!

This .inf file contains scripts for one or more VID:PID's. When windows
can find the right VID:PID it will execute the script, which installs the
driver. When the .inf file doesn't contain the right VID:PID combination
it will tell you it can't find the right driver in that place.

What appeared to happen with me was that originally when I pointed
to a directory if would try the driver and inevitable fail to install it
correctly. Now however it doesn't seem to find the drivers there
IIRC (but it does show a OK button I believe) but when I click it
it says (IIRC) no driver found. It is as if it remembered the driver
there failed and it is unwilling to even contemplate trying to install it
again!!
(Is that how it might operate?).

But thanks I will get that prog and see if that throws any light on the
(rather confused) situation :O)

This originate from a previous thread in alt.comp.hardware 5/5/2006
entitled :-
"Problems installing network card (ethernet 10/100 NIC PCI)"

But thanks once again, I will have another go at trying to install it
later.

When tended to happen when it did the find driver was it then prompted
me for my wiindows disk so if could get another pile of 'stuff'
(drivers etc..?), which initially failed untill I unpacked some .cab files.
However when it did find then it would usually lock up after it found
telnet.exe, and even when I (somehow) got past that it would still
fail to install the driver.

Unfortunately the picture is pretty confused as I tried many different
things
and had various different types of failure, probably due to different
drivers etc being installled and the basic setup being changed.

Also from the 'manual' supplier it seems they could not install the
NIC either, it shows a screenshot where it can't find the driver
on the windows CD and advises you to click OK, which just
results in the same message.

One aspect that confuses many about installations of such custom
drivers is that Windows keeps a copy of any applied .inf files in
Windows\INF\OTHER folder. That's where Windows looks first and if a
suitable inf file is found there, it is automatically selected. If you
want a choice, delete the offending file(s) from that folder and
Windows will once again start asking for locations for installation
files.

The other side of this issue is that any named files required inside
such a custom inf file should be supplied in the same folder as the inf
file. Perhaps THEIR telnet.exe file is different from Win98's copy of
the same named file and it's not working for that issue? Usually such
named files from these inf files are placed in the Systems folder and
you may have a form of dll hell where similar named dll support files
are not the right versions and/or linked to other missing/wrong
versioned dll files. One might track that a few layers deep with
Dependency Walker but it could get very confusing very fast.
Especially after so many attempts have been made.
http://www.dependencywalker.com/

Try unzipping the cab files to seperate folders so that if a proper
driver is found it is not matched to the wrong support file(s).

One aspect that confuses many about installations of such custom
drivers is that Windows keeps a copy of any applied .inf files in
Windows\INF\OTHER folder. That's where Windows looks first and if a
suitable inf file is found there, it is automatically selected. If you
want a choice, delete the offending file(s) from that folder and
Windows will once again start asking for locations for installation
files.

The other side of this issue is that any named files required inside
such a custom inf file should be supplied in the same folder as the inf
file. Perhaps THEIR telnet.exe file is different from Win98's copy of
the same named file and it's not working for that issue? Usually such
named files from these inf files are placed in the Systems folder and
you may have a form of dll hell where similar named dll support files
are not the right versions and/or linked to other missing/wrong
versioned dll files. One might track that a few layers deep with
Dependency Walker but it could get very confusing very fast.
Especially after so many attempts have been made.
http://www.dependencywalker.com/

Try unzipping the cab files to seperate folders so that if a proper
driver is found it is not matched to the wrong support file(s).

"Lee" wrote in message
ups.com...
One aspect that confuses many about installations of such custom
drivers is that Windows keeps a copy of any applied .inf files in
Windows\INF\OTHER folder. That's where Windows looks first and if a
suitable inf file is found there, it is automatically selected. If you
want a choice, delete the offending file(s) from that folder and
Windows will once again start asking for locations for installation
files.

Thanks for that that sounds like that will be very usefull advice (maybe).



The other side of this issue is that any named files required inside
such a custom inf file should be supplied in the same folder as the inf
file. Perhaps THEIR telnet.exe file is different from Win98's copy of
the same named file and it's not working for that issue?

Actually what tend to happen, I believe is I told it to keep the
existing telnet and then it locked up (telnet maybe a red herring).
So next time I though I might as well overwrite it, however it
still failed eventually.

Usually such
named files from these inf files are placed in the Systems folder and
you may have a form of dll hell where similar named dll support files
are not the right versions and/or linked to other missing/wrong
versioned dll files. One might track that a few layers deep with
Dependency Walker but it could get very confusing very fast.
Especially after so many attempts have been made.
http://www.dependencywalker.com/

I will try that when i am feeling brave!!


Try unzipping the cab files to seperate folders so that if a proper
driver is found it is not matched to the wrong support file(s).

Not too sure what you mean my that (maybe) however I did notice
whenI unzipped all the cab files in options/cabs to a folder that
there were different versions of the same .dll in different folders,
I tried to keep the latest. I can't undesrtand why this should be if that
is a copy of what is on the installation disk, you would think that that
would
have its .dll files 'sorted'?