Hi,

We are using CyAPI.lib and capturing pnpevents waiting for a DBT_DEVTYP_HANDLE. All is running ok if used on a 32 bits machine. But the same app, when used in a Windows 7 64 bits, is not capturing the DBT_DEVICEREMOVECOMPLETE in the same way.

The documentation says we should capture DBT_DEVICEREMOVECOMPLETE events, and then check if the event is:

pDBHdr = (PDEV_BROADCAST_HDR) lParam;

if (pDBHdr->dbch_devicetype == DBT_DEVTYP_HANDLE)

     WhateverCode....()

After some debugging, we noticed that sometime the event is DBT_DEVTYP_DEVICEINTERFACE, and not DBT_DEVTYP_HANDLE. We are sometimes receiving both events. That should not be a problem if we just capture the DBT_DEVTYP_HANDLE types. What happens is that the first time I disconnect the device, we are just receiving a DBT_DEVTYP_DEVICEINTERFACE event. If we continue pluging in and out, we are receiving the DBT_DEVTYP_HANDLE event on the nexts, but the first time we are not receiving the DBT_DEVTYP_HANDLE. 

Is there something we are missing?

Just rephrasing your above query,

In Windows 7 64-bit you get DBT_DEVTYP_DEVICEINTERFACE for the first disconnect. After that all the disconnect trigger DBT_DEVTYP_HANDLE as expected. Is my understanding right? Have you tried using the x64 library and compiling the application for 64-bit?

Regards,

Anand

 Yes, your understanding is right. Moreover, later when we are capturing DBT_DEVTYP_HANDLE, we are also capturing DBT_DEVTYP_DEVICEINTERFACE, but as we captured what we expected, we just ignore the rest of events.

We have not tried to compile using the x64 lib, because we are not compiling for 64 bits. That is a future work for us, at current moment we are compiling only in 32 bits, and all is running ok but this. Before we were using .NET component CYUSB.dll, but some months ago we started to use CyAPI.lib, trying to avoid .NET for a simple driver. You mean we cannot use 32bit CyAPI.lib for 64 bit machines, althoug our software is entirely compiled in x86 mode?

These events are generated by the OS so we don't have much visibility as to what is happening internally. We're just using WindowProc to listen to these messages, understand what is happening and react accordingly.

32 bit applications run in 64-bit using wow64, just wanted to take this out of the equation to see if it is behavior seen across Win7 x64.

Regards,

Anand

 Ok, thanks aasi. Until now we were using a barely modified version of sample code from cypress to register events. The original way:

[code]

PDEV_BROADCAST_HDR bcastHdr = (PDEV_BROADCAST_HDR) Message.LParam;

if (bcastHdr->dbch_devicetype == DBT_DEVTYP_HANDLE) { 

      PDEV_BROADCAST_HANDLE pDev = (PDEV_BROADCAST_HANDLE) Message.LParam;

  if (pDev->dbch_handle == USBDevice->DeviceHandle())

        USBDevice->Close();

    }

  }

[\code]

Seeing that we are not receiving always the DBT_DEVTYP_HANDLE, we changed to

[code]

PDEV_BROADCAST_HDR bcastHdr = (PDEV_BROADCAST_HDR) Message.LParam;

if (bcastHdr->dbch_devicetype == DBT_DEVTYP_DEVICEINTERFACE) { 

  PDEV_BROADCAST_HANDLE pDev = (PDEV_BROADCAST_HANDLE) Message.LParam;

  GUID guidRemovedDevice;

  CLSIDFromString(L"{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX}", &guidRemovedDevice);

  if (pDev->dbcc_classguid == guidRemovedDevice)

        USBDevice->Close();

    }

  }

[\code]

I will report you if it worked on all OS versions (Windows 7 32-64 bits, Win XP 32 bits).

 I will update our solution to the problem for someone having something similar.

In Windows XP we are receiving just one event, of type DBT_DEVTYP_HANDLE

In Windows 7 64 bits, we are receiving in the first disconneciton of the device an event of type DBT_DEVTYP_DEVICEINTERFACE. After that, everty time we disconnect, we are receiving two events, one of type DBT_DEVTYP_DEVICEINTERFACE and one more of type DBT_DEVTYP_HANDLE, and they are launching in random order.

Our solution is to capture both events, to close the device. As we are notifying that the device has been disconnected, and we don't want to notify two times, we have made a simple algorithm to syncronize the events, and we are just capturing the first event we receive.

I hope this information is helpful for someone else.

Best regards,