RegisterDLLs

NTDEV
1

In an INF file for a 64-bit system, is the RegisterDLLs line supposed to
work for both 32-bit and 64-bit DLLs? It’s beginning to look to me like
32-bit DLL registration does not succeed. The INF file contains:

[vidocmos.NTAMD64]
11,VendorPlugin.ax,1
16425,VendorPlugin.ax,1

And setupapi.dev.log looks like this:

inf: {Install Inf Section [vidocmos.NTAMD64]}
inf: AddReg=vidousb.WIA.AddReg,vidousb.Proxy.AddReg
(vcamgen.inf line 137)
inf: 11,VendorPlugin.ax,1 (vcamgen.inf line 203)
inf: Processing REGISTERDLLS section [vido.Register].
Module: ‘%11%\VendorPlugin.ax’, flags: 0x0001, timeout: 300s, Arguments:
‘(null)’.
inf: Calling ‘DllRegisterServer’ in OLE Control
‘C:\Windows\system32\VendorPlugin.ax’ succeeded.
inf: 16425,VendorPlugin.ax,1 (vcamgen.inf line 204)
inf: Processing REGISTERDLLS section [vido.Register].
Module: ‘%16425%\VendorPlugin.ax’, flags: 0x0001, timeout: 300s,
Arguments: ‘(null)’.
inf: {Install Inf Section [vidocmos.NTAMD64] exit (0x00000000)}

Note that only the 64-bit version gets an acknowledgment. There is no
error from the second call, but no response, either.

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

2

If the program that processes the inf is a 64 bit app how could the
registration work? The LoadLibrary would fail.

Bill Wandel

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]
On Behalf Of Tim Roberts
Sent: Monday, April 26, 2010 8:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RegisterDLLs

In an INF file for a 64-bit system, is the RegisterDLLs line supposed to
work for both 32-bit and 64-bit DLLs? It’s beginning to look to me like
32-bit DLL registration does not succeed. The INF file contains:

[vidocmos.NTAMD64]
11,VendorPlugin.ax,1
16425,VendorPlugin.ax,1

And setupapi.dev.log looks like this:

inf: {Install Inf Section [vidocmos.NTAMD64]}
inf: AddReg=vidousb.WIA.AddReg,vidousb.Proxy.AddReg
(vcamgen.inf line 137)
inf: 11,VendorPlugin.ax,1 (vcamgen.inf line 203)
inf: Processing REGISTERDLLS section [vido.Register].
Module: ‘%11%\VendorPlugin.ax’, flags: 0x0001, timeout: 300s, Arguments:
‘(null)’.
inf: Calling ‘DllRegisterServer’ in OLE Control
‘C:\Windows\system32\VendorPlugin.ax’ succeeded.
inf: 16425,VendorPlugin.ax,1 (vcamgen.inf line 204)
inf: Processing REGISTERDLLS section [vido.Register].
Module: ‘%16425%\VendorPlugin.ax’, flags: 0x0001, timeout: 300s,
Arguments: ‘(null)’.
inf: {Install Inf Section [vidocmos.NTAMD64] exit (0x00000000)}

Note that only the 64-bit version gets an acknowledgment. There is no error
from the second call, but no response, either.

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

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

3

Bill Wandel wrote:

If the program that processes the inf is a 64 bit app how could the
registration work? The LoadLibrary would fail.

It’s Device Manager that processes the INF. One assumes that the folks
at Microsoft are either smart enough to spawn a 32-bit proxy process, or
smart enough to issue an appropriate error. They know from the
directory ID that it’s a 32-bit DLL.

Making this even more frustrating, this does seem to work for me (even
without the line in the log), but the client says it doesn’t work
immediately after a virgin operating system install. That’s my next
adventure.

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

4

Bill Wandel wrote:

If the program that processes the inf is a 64 bit app how could the
registration work? The LoadLibrary would fail.

Tim Roberts wrote:

It’s Device Manager that processes the INF. One assumes that the folks
at Microsoft are either smart enough to spawn a 32-bit proxy process, or
smart enough to issue an appropriate error. They know from the
directory ID that it’s a 32-bit DLL.

Mybe it just runs in a protected/virtualized environment. Can you have
it pop up a dialog box and check if it does?

Better don’t assume anything. One could also assume that a driver
package installer would be platform-agnostic (or part of the system).

But it is not:
http://www.microsoft.com/whdc/driver/install/32-64bit_install.mspx

“32-bit driver installation packages cannot be used to directly install
64 bit drivers, but they can be used to determine which architecture is
being run and then launch the appropriate installer.”

  • So a 32bit “dpinstselect.exe” runs first
  • “dpinstselect” detects if it runs on a 32bit or 64bit system.
  • Then it invokes the correct “dpinst32.exe” or “dpinst64.exe”.
  • These then process the same(!) multi-platform(!) driver package.

Looks very “kludgy” to me. But at least it works.

[Carrying around two copies of dpinst in the multi-platform installer is
a waste of bandwidth. That’s why we will likely split up the driver
package again and provide individual setups for 32bit/64bit.]

=> The same could be true for your 32bit DLL on a 64bit system, possibly
you need two different ones.

5

Hagen Patzke wrote:

[Carrying around two copies of dpinst in the multi-platform installer is
a waste of bandwidth. That’s why we will likely split up the driver
package again and provide individual setups for 32bit/64bit.]

Pooh. It’s 570k and 650k. My NSIS installer script just copies the
proper dpinst into place before calling it.

=> The same could be true for your 32bit DLL on a 64bit system, possibly
you need two different ones.

I’m not sure what you’re trying to say. I have a multi-platform INF
file in an NSIS installer package with both flavors of dpinst included,
but in this case the client is installing from the driver files
directly, without using the installer. And please remember that it
works JUST FINE unless it happens to be a fresh install of the operating
system.

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

6

What os are we talking about here (maybe I just missed it)?

mm

7

xxxxx@evitechnology.com wrote:

What os are we talking about here (maybe I just missed it)?

The client claims to have seen this on both Vista 64 and Win 7 64. I’m
still trying to duplicate it.

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

8

> [dpinst 32bit+64bit versions both necessary = waste of bandwidth]

Pooh. It’s 570k and 650k. My NSIS installer script just copies the
proper dpinst into place before calling it.

Ever downloaded a multi-megabyte installer via GPRS or EDGE?
We can’t rely on an FAE having hi-bandwidth access.

> => The same could be true for your 32bit DLL on a 64bit system, possibly
> you need two different ones.

I’m not sure what you’re trying to say.

I’m trying to say that you probably need a 32bit DLL and a 64bit DLL.
Probably what “One assumes” is wrong, and it’s not handled.