Installation problem on the Win7

NTDEV
1

Hi, dears!

I have a problem with installation of my driver. I have directories with all needed files:
the names are
for windows 7:
c:\mydriver\w7\x86 & c:\mydriver\w7\amd64
for server2008
c:\mydriver\2k8\x86 & c:\mydriver\2k8\amd64

When I install the driver ( win7 : x86 ) in the “Update driver software” dialog box and choose
path as c:\mydriver installation failed because try to install ( as I see from setupapi.dev.log )
from:
inf: Opened INF: ‘c:\mydriver\2k8\amd64’ ([strings])

When I changed the name of subdirectory from 2k8 to ws2k8, installer went to w7 subdirectory, but continue to use amd64 and fail. Changes of the amd64 name to something greater that x86, like x87 didn’t help.
So is it possible to give just part of the inf path to installer at all and if yes, what rules it use for names.

TIA
Arkady

2

Some additions!
Even after re-build the driver for x86 and set all new files into i386 directory, the installer continue to go to i486 ( originally amd64 ) dir and tried to install from there, it failed with message:
“Windows found driver software for your device but encountered an error while attempting to install it”.
That’s correct, because windows choose to take 64 bit driver for 32 bit OS. The driver don’t appear in the DevManager tree, but I see that 64 bit driver itself set in windows\system32\drivers dir, and DevManager allow me to uninstall it, when I choose it’s parent device :“PCI Standard RAM controller” and choose uninstall from float menu.
Seems, that decision to allow installation with partial path, opposite to XP, where OK button activated only after choosing last subdirectory with driver files, is problematic. But what push the installer to 64bit directory ?
TIA
Arkady

3

xxxxx@hotmail.com wrote:

Some additions!
Even after re-build the driver for x86 and set all new files into i386 directory, the installer continue to go to i486 ( originally amd64 ) dir and tried to install from there, it failed with message:
“Windows found driver software for your device but encountered an error while attempting to install it”.
That’s correct, because windows choose to take 64 bit driver for 32 bit OS. The driver don’t appear in the DevManager tree, but I see that 64 bit driver itself set in windows\system32\drivers dir, and DevManager allow me to uninstall it, when I choose it’s parent device :“PCI Standard RAM controller” and choose uninstall from float menu.
Seems, that decision to allow installation with partial path, opposite to XP, where OK button activated only after choosing last subdirectory with driver files, is problematic. But what push the installer to 64bit directory ?

It’s your installer, isn’t it? How would we know that? Have you posted
your INF file?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

4

xxxxx@hotmail.com wrote:

I have a problem with installation of my driver. I have directories with all needed files:
the names are
for windows 7:
c:\mydriver\w7\x86 & c:\mydriver\w7\amd64
for server2008
c:\mydriver\2k8\x86 & c:\mydriver\2k8\amd64

Why do you need different drivers for Win 7 and Server 2008?

When I install the driver ( win7 : x86 ) in the “Update driver software” dialog box and choose
path as c:\mydriver installation failed because try to install ( as I see from setupapi.dev.log )
from:
inf: Opened INF: ‘c:\mydriver\2k8\amd64’ ([strings])

When I changed the name of subdirectory from 2k8 to ws2k8, installer went to w7 subdirectory, but continue to use amd64 and fail. Changes of the amd64 name to something greater that x86, like x87 didn’t help.

Do you have the proper “decorations” in each of those INF files? The
system is going to look at all of those INF files one by one, looking
for a match for your hardware. If all four match, then it’s just going
to pick one of them. You have to tell it, using decorations, that “this
INF file only applies to Windows 7 64-bit”.

By the way, it’s quite possible to write a single INF file that handles
all four choices above, even if you need four different driver binaries.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

Hi, Tim!
Thanks, for the answer and here mine.

1)I used windows installer and not my own.
2)PM wanted separation between win7 and WS2008 R2 but really that the same drivers.
3)I take the example to show that windows install in the case of win7 or 2k8 went to second because of the same 2K8 < win7 but in the case of the win7 only ( amd64 and x86/i386 ) that not work in the same way and goes to amd always.
4)There is no problem with each inf file : all passed chkinf and work without probles if I set full path to inf. The problem happen when I choose only part of the path and not full.
In this case setupapi.dev.log show incorrect path to inf and fail.
There is no enumeration of inf files in setupapi.dev.log shown( there is 8 of such really : x86/amd 64 for xp,2k3,win7,2k8 ), but only single opened inf file for amd64.

Arkady

6

xxxxx@hotmail.com wrote:

1)I used windows installer and not my own.

I don’t know what that means. Do you mean you are using Device Manager,
and choosing Update Driver?

2)PM wanted separation between win7 and WS2008 R2 but really that the same drivers.

That’s silly. Those two operating systems are the same. The kernels
are identical. You’re just asking for confusion, as evidenced by the
confusion you are now seeing.

4)There is no problem with each inf file : all passed chkinf and work without probles if I set full path to inf. The problem happen when I choose only part of the path and not full.
In this case setupapi.dev.log show incorrect path to inf and fail.
There is no enumeration of inf files in setupapi.dev.log shown( there is 8 of such really : x86/amd 64 for xp,2k3,win7,2k8 ), but only single opened inf file for amd64.

The fact that the individual INF files do not exhibit any errors does
NOT mean the INF files are set up correctly to pinpoint a single
operating system and processor combination.

Here’s an example. Let’s say you had this:

[Manufacturer]
MyName = Devices, NTamd64
[Devices]
%MyDescription% = ThisDevice, PCI\VEN_1234&DEV_5678
[Devices.NTamd64]
%MyDescription% = ThisDevice, PCI\VEN_1234&DEV_5678

That would be valid for any of the system / processor combinations you
named. You could copy this into all four directories. And that,
basically, is the problem – there’s no way for Device Manager to tell
the difference between them – that it’s not supposed to use this one
for x86 Server 2008.

You would need to use this in the Win 7 32 file:
[Manufacturer]
MyName = Devices, NTx86.6.1.1
[Devices.NTx86.6.1.1]

and this in the 2008R2 32 file:
[Manufacturer]
MyName = Devices, NTx86.6.1.3
[Devices.NTx86.6.1.3]

and this in the Win 7 64 file:
[Manufacturer]
MyName = Devices, NTamd64.6.1.1
[Devices.NTamd64.6.1.1]

And this in the 2008R2 64 file:
[Manufacturer]
MyName = Devices, NTamd64.6.1.3
[Devices.NTamd64.6.1.3]

See? It’s silly. Much easier to have one INF.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

Hi!
Answers:

    • Yes, Update driver from DevManager
  2. Agree, but that’s life. Any case I talk only about win7 2 different directories : 1) for 32 bit and 2) for 64
    3)You talk about content of the INF file itself, but what I see that installer went to amd64 path in 32 bit system and copy 64 bit driver to directory, even decoration in the INF itself stand that it for 64 bit only.
    And that maybe approved your statement.
    More and more I see that windows installer have to be treated with a single INF for all systems in it.
    Activating OK button for any path ( not full , opposite to XP where OK greyed up to last subdirectory with sys, INF in it ) caused that INF file have to be single and include all systems in it.

Best,
Arkady

8

P.S. Maybe the single question in all this story is why installer goes to amd64 directory, even if under win7 I renamed it to i486 to be more than 32bit one ( i386 ) ?

TIA
Arkady

9

On 12-Jul-2011 09:33, xxxxx@hotmail.com wrote:

P.S. Maybe the single question in all this story is why installer goes to amd64 directory, even if under win7 I renamed it to i486 to be more than 32bit one ( i386 ) ?

Names of subdirectories mean nothing to the installer.
It scans all INFs in all subdirectories and finds the 1st suitable.

–pa

10

xxxxx@hotmail.com wrote:

Answers:

    • Yes, Update driver from DevManager
  2. Agree, but that’s life.

No, I disagree. As I have said before, as a professional engineer, it
is your responsibility to point out to management when they request
things that do not make sense because they do not understand the
technicalities. That’s why they pay you the big bucks.

Any case I talk only about win7 2 different directories : 1) for 32 bit and 2) for 64
3)You talk about content of the INF file itself, but what I see that installer went to amd64 path in 32 bit system and copy 64 bit driver to directory, even decoration in the INF itself stand that it for 64 bit only.

Forgive me for being blunt, but you are wrong. If Device Manager chose
your 64-bit INF on a 32-bit system, then the decorations were clearly
not correctly identifying the INF as 64-bit only. If you are unwilling
to post your INF files for us to examine, then I don’t see how we can be
of any help to you.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

11

xxxxx@hotmail.com wrote:

P.S. Maybe the single question in all this story is why installer goes to amd64 directory, even if under win7 I renamed it to i486 to be more than 32bit one ( i386 ) ?

I would hope it is clearly obvious that the directory names don’t mean
anything. You could put the 32-bit INF in a directory called “powerpc”
and the 64-bit INF in a directory called “ladygaga”, and Device Manager
would still find them just fine.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

12

I would hope it is clearly obvious that the directory names don’t mean
anything. You could put the 32-bit INF in a directory called “powerpc”
and the 64-bit INF in a directory called “ladygaga”, and Device Manager
would still find them just fine.

Paparazzi would be a better name :slight_smile:

-p

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

13

Hi, Tim!
PMs stand that their name will help to sell the product better to bring me “big bucks”, but I’ll obviously
propose “ladygaga” as opportunity to receive additionally 0.001% to it.

As to the problem, I really saw with ProcessMonitor that drvinst.exe enumerate all dirs and that was not shown in setupapi.dev.log even with max loglevel (TXTLOG_VERY_VERBOSE).
I found that problem with amd was incremented version number, for unknown to me yet reason:
the inf created thousand miles from me… and after correct set yet, I can’t check it quickly, because have to pass whql. That because the package with MS signature drvinst prefer even with less version number, compare to the package signed with my company signature, maybe because that RAM controller.

Thank you, Pave and Prokash for the participation in this thread.
Best,
Arkady

14

Hi, dears!

Just for those interested interested in this topic, I continued with different kind of the driver ( not RAM controller ) to receive the full picture of installing scenario using partial path to driver files.
Due to http://msdn.microsoft.com/en-us/library/ff553973(v=VS.85).aspx. there is no way to use such installation from Win7, but because the OK button opened from in dialog box in Win7 for any path ( opposite to XP where it’s activated only for full path only ) really do possible to use that.

Drvinst.exe enumerate all directories (first stage) for INF including highest driver version in the [Version] section ( key DriverVer ). When drvinst.exe find such, the directory included the INF used for installation.
If all INF files have the same version, the least alphabetically path chosen in the first stage.

During the second stage drvinst.exe try to install files from that directory and only there it looks upon decorations (x86, amd64 ) and may fail the installation, if INF found, have to be used for amd64, but really its 32 bit OS.

Best, Arkady