So I am having the same problem as the OP and I found it is directly due to an invalid or incompatible coded configuration descriptor 'configDescrCDC' in DigiCDC.cpp.
Although I am close, I unfortunately dont have intimate knowledge of what interrupts or pipes the developer is trying to use in the lowcdc.sys driver. I can see and work with the existing configuration descriptor but for the life of me, I cant figure out what is wrong with the descriptor except that it looks like it might be mistructured.
Duplicated with Windows 8.1 64 bit, Arduino IDE 1.6.5, Digistump AVR 1.6.5, on a brand new digistump pro board.
I am able to coerce the digistump virtual serial port driver to install by changing the size of the returned configuration descriptor, but then the device cannot start. This is line 392 - return sizeof(configDescrCDC); - changed to - return configDescrCDC[0] > of digiCDC.cpp. This change is wrong since windows will now think the descriptor size is only 9 bytes, but this lets windows read the first part and install the corresponding digistumpCDC driver.
If I leave the correct size on the configuration descriptor, and remove the class descriptor and data interface descriptor within it, then the device does start but windows immediately crashes out and gives a 'stack unhandled exception' in lowcdc.sys. I assume this is the case because since I have removed the pipes and it does start/connect, the lowcdc driver crashes because it cannot find an expected resource.
I am using Theyscon's descriptor dump utility to analyze my changes/findings - tool can be found here:
http://www.thesycon.de/eng/usb_descriptordumper.shtmlIf the developer of digistumpCDC would care to chime in, or any other working user of the latest digistumpCDC library, it would be very helpful.
If I could just get a dump of a working install, I may be able to figure out the problem for installations like mine. Any working setup could help by running the above tool, selecting the digistump pro device in the tool vendor 16D0/product 087E (if your vendor/product id differ you can find it by going to properties for the digistump virtual com port in device manager), select show hex dump under options, and then file - save to file.
Since the descriptor is seen as malformed by windows and the above tool in an installation like mine, I cant see what a good descriptor should look like. If someone can post theirs, I might have a chance at finding a solution. I have two machines with a similar setup, and I have the same problem on both.
My suspicion is that the endpoints are of the wrong count, or in the wrong order, as the class descriptor looks correct, and the interface descriptors look correct, and the total length and size of each descriptor seem fine. Its possible that different versions of windows or different architectures may be more tolerant or less picky, but not in all cases.
