New HCK and RunDLL32

NTDEV
1

I’ve come across a catch-22; I wonder if anyone else has come across it.

Background: I do several AVStream drivers that include ksproxy plugins.
Those plugins are COM components. Because of that, on a 64-bit system,
I have to ship both 32-bit and 64-bit proxy plugin DLLs. I register
them using RegisterDlls directives in the INF file.

However, there’s a problem. Through empirical research, I’ve learned
that RegisterDlls does not work for 32-bit DLLs on a 64-bit system.
That’s not necessarily surprising. I can copy them into place (using
DirID 16425), but if I have this in my INF:
RegisterDlls = proxy.register
[proxy.register]
11,MyProxyPlugin,ax,1
16425,MyProxyPlugin.ax,1

the 64-bit version gets registered, but the 32-bit version does not.
Because of that, I have to add a registry entry to the RunOnce key to
call “rundll32.exe %16425%\MyProxyPlugin.ax,DllRegisterServer”.

That’s fine, it all works, everyone is happy, and it’s gone through WHQL
many times with the older HCK several times.

However, in the latest HCK, this fails CHKINF testing. It says “RunOnce
usage for device driver installation is restricted to installation of
software-only devices enumerated by SWENUM.” That’s a problem. For a
while yet, our lab can use the older HCK, but I understand that retires
on November 30. After that, I don’t know how I’m supposed to get my
32-bit proxy registered. I shouldn’t have to embed a huge AddReg
section in the INF by hand – that’s just busy work, duplicating
error-prone GUID manipulation code that I’m already doing inside my proxy.

Is this familiar?

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

2

Have your 64bit DLL do the job for 32 bit.

3

I received a private reply to my 32-bit COM RunDLL32 question from Jason
at Microsoft, but I got his permission to forward his responses here.

To summarize, the RegisterDlls directive is going away. The only
recommended path is to embed a bazillion AddReg directives in the INF.
Yecch. Besides being a duplication of effort, that is so much more
error-prone. The justification is that it allows the system to know
exactly what effect your INF will have without requiring any outside
resources.

He also asserts that RegisterDlls DOES know how to handle 32-bit DLLs.
That’s contrary to the evidence I have, but in the end the point is moot.

It’s worth going through the “Device.DevFund.INF” requirements in the
link he sent me. INF files are being severely restricted. You won’t be
able to copy files to anywhere except %11% (system32) and %12%
(system32\drivers). That would mean you couldn’t copy 32-bit DLLs to
%16425% (syswow64) at all, something that seems wrong.

Jason Knichel wrote:

Adding COM registrations by an AddReg section in the INF is what is
desired long-term. The use of the RegisterDlls can be problematic.
For example, it is a non-deterministic operation from the OS point of
view. The OS does not know what the code that is referenced will do,
whereas with the AddReg section in the INF, the OS can know exactly
what will be done. Since the OS doesn’t know what the RegisterDlls is
going to do, the driver package cannot be fully processed offline.
This directive is on a deprecation path, as indicated in HCK
requirement Device.DevFund.INF.DeviceConfigOnly at
http://msdn.microsoft.com/en-US/library/windows/hardware/jj134349

That being said, what is your empirical research showing that
RegisterDlls does not work for 32 bit DLLs on a 64 bit system? I have
seen that work with some drivers in the past.

-Jason

Followup:

If a driver is added to the OS image offline, being able to fully
process the driver offline allows work to be done at that time,
instead of at device installation time on the running system. In
general (whether the driver is added offline or not), moving your
driver package to the declarative model we are guiding people to gives
the OS more knowledge about what settings the driver package
modifies. This knowledge can potentially allow the OS to make use of
device installation enhancements in Windows 8 and later operating
systems that will result in faster and more reliable device
installation experiences.

In what way does the 32-bit registration fail? The component that
handles the processing of RegisterDlls does have logic to detect when
the DLL is 32 bit and should correctly launch it. Are the correct
registry keys getting updated by the 32-bit DLL referenced by the
RegisterDlls?

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

4

> If a driver is added to the OS image offline

Either I’m reading much more into this than Mr. Knichel intended or this is exceedingly interesting.

Peter
OSR

5

On 10/4/2013 6:43 PM, Tim Roberts wrote:

I received a private reply to my 32-bit COM RunDLL32 question from Jason
at Microsoft, but I got his permission to forward his responses here.

To summarize, the RegisterDlls directive is going away. The only
recommended path is to embed a bazillion AddReg directives in the INF.

A good post on why it’s wrong and should go away is at
http://www.symantec.com/connect/forums/fresh-os-fails-register-dll-error-1904

"Insofar as installations (and uninstallations) are concerned,
self-registration is pure evil and should *never* be used***. It
shouldn’t be used by Windows Installer, it shouldn’t be used by
WiseScript, it shouldn’t be used by InstallScript, it shouldn’t be used
by Inno Setup. Not on a plane. Not on a train. Not on cocaine. I would
not SelfReg here or there. I would not SelfReg anywhere**

** Note: * I didn’t say that self-registration should never be used
under other non-installation circumstances. For example: If you’ve
identified a group of machines that appear to have already had their
registry damaged by a less-than-stellar uninstall routine (registry
rot), it could be entirely appropriate to self-register. Although…due
to self-registration’s legendary fragility, it would still be mentally
deficient to do so; why would you not instead extract the registry and
deliver it in a 100% guaranteed working fashion? Seriously, I’ll give a
no-prize to anybody who can bring up even just one situation where
self-registration is the right answer. And, no, “I’m too lazy to
extract the registry” is not a valid answer :slight_smile:

Microsoft has a fair bit to say about why you shouldn’t ever want to use
self-registration. Just open MSI.chm and read the entry for the SelfReg
Table (or click this
http: handy-dandy
link)"

–
Bruce Cran</http:>

6

On 10/4/2013 6:43 PM, Tim Roberts wrote:

It’s worth going through the “Device.DevFund.INF” requirements in the
link he sent me. INF files are being severely restricted. You won’t be
able to copy files to anywhere except %11% (system32) and %12%
(system32\drivers). That would mean you couldn’t copy 32-bit DLLs to
%16425% (syswow64) at all, something that seems wrong.

Device.DevFund.INF.DDInstall.CoInstallers also says that co-installers
can’t be run from an INF file any more - is that right?

–
Bruce Cran