32 to 64 bit upgrade issues

Hello All,

I have inherited a device driver project (my background is user mode applications). The driver works successfully on windows 7 32 bit. My task has been to port this driver to 64 bit windows 7 (it will be targetting windows 10 soon).

I have built the driver with the X64 checked build enviroment in the windows 7 ddk. I can installed the driver and see the device in devicemanager and USB view.

The driver works by creating a windows file object and the client using the usual Win32 file IO command to read and write data.

The driver code (acquired from a third party many years ago) is based on the loopback example from “programming the windows driver model, 2nd Edition”.

The driver will successfully plug and play, the device properties can be examined in device manager, and the client can successfully open the virtual file handle representing the device. I have test signed the device and the machine is currently in test signing mode (i.e. I have call “bcdedit set testsigning on”

However, when I attempt to read or write data to the device, when I submit my URB to the device stack, my call to IoCallDriver will return STATUS_PENDING, but not return any data. The only way the completion routine is called is when I physically unplug the usb cable to the device.

As far as I can tell, setup prior to the call to IoCallDriver matches the recommended best coding technique as shown here. https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/send-requests-to-the-usb-driver-stack.n

I’m hoping someone might be able to shed some light on why this might not work in 64bit windows, or how I might find out what is going on further down the usb stack.

thanks,

Andy

Wow, that’s some old code…Sorry, had to say it :slight_smile:

Not much to go on based on your description of the behavior you’re seeing. Nothing should really change in a USB driver from 32-bit to 64-bit.

Aside from recommending that you rewrite the driver in WDF, I’d hook up a USB analyzer and check the traces in the working and non-working cases. You might get something out of the USB ETW trace messages, but nothing will beat a hardware analyzer.

@“Scott_Noone_(OSR)” said:
Wow, that’s some old code…Sorry, had to say it :slight_smile:

Not much to go on based on your description of the behavior you’re seeing. Nothing should really change in a USB driver from 32-bit to 64-bit.

Aside from recommending that you rewrite the driver in WDF, I’d hook up a USB analyzer and check the traces in the working and non-working cases. You might get something out of the USB ETW trace messages, but nothing will beat a hardware analyzer.

Its some legacy hardware which we need to support going forwards. Its been in production without issue for over 10 years now. The plan will be to migrate the target OS from 32bit Windows 7 to 64 Bit windows 10 by start of Q2 2010. This is a 64 bit proof of concept, before we move to Win10. I’ve already attempted to use the ETW - I am unfortunately constrained by the software development environment in which I have to work, so currently I need to use Event Viewer to view the trace events. I’m seeing a lot of 71 and 26 event iDs from my USB-USBPORT - I’m not sure what these events are or even if USB-USBPORT is the correct thing to be tracing.

Unless the driver was badly written, there usually aren’t any real issues going from 32-bit to 64-bit. Just double check to make sure you aren’t storing addresses in ULONGs, and if you’re passing structures through an ioctl, make sure the fields are all the same size in 32 and 64-bit land. Beyond that, none of the USB functions have changed.

Hm, I sent a similar reply by email some hours ago, but it looks like it got lost in the new forum software. :frowning:

Thanks for everyone’s reply. Your assistance and patience has been very much appreciated. We found some documentation for the device in question and subsequently we found some issues in what we were sending to our device. So it is all now working as expected.