Porting a windows 32bit XP PCI Device Driver to 64bit

NTDEV
1

I have successfully managed to build a 32bit PCI Device Driver for Windows
XP, however I’ve been asked to port my device driver to run on the 64bit
edition of Windows XP.

However im not sure how to get started porting the code across, I know I
will need to update the INF file which shouldn’t be a problem as I have
played around with inf files for 64 bit drivers in the past.

my question is how do I go about porting my 32 bit driver to 64 bit? should
I just compile the driver using the 64 bit compiler and see if it links
without any errors and take it from there? or are their any special
considerations I need to take beforehand?

Regards
James
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.

2

If its written correctly and in C with no assembler, your driver should
pretty much just compile and work. I’ve got a driver that compiles for
ia32, ia64, and x64 with very little conditional code. And most of that
conditional code probably shouldn’t be there . (I inherited the driver.)

Somewhere in the MSDN stuff there are a set of driver writing rules to keep
you out of trouble. Most of the problems seem to come from casting pointers
of one type to another type, or casting variables.

Loren

3

James Dunning wrote:

I have successfully managed to build a 32bit PCI Device Driver for Windows
XP, however I’ve been asked to port my device driver to run on the 64bit
edition of Windows XP.

However im not sure how to get started porting the code across, I know I
will need to update the INF file which shouldn’t be a problem as I have
played around with inf files for 64 bit drivers in the past.

my question is how do I go about porting my 32 bit driver to 64 bit? should
I just compile the driver using the 64 bit compiler and see if it links
without any errors and take it from there? or are their any special
considerations I need to take beforehand?

Hello James,
I’ve ported one driver to 64 bit so far. Thats my experience:
The most difficult thing was to find the ddk build version which
supports 64 bit. Currently I’m still using 3790.1289
There are older and newer version which did not work for me because of
library problems.
You should know if your user level application which accesses the driver
is 32 bit or 64 bit.
If there are both 32 bit and 64 bit user level apps accessing the driver
there are at least 2 ways to handle them:
a) 2 sets of IOCTLs
b) each IOCTL is able to handle both worlds. You can use
IoIs32bitProcess to distinguish betwen 32 and 64 bit.
You should read all articles available from ms about the topic.
You will find that porting is quite easy once you’ve done it.
Uwe

4

To clarify the point about IoIs32bitProcess, you only need to call this
DDI if the structure layout is different between a 32 and 64 bit
application. If you don’t have polymorphic types in there (like PVOID
or size_t), it should be the same on both architectures.

One easy way to verify this is to load the application as a dump file in
windbg (windbg -z ). This gives you the ability to inspect
the types and offsets w/out actually having to run the application. You
just do this for both architectures and compare the results.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of uwe kirst
Sent: Tuesday, November 08, 2005 2:02 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Porting a windows 32bit XP PCI Device Driver to
64bit

James Dunning wrote:

>I have successfully managed to build a 32bit PCI Device Driver for
Windows
>XP, however I’ve been asked to port my device driver to run on the
64bit
>edition of Windows XP.
>
>However im not sure how to get started porting the code across, I know
I
>will need to update the INF file which shouldn’t be a problem as I have
>played around with inf files for 64 bit drivers in the past.
>
>my question is how do I go about porting my 32 bit driver to 64 bit?
should
>I just compile the driver using the 64 bit compiler and see if it links
>without any errors and take it from there? or are their any special
>considerations I need to take beforehand?
>
>
>
Hello James,
I’ve ported one driver to 64 bit so far. Thats my experience:
The most difficult thing was to find the ddk build version which
supports 64 bit. Currently I’m still using 3790.1289
There are older and newer version which did not work for me because of
library problems.
You should know if your user level application which accesses the driver

is 32 bit or 64 bit.
If there are both 32 bit and 64 bit user level apps accessing the driver

there are at least 2 ways to handle them:
a) 2 sets of IOCTLs
b) each IOCTL is able to handle both worlds. You can use
IoIs32bitProcess to distinguish betwen 32 and 64 bit.
You should read all articles available from ms about the topic.
You will find that porting is quite easy once you’ve done it.
Uwe

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

> b) each IOCTL is able to handle both worlds. You can use

IoIs32bitProcess to distinguish betwen 32 and 64 bit.

Yes, but all of this is necessary only if there are pointers or kernel handles
in IOCTL buffers.

Some more rules:

  • HANDLE is 64bit on Win64, be careful to not mix HANDLE with ULONG (only with
    ULONG_PTR).

  • so is any pointer

  • the pointer difference is ULONG_PTR and not ULONG

  • sizeof(struct) != sum of sizeof of fields, remember this. Structure field
    alignment can be different on Win64 if there are pointers or HANDLEs in the
    structure.

  • Itanium has one more great, very great issue called _alignment.

There was a PPT file to download on Microsoft (IIRC) with these rules.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

6

Doron Holan wrote:

One easy way to verify this is to load the application as a dump file in
windbg (windbg -z ). This gives you the ability to inspect
>the types and offsets w/out actually having to run the application. You
>just do this for both architectures and compare the results.
>
>

That is such a cool trick. It’s one of those features where you can
imagine the developers saying, “you know, with just a couple of lines of
code here, we could hook the symbol code and the dump code together, and
pretend that EXEs were dump files. I wonder if that would be useful?”

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

7

Oh yeah, I can see that ;). This also works for DLL and SYS files as
well (basically anything that is a PE file). I use it to check symbols
in drivers all the time.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, November 08, 2005 3:36 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Porting a windows 32bit XP PCI Device Driver to
64bit

Doron Holan wrote:

One easy way to verify this is to load the application as a dump file
in
windbg (windbg -z ). This gives you the ability to inspect
>the types and offsets w/out actually having to run the application.
You
>just do this for both architectures and compare the results.
>
>

That is such a cool trick. It’s one of those features where you can
imagine the developers saying, “you know, with just a couple of lines of

code here, we could hook the symbol code and the dump code together, and

pretend that EXEs were dump files. I wonder if that would be useful?”

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

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

I don’t know if I’m barking up the right tree, but recently I
had problems with data structures where 64-bit variables weren’t
aligned on 64-bit boundaries on the 32-bit driver. The 64-bit
compilation automatically aligned 64-bit items on 64-bit
boundaries, and I decided - partly because of lack of time,
partly because of laziness - to change the structures on both
sides so that they are always aligned on their natural
boundaries regardless of compiler options and/or which machine
they’re running. A further complication is that my driver must
run on both 32-bit and 64-bit environments and different
machines must be able to talk to each other over a network.

Alberto.

----- Original Message -----
From: “Doron Holan”
To: “Windows System Software Devs Interest List”

Sent: Tuesday, November 08, 2005 1:35 PM
Subject: RE: [ntdev] Porting a windows 32bit XP PCI Device
Driver to 64bit

To clarify the point about IoIs32bitProcess, you only need to
call this
DDI if the structure layout is different between a 32 and 64 bit
application. If you don’t have polymorphic types in there (like
PVOID
or size_t), it should be the same on both architectures.

One easy way to verify this is to load the application as a dump
file in
windbg (windbg -z ). This gives you the ability to
inspect
the types and offsets w/out actually having to run the
application. You
just do this for both architectures and compare the results.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of uwe
kirst
Sent: Tuesday, November 08, 2005 2:02 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Porting a windows 32bit XP PCI Device
Driver to
64bit

James Dunning wrote:

>I have successfully managed to build a 32bit PCI Device Driver
>for
Windows
>XP, however I’ve been asked to port my device driver to run on
>the
64bit
>edition of Windows XP.
>
>However im not sure how to get started porting the code across,
>I know
I
>will need to update the INF file which shouldn’t be a problem
>as I have
>played around with inf files for 64 bit drivers in the past.
>
>my question is how do I go about porting my 32 bit driver to 64
>bit?
should
>I just compile the driver using the 64 bit compiler and see if
>it links
>without any errors and take it from there? or are their any
>special
>considerations I need to take beforehand?
>
>
>
Hello James,
I’ve ported one driver to 64 bit so far. Thats my experience:
The most difficult thing was to find the ddk build version which
supports 64 bit. Currently I’m still using 3790.1289
There are older and newer version which did not work for me
because of
library problems.
You should know if your user level application which accesses
the driver

is 32 bit or 64 bit.
If there are both 32 bit and 64 bit user level apps accessing
the driver

there are at least 2 ways to handle them:
a) 2 sets of IOCTLs
b) each IOCTL is able to handle both worlds. You can use
IoIs32bitProcess to distinguish betwen 32 and 64 bit.
You should read all articles available from ms about the topic.
You will find that porting is quite easy once you’ve done it.
Uwe

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@microsoft.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com

9

I have managed to port my 32bit driver to 64bit, and it has been
successfully installed on to
Windows XP x64 Edition, however the driver will lockup after a few seconds
while performing DMA operations.

I am sharing a copy of the DMA status register, in the Device Extension of
type UCHAR, the status register allows me to determine whether my PCI device
is interrupting upon completion of a DMA transfer, and to indicate whether
the DMA transfer was completed.

From the debug logging I have noticed that the copy of the DMA status
register is going out of sync between the InterruptHandler and the DPCforISR
routine. In one case the status register would be set to 0x84 Hex in the
interrupt handler, only to find that the copy of the status register has
been cleared before it enters the DPCforISR routine.

The access to the copy of the status register is controlled by the use of
KeAcquireInterruptSpinLock and KeReleaseInterruptSpinLock, so this has left
me rather confused! especially when the copy of the status register can only
be cleared from the DPCforISR routine.

Incidentally, I have added count information in the device extension to
determine how many times an IRP_MJ_READ request was handled, how many times
the InterrruptHandler was called, and how many times the DPCforISR routine
was called… these counts did not reveal anything out of the ordinary…

The driver is installed on a dual Opteron 251 system. any advice or
suggestions would be appreciated.

Regards
James

This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.

10

Ah haa! solved it, foolish mistake on my behalf… I decided to check if
there were other
devices sharing the same interrupt as my PCI device, using winmsd.exe. it
turns out that there
were two other devices sharing the interrupt which was overwriting my copy
of the status control
register.

I should have read the status control register into a local variable and
copied it to my device extension
if it was an interrupt from my device…

Oppps! this would have been an issue with the 32bit driver as well, but it
wasn’t spotted since it wasn’t sharing its interrupt.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of James Dunning
Sent: 09 November 2005 14:36
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Porting a windows 32bit XP PCI Device Driver to
64bit

I have managed to port my 32bit driver to 64bit, and it has been
successfully installed on to
Windows XP x64 Edition, however the driver will lockup after a few seconds
while performing DMA operations.

I am sharing a copy of the DMA status register, in the Device Extension of
type UCHAR, the status register allows me to determine whether my PCI device
is interrupting upon completion of a DMA transfer, and to indicate whether
the DMA transfer was completed.

From the debug logging I have noticed that the copy of the DMA status
register is going out of sync between the InterruptHandler and the DPCforISR
routine. In one case the status register would be set to 0x84 Hex in the
interrupt handler, only to find that the copy of the status register has
been cleared before it enters the DPCforISR routine.

The access to the copy of the status register is controlled by the use of
KeAcquireInterruptSpinLock and KeReleaseInterruptSpinLock, so this has left
me rather confused! especially when the copy of the status register can only
be cleared from the DPCforISR routine.

Incidentally, I have added count information in the device extension to
determine how many times an IRP_MJ_READ request was handled, how many times
the InterrruptHandler was called, and how many times the DPCforISR routine
was called… these counts did not reveal anything out of the ordinary…

The driver is installed on a dual Opteron 251 system. any advice or
suggestions would be appreciated.

Regards
James

This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@generaldynamics.uk.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any files attached are intended for the addressee and may
contain information of a confidential nature. If you are not the intended
recipient, be aware that this email was sent to you in error and you should
not disclose, distribute, print, copy or make other use of this email or its
attachments. Such actions, in fact, may be unlawful. In compliance with
the various Regulations and Acts, General Dynamics UK Limited reserves the
right to monitor (and examine for viruses) all emails and email attachments,
both inbound and outbound. Email communications and their attachments may
not be secure or error- or virus-free and the company does not accept
liability or responsibility for such matters or the consequences thereof.
Registered Office: 100 New Bridge Street, London EC4V 6JA. Registered in
England and Wales No: 1911653.