DeviceIoControl failed in WOW64 on 64bit XP Pro

Discussion in 'Windows Vista Drivers' started by hyfeng, Nov 17, 2004.

  1. hyfeng

    hyfeng Guest

    I have an application that is required to run under 64-bit Windows
    (AMD64/EM64T). I am using 64-bit XP Pro for test (build 1218, shown build
    3790 on screen). The applications issue many DeviceIoControl() to driver
    and NDIS. Some of the DeviceIoControl() failed or returned bad data. THe
    problem is that, even with the same OID, someties it worked and sometimes
    it didn't. I used WinDbg to looked into driver. It appeared like the driver
    may not received correct parameters from my application. When the
    DeviceIoControl() failed, I can see driver was getting bogus data form the
    InformationBuffer. By the way, there is no pointer-precision data. All data
    in the buffer are fixed-precision type.

    My question is: is this a known problem? If it is, when it can be fixed?

    hyfeng, Nov 17, 2004
    1. Advertisements

  2. Alignment can be an issue. Align all IOCTL buffers on 8 bytes.
    Maxim S. Shatskih, Nov 18, 2004
    1. Advertisements

  3. hyfeng

    hyfeng Guest

    Well, I understand alignment very likely is the issue and that is probably
    what I will do to get around the problem.

    However, WOW64 is supposed to provide thunking properly so that 32-bit
    applications do not need to change and that is why I think this is a
    problem from WOW64 and I need confirmation form Microsoft. Also, please
    keep in mind that there is no pointer-precision data in the buffer passed
    into DeviceIoControl(). All data in the buffer are fixed-precision type.
    hyfeng, Nov 18, 2004
  4. I understand that you are not passing any pointers... However, the data
    passed two and from a driver intrinsically uses pointers in the IRP that,
    depending on the I/O method, may be mapped for you.

    HOWEVER, it has been my experience that some 64-bit components check for
    64-bit alignment of IRP buffers before they check anything else. For
    example, a call to read a 32-bit value may fail because the 32-bit value is
    not aligned on a 64-bit boundary.

    I think that this is a bug - or at least isn't documented sufficiently
    anywhere that I looked.

    Good luck,

    Thomas F. Divine, Windows DDK MVP
    Thomas F. Divine [DDK MVP], Nov 18, 2004
  5. hyfeng

    hyfeng Guest

    I think it is bug in WOW64. I changed my code to make sure all buffer I
    passed to DeviceIoControl() are at 8-byte boundary. THe result was still
    the same. Some OID succeeded, some failed and they use the same buffer.
    hyfeng, Nov 18, 2004
  6. windows has no way of how to thunk a DeviceIoControl buffer. Unless NDIS is
    checking for a 32 bit process and using a 32 bit version of the structure,
    you will still have probelms on structure packing, ie how much padding there
    are between fields in 32 vs 64 bit structures.

    Doron Holan [MS], Nov 19, 2004
  7. hyfeng

    hyfeng Guest

    Please check out the article from MSDN.

    Windows certainly will not thunk the contents in the buffer. But, it will
    convert the buffer pointer to 64-bit pointer. As for the contents in the
    buffer, maybe you miss in my previous messages. I used all fixed-precision
    data. And, from what I saw, it's not the 'packing' problem. the contents in
    the buffer are garbage. It looks like the pointer passed to the driver is
    point to wrong place.

    By the way, we do define 'packing' for our structure and that will take
    care of your concern.
    hyfeng, Nov 19, 2004
  8. hyfeng

    Calvin Guan Guest

    For example, a call to read a 32-bit value may fail because the 32-bit
    value is
    Alignment requirement for 32-bit value in 64-bit system is 4-byte boundary.
    Not aligned on a 64-bit boundary by itself won't fail if it's aligned to
    4-byte boundary (PtrAddr %4 == 0)
    Calvin Guan, Nov 21, 2004
  9. Are you using one of the NDIS IOCTLS? Is it being sent to the device object
    created by NDIS for the miniport (the one using the miniport GUID) or is it
    going to a miniport created device object?

    Have you tried running a 64 bit version of the application (or a 32 bit
    version on 32 bit 1218)?

    Mitesh Desai [MSFT], Nov 23, 2004
  10. hyfeng

    hyfeng Guest

    I tried both NDIS defined IOCTLs and our prorpietary IOCTLs and both
    behaved the same (some work and some don't). I had also compiled my
    applications to 64-bit and it worked just fine for all IOCTLs. By the way,
    the application is running ok on 32-bit OS (w2k, XP, 2003) too.

    So far, the problem case is under WOW64 envoronment. For some unknown
    reason, sometimes driver just received garbage in buffer or the
    DeviceIoControl() failed.
    hyfeng, Nov 23, 2004
  11. For proprietary IOCTLs, your driver is responsible for handling any WOW64
    thunking. NDIS does not touch the buffer.

    For NDIS IOCTLs, these are query only. NDIS will not copy the data from the
    user mode input buffer to the buffer it passes to the miniport (there are
    some rare cases in which it ends up passing the data down). You cannot
    assume that data in user mode buffer will get passed to miniport. If you
    want that, you have to use WMI.

    Mitesh Desai [MSFT], Nov 23, 2004
  12. hyfeng

    hyfeng Guest

    As I mentioned in my earlier message, I used fixed-precision data and had
    defined pack. All I need is WOW64 to convert the 32-bit buffer pointer in
    DeviceIoControl() to 64-bit and pass to driver. As for the result, WOW64 do
    the job well in most cases. But, sometimes, driver simply received a
    pointer full with garbage even with the same IOCTL. Frr example, my
    application may call the same IOCTL over and over again and it may mail
    sometimes. That is why I think there is problem in WOW64.
    hyfeng, Nov 24, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.