none
This device cannot start. (Code 10) on Win 7

    Question

  • Hi,

    I am developing an custom USB device and use the standard WinUSB driver for it. I followed the instructions for implementing the inf file and installed WinUSB on an XP machine. It was a bit of a battle with the inf file, but eventually I got that to install. Once the driver was installed I had no more trouble with WinUSB. My application works just fine.

    Now I wanted to install the driver on my Win 7 machine (32 bit) and continue development there. At first the driver would not install. I completely rewrote the inf file according to the latest instructions and finally got it to install on the Win 7 machine. Now I am stuck with the message 'This device cannot start. (Code 10)' in the device manager.

    According to my protocol analyzer the negotiation between the system and the device pretty much goes the same on both the XP and the Win 7 machine. The last exchange is that the system sets the configuration on the device in both cases (there is only one possible configuration). Therefore I am currently ruling misbehavior on part of the device at a very low probability.

    The past couple of days I pretty much tried 'everything under the sun' to get this work, but always with the same result. I am sure winusb.sys and associated files are not corrupt. My protocol analyzer uses them too and that works just fine and dandy.

    I would really appreciate some hints how I might approach debugging this situation. At present I don't even know if the OS is even trying to load WinUSB or not and if, what WinUSB doesn't like. Is there a way to find this out?

    Thanks.

    Friday, December 02, 2011 7:21 AM

Answers

  • code 10 means the driver is loaded and failed the pnp request to start the device (irp_mn_start_device).  it could easily be that the win7 stack is more strict about compliance than previous releases wrt your device.  look in the log for events from winusb, also if you are familiar with hooking up a kernel debugger, do so and you can run !wdfkd.wdflogdump on winusb in the failed state and see what is wrong potentially
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, December 02, 2011 7:42 AM
    Owner

All replies

  • code 10 means the driver is loaded and failed the pnp request to start the device (irp_mn_start_device).  it could easily be that the win7 stack is more strict about compliance than previous releases wrt your device.  look in the log for events from winusb, also if you are familiar with hooking up a kernel debugger, do so and you can run !wdfkd.wdflogdump on winusb in the failed state and see what is wrong potentially
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, December 02, 2011 7:42 AM
    Owner
  • Doron,

    thanks for your reply. Just to complete the information, I am using the latest version of WinUSB in both cases. It seems a bit weird that the stack would have a problem with the device behavior but still goes ahead and sets a configuration on the device. But then sometimes perfectly obvious things seem mysterious if one doesn't know what it going on. I am not set up for kernel debugging. I thought by using a ready made driver I wouldn't have to do this. Seems I might be wrong.

    Can you point me to a log file that potentially contains the information you are talking about? So far the only file having related information that I know about it C:\windows\inf\setupapi.dev.log. But this only contains information relating to the installation. BTW, this information helped me a great deal in figuring out my problems with the inf file, even though it took some head scratching. At least there was information about things the system had problems with. But this file contains nothing about device startup. Other log files I found in this directory have absolutely no information relating to USB devices.

    -- Edit --

    Hold on, I just found this blog: http://blogs.msdn.com/b/usbcoreblog/archive/2010/02/05/how-to-generate-and-view-a-winusb-debug-trace-log.aspx. It looks like this contains information on how to debug issues with WinUSB.

    • Edited by techie4 Friday, December 02, 2011 6:58 PM
    Friday, December 02, 2011 6:48 PM
  • Hi, techie4

    I have the same problem as yours.

    My xusb.sys works fine on XP, but code 10 on win7.

    Please let me know how do you do after you resolve it.

    Friday, December 02, 2011 11:26 PM
  • Steven,

    well, so far I managed to get the tracing running based on the link I had provided above. This is not as straight forward as it seems either. Follow the instructions for setup *exactly*. When setting the path do *not* place it in double quotes, even it it contains spaces! As someone in the discussion thread to that blog had pointed out the cmd file contains an error that mkes it not work. Change the second to last line in the cmd file from

    tracefmt -rt %_TRACE_NAME% -tmf "%_TMF_FILES%"\win7_winusb.tmf -display

    to

    tracefmt -rt %_TRACE_NAME% -tmf "%_TMF_FILES%\win7_winusb.tmf" -display

    Notice the second double quote has been moved.

    Then run:

    winusbtrace start

    winusbtrace view_realtime

    When you plug your device in, the trace output shows up in the DOS window. If you run winusbtrace view, it just shows useless information.

    Here is what I got (you should do the same debugging on your device, since your problem might be a different one).

    [0]0004.0044::12/02/2011-14:02:22.672 -DriverObject 0x86DF1180
    [0]0004.0044::12/02/2011-14:02:22.673 -Preparing hardware
    [1]0004.0044::12/02/2011-14:02:22.691 -Unable to select the default configuration, failing Start
    [1]0004.0044::12/02/2011-14:02:22.691 -Enter: WinUSB_ReleaseHardware
    [1]0004.0044::12/02/2011-14:02:22.691 -Exit: WinUSB_ReleaseHardware (STATUS_SUCCESS)
    [1]0004.002C::12/02/2011-14:02:22.691 -Handling Device Cleanup

    I don't know why it thinks it was unable to set the configuraiton. With my bus analyzer I can see that the configuraiton is being set and that my device acknowledges the request. There are no errors or protocol violations indicated in this exchange. So, while I have a better understanding now why the driver thinks it sholuld be unhappy, I am no closer to an actual solution.

    I hope this helps a bit.

    For anyone who might be familiar what WinUSB or the basic USB protocol stack in Win7 do/do not expect, here is an excerpt of what my protocol analyzer sees. The capture starts with the request of the device descriptor and ends with setting the device configuraiton. After that there is no more communicaiton on the bus and loading the driver has failed.

    Get Configuration Descriptor,Index=0 Length=32
     SETUP txn,80 06 00 02 00 00 20 00
        SETUP packet,2D 01 E8
        DATA0 packet,C3 80 06 00 02 00 00 20 00 B1 94
        ACK packet,D2
        IN txn,09 02 20 00 01 01 00 C0 19 09 04 00 00 02 FF 00 00 00 07 05 01 03 FF 00 01 07 05 82 03 FF 00 01
           IN packet,69 01 E8
           DATA1 packet,4B 09 02 20 00 01 01 00 C0 19 09 04 00 00 02 FF 00 00 00 07 05 01 03 FF 00 01 07 05 82 03 FF 00 01 F4 A1
           ACK packet,D2
        OUT txn,
           OUT packet,E1 01 E8
           DATA1 packet,4B 00 00
           ACK packet,D2

    Get Device Status,
      SETUP txn,80 00 00 00 00 00 02 00
         SETUP packet,2D 01 E8
         DATA0 packet,C3 80 00 00 00 00 00 02 00 B6 F4
         ACK packet,D2
         IN txn,00 00
            IN packet,69 01 E8
            DATA1 packet,4B 00 00 FE 4F
            ACK packet,D2
         OUT txn,
            OUT packet,E1 01 E8
            DATA1 packet,4B 00 00
            ACK packet,D2

    Set Configuration,Configuration=1
         SETUP txn,00 09 01 00 00 00 00 00
            SETUP packet,2D 01 E8
            DATA0 packet,C3 00 09 01 00 00 00 00 00 27 25
            ACK packet,D2
         IN txn,
            IN packet,69 01 E8
            DATA1 packet,4B 00 00
            ACK packet,D2

    • Edited by techie4 Saturday, December 03, 2011 4:31 AM
    Saturday, December 03, 2011 1:01 AM
  • Three years later, and I have apparently the same problem, with the transactions on the bus ending with an acknowledgement that configuration 1 has been set, then nothing more, and Windows 7 saying that the device cannot start.

    Any chance that someone's figured out what can cause this?

    Sunday, September 28, 2014 1:47 PM
  • Same problem... same answer. See the reply of Doron up the thread.

    -- pa

    Sunday, September 28, 2014 2:26 PM
  • It appeared to me that Doron provided a suggestion of how to proceed, and that Steven did so, but was "no closer to an actual solution" as a result.


    Edit - never mind - was a problem with the interface descriptor, which was specifying a zero sized packet; something which the driver presumably only bothers to check after setting the configuration. Kudos to Microsoft for maintaining their practice of only ever providing a "didn't work" diagnostic.
    Monday, September 29, 2014 12:54 AM