Hello,
We have a number of legacy products that pair a dll with a kernel driver. They work when the bit width of the dll matches the the bit width of the driver – 32-bit dll & 32-bit driver; 64-bit dll and 64-bit driver. However 32-bit dll’s do not work with the 64-bit drivers. The reason is that the dll’s make a lot of DeviceIoControl calls passing pointers to structures that contain pointers and fields of type HANDLE. As an example, we might have
typedef struct _S
{
void *a;
HANDLE b;
} S;
where the handle allows the driver to signal when something of interest happens. Naturally, when the driver tries to do something with the handle, it’s looking at a bad address;
What are the commonly-accepted-ways of building things to accomodate 32-bit dll’s with 64-bit drivers?
Getting rid of the pointer is easy, but I’m wondering about the handle.
Thanks,
xxxxx@comcast.net wrote:
We have a number of legacy products that pair a dll with a kernel
driver. They work when the bit width of the dll matches the the bit
width of the driver – 32-bit dll & 32-bit driver; 64-bit dll and
64-bit driver. However 32-bit dll’s do not work with the 64-bit
drivers. The reason is that the dll’s make a lot of DeviceIoControl
calls passing pointers to structures that contain pointers and fields
of type HANDLE. As an example, we might have
typedef struct _S
{
void *a;
HANDLE b;
} S;
where the handle allows the driver to signal when something of
interest happens. Naturally, when the driver tries to do something
with the handle, it’s looking at a bad address;
What are the commonly-accepted-ways of building things to accomodate
32-bit dll’s with 64-bit drivers?
It’s never a good idea to pass a pointer in a structure to an ioctl.
The best way to do that kind of thing is to use METHOD_IN_DIRECT, pass
the handle as the first ioctl buffer, and pass the pointer as the second
ioctl buffer. That way, the operating systems handles the magic for you.
To deal with the handle, you’re going to have to use IoIs32BitProcess
and treat the buffer differently. Here’s a document that describes this
process, and their example is practically identical to yours:
http://www.microsoft.com/whdc/driver/kernel/64bit_chklist.mspx
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> It’s never a good idea to pass a pointer in a structure to an ioctl.
Agreed. This stuff got written long before I started working here. The original authors are gone, & I get to clean up. 
The best way to do that kind of thing is to use METHOD_IN_DIRECT, pass
the handle as the first ioctl buffer, and pass the pointer as the second
ioctl buffer. That way, the operating systems handles the magic for you.
Ah. Thanks.
To deal with the handle, you’re going to have to use IoIs32BitProcess
and treat the buffer differently. Here’s a document that describes this
process, and their example is practically identical to yours:
http://www.microsoft.com/whdc/driver/kernel/64bit_chklist.mspx
Again, thanks.
–
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