Devcon 32 vs 64

NTDEV
1

While doing some driver testing on 64-bit Windows 7, I noticed that the
32-bit “devcon” binary was unable to restart my driver. Queries all
seemed to work fine, but “restart” failed.

That problem has a trivial solution, of course (use the 64-bit devcon
binary), but it made me wonder why. In my experience, most 32-bit apps
– even sophisticated 32-bit apps – work seamlessly on Win64. What is
it about a driver restart that cannot cross the 32/64 boundary?
Accident or design decision?

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

2

Tim,

Obviously I cannot answer with authority but I recall being told at a DDC or
WinHEC that it was *decision* and not an implementation flaw to ensure that
32-bit WOW64 processes that might not realize they are running on Win64
cannot do stuff like install and manipulate drivers because they might well
try to stuff a 32-bit binary into the system (which I answered with, and
that won’t work anyway so why the prohibition?)

This has been a source of untold agony for device installation and kernel
driver installation as part of applications that are smart enough to know
how to tell what platform they are running on. There does not seem to be a
way (like the ability to disable WOW64 redirections of registry and file
system) to tell the CFGMGR and other parts of SETUPAPI and related (INetCfg)
to just ‘do it’ and stop protecting me from myself. These things *are* just
RPC or COM right?

I for one think it was a ‘accident’ of the design process but then again, I
have long ago built my cadre of work-a-rounds which essentially boil down to
hiding native code that gets invoked out of process when necessary.

Perhaps there is a magic switch and I just don’t know about it. That would
be a nice thing to learn…

Cheers,
Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, March 27, 2009 1:29 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Devcon 32 vs 64

While doing some driver testing on 64-bit Windows 7, I noticed that the
32-bit “devcon” binary was unable to restart my driver. Queries all
seemed to work fine, but “restart” failed.

That problem has a trivial solution, of course (use the 64-bit devcon
binary), but it made me wonder why. In my experience, most 32-bit apps
– even sophisticated 32-bit apps – work seamlessly on Win64. What is
it about a driver restart that cannot cross the 32/64 boundary?
Accident or design decision?

–
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

That information is false, a 32 bit process can install, start and
communicate with a 64 bit driver without problems through the I/O manager.
What I have seen problems with however is a 32 bit process trying to install
a 64 bit driver with an INF file through the SetupAPI as it will (sometimes)
install to the SysWow64\Drivers directory (which according to me could never
makes sense) as a result of file system redirection.

//Daniel

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> Obviously I cannot answer with authority but I recall being told at a DDC
> or
> WinHEC that it was decision and not an implementation flaw to ensure
> that
> 32-bit WOW64 processes that might not realize they are running on Win64
> cannot do stuff like install and manipulate drivers because they might
> well
> try to stuff a 32-bit binary into the system (which I answered with, and
> that won’t work anyway so why the prohibition?)
>

4


What I have seen problems with however is a 32 bit process trying to install

a 64 bit driver with an INF file through the SetupAPI as it will (sometimes)

install to the SysWow64\Drivers directory (which according to me could never

makes sense) as a result of file system redirection.

This was the only case I was referring to: PnP drivers via SETUPAPI and its
friends. I was not referring to interacting with the SCM to install kernel
services (is that what you mean by I/O manager?). I actually don’t know how
that behaves. If it works (which is what I think you are saying), that is
nice to know.

Do you happen to know if disabling WOW64 file redirection before calling
into SETUPAPI solves the issue you note below? Even if it did, the class
installers, co-installers, and related guts that are 64-bit cannot be loaded
in-process. I wonder if that is at the root of the issue - that operations
involving the class (and device) installers simply fail because those
modules cannot be loaded.

Cheers,
-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@resplendence.com
Sent: Friday, March 27, 2009 3:18 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Devcon 32 vs 64

That information is false, a 32 bit process can install, start and
communicate with a 64 bit driver without problems through the I/O manager.
What I have seen problems with however is a 32 bit process trying to install

a 64 bit driver with an INF file through the SetupAPI as it will (sometimes)

install to the SysWow64\Drivers directory (which according to me could never

makes sense) as a result of file system redirection.

//Daniel

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> Obviously I cannot answer with authority but I recall being told at a DDC
> or
> WinHEC that it was decision and not an implementation flaw to ensure
> that
> 32-bit WOW64 processes that might not realize they are running on Win64
> cannot do stuff like install and manipulate drivers because they might
> well
> try to stuff a 32-bit binary into the system (which I answered with, and
> that won’t work anyway so why the prohibition?)
>

—
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

5

>Do you happen to know if disabling WOW64 file redirection before calling into SETUPAPI solves the issue you note below?

IIRC, turning off redirection does not solve the problem.

Satya
http://www.winprogger.com

6

I seem to recall that anything that needs to call a class (co)installer needs to be run as a native process.

A year or two ago I hacked up something to bounce some USB controller dev nodes via setupaoi on suspend/resume to work around a hardware bug on my laptop that caused said controllers to fail to boot after resume randomly, killing integrated Bluetooth + smartcard reader. I recall having to do this from 64-bit code and that was back with Vista, not W7 (my box is 64-bit).

What SetupDi APIs are you ending up calling here?

  • S

-----Original Message-----
From: Tim Roberts
Sent: Friday, March 27, 2009 10:29
To: Windows System Software Devs Interest List
Subject: [ntdev] Devcon 32 vs 64

While doing some driver testing on 64-bit Windows 7, I noticed that the
32-bit “devcon” binary was unable to restart my driver. Queries all
seemed to work fine, but “restart” failed.

That problem has a trivial solution, of course (use the 64-bit devcon
binary), but it made me wonder why. In my experience, most 32-bit apps
– even sophisticated 32-bit apps – work seamlessly on Win64. What is
it about a driver restart that cannot cross the 32/64 boundary?
Accident or design decision?

–
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

7

I remember that disabling FS redirection and calling SetupApi directly also
does not work. One thing a 32 bit process can surely do to solve the problem
is disable FS redirection to explicitly execute the 64 bit version of
rundll32.exe which calls SetupApi. Anything that will get loaded and
executed in that chain will be a native 64 bit process or library.

//Daniel

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> Do you happen to know if disabling WOW64 file redirection before calling
> into SETUPAPI solves the issue you note below? Even if it did, the class
> installers, co-installers, and related guts that are 64-bit cannot be
> loaded
> in-process. I wonder if that is at the root of the issue - that
> operations
> involving the class (and device) installers simply fail because those
> modules cannot be loaded.
>

8

Indeed, that is one of the techniques I have used (native rundll32.exe to
invoke a native DLL with helper functionality). That forms a rather crude
but effective “RPC” mechanism.

Cheers,
-Dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@resplendence.com
Sent: Saturday, March 28, 2009 4:40 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Devcon 32 vs 64

I remember that disabling FS redirection and calling SetupApi directly also
does not work. One thing a 32 bit process can surely do to solve the problem

is disable FS redirection to explicitly execute the 64 bit version of
rundll32.exe which calls SetupApi. Anything that will get loaded and
executed in that chain will be a native 64 bit process or library.

//Daniel

“David R. Cattley” wrote in message news:xxxxx@ntdev…
> Do you happen to know if disabling WOW64 file redirection before calling
> into SETUPAPI solves the issue you note below? Even if it did, the class
> installers, co-installers, and related guts that are 64-bit cannot be
> loaded
> in-process. I wonder if that is at the root of the issue - that
> operations
> involving the class (and device) installers simply fail because those
> modules cannot be loaded.
>

—
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

9

Skywing wrote:

I seem to recall that anything that needs to call a class (co)installer needs to be run as a native process.

Hmmm, that’s a possible explanation. It is a video camera in Image
class, which does have a class installer.

What SetupDi APIs are you ending up calling here?

“devcon restart” ends up calling SetupDiCallClassInstaller, which also
supports your hypothesis.

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

10

I don’t really understand how this whole ‘coinstaller’ thing works, but wouldn’t the mixture of a
32-bit process (devcon) loading a 64-bit coinstaller dll be a deal breaker?

mm

Tim Roberts wrote:

Skywing wrote:
> I seem to recall that anything that needs to call a class (co)installer needs to be run as a native process.
>

Hmmm, that’s a possible explanation. It is a video camera in Image
class, which does have a class installer.

> What SetupDi APIs are you ending up calling here?
>

“devcon restart” ends up calling SetupDiCallClassInstaller, which also
supports your hypothesis.

11

Martin O’Brien wrote:

I don’t really understand how this whole ‘coinstaller’ thing works,
but wouldn’t the mixture of a 32-bit process (devcon) loading a 64-bit
coinstaller dll be a deal breaker?

Possibly, but you’re assuming that SetupDiCallClassInstaller results in
an attempt to load and execute the class installer DLL in the current
process. I would find that surprising (but not shocking). I would have
expected the API to trigger an RPC to a privileged process where the
installer gets loaded. RPC alleviates the 32/64 issues.

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

12

Oh, I’m assuming a whole lot more than that, as I don’t know what I’m talking about :).

mm

Tim Roberts wrote:

Martin O’Brien wrote:
> I don’t really understand how this whole ‘coinstaller’ thing works,
> but wouldn’t the mixture of a 32-bit process (devcon) loading a 64-bit
> coinstaller dll be a deal breaker?

Possibly, but you’re assuming that SetupDiCallClassInstaller results in
an attempt to load and execute the class installer DLL in the current
process. I would find that surprising (but not shocking). I would have
expected the API to trigger an RPC to a privileged process where the
installer gets loaded. RPC alleviates the 32/64 issues.

13

I don’t think that there is any RPC magic to make 32-bit class installer calls work.

  • S

-----Original Message-----
From: Tim Roberts
Sent: Monday, March 30, 2009 09:44
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Devcon 32 vs 64

Martin O’Brien wrote:
> I don’t really understand how this whole ‘coinstaller’ thing works,
> but wouldn’t the mixture of a 32-bit process (devcon) loading a 64-bit
> coinstaller dll be a deal breaker?

Possibly, but you’re assuming that SetupDiCallClassInstaller results in
an attempt to load and execute the class installer DLL in the current
process. I would find that surprising (but not shocking). I would have
expected the API to trigger an RPC to a privileged process where the
installer gets loaded. RPC alleviates the 32/64 issues.

–
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