I have experienced the same upload problem on a Win10 PC on my Arduino 101 and I discovered some interesting facts.
While I'm a blog newbie, I have worked in electronics since the '70's when I built my own 8008 (NOT 8080!) micro for my college senior design project.
My original research on this bug included graphic screen captures, which I won't be able to use here (but they are available if needed). I will try to explain everything without the graphics. Maybe this note will help Intel and/or anyone else to figure out the additional pieces of this puzzle that I have yet to find.
This all started when I tried the blink example to test my new Arduino 101. I started by using the board manager to add the Intel Curie. I then loaded the example blink code. Clicked the compile and load button, when it started the downloading, there was a long pause which ALWAYS ended with these error messages each time I tried:
Waiting for device...
Cannot open DFU device 8087:0aba
Cannot open DFU device 8087:0aba
Cannot open DFU device 8087:0aba
ERROR: Timed out waiting for Arduino 101.
I noticed that when I connect the 101 board, there are THREE sets of audio annunciations, the third being delayed several seconds. A normal USB device only generates two: [1] USB inserted, and [2] USB driver started (or so I think). Using Microsoft's free USBView program, I saw that this was indeed an Intel USB driver:
idVendor: 0x8087
idProduct: 0x0AB6
bcdDevice: 0x8087
iManufacturer: 0x01
0x0409: "Intel"
iProduct: 0x02
0x0409: "ARDUINO 101"
(Some may recall 8087 as Intel's old 8086 math coprocessor designation.) The 8087:0aba in the error message is NOT using the Intel Arduino 101 PID of 0x0AB6. More on that later. I googled and found a list of USB vendor IDs kept by none other than the fine people who maintain Linux and that list shows 0x8087 “belongs” to Intel.
I found that what the Arduino IDE saw as the 101's com port was identified by device manager as a Teensy com port driver and not Intel. I then recalled using the board manager to install Teensy on this PC BEFORE adding the Intel Curie. Later, I had the Win10 control panel for "printers and devices" open while playing some more and noticed that when I unplugged the 101 and plugged it back in, it MOMENTARILY shows "Arduino 101" and then after that third audio annunciation it changed to Teensy!
That "official" Linux list shows Teensy using 18 PIDs (product IDs) for USB drivers but all use a VID of 0x16c0 registered to Van Ooijen Technische Informatica and not the 0x8087. So why is my PC showing the Teensy driver as using a VID of 0x8087? That is part of the mystery.
Being stuck, I decided to try something else. I wanted to test a theory: will the 101 work on a PC that never had the Teensy driver installed (via the board manager)? So I tried running the "blink" test on a "clean" laptop. It loaded and ran fine --- most of the time! I guess Intel still has some (timing?) problems with their driver software. I found out that the Intel driver uses a "backdoor" to change the port's baud rate from the default of 9.6 kbps to 57.6 kbps "momentarily" for uploads by first changing the baud rate to 1.2 kbps which causes the Arduino 101 to (quickly?) reset itself so it can then run the bootloader and download the program (if I understand it correctly).
Now I need find out how to I get rid of that interfering Teensy driver on my main PC. Since I had used FTDI's driver removal tool in the past, I thought I would give that a try, but it just removes everything with a specific VID/PID pair and that would get rid of Intel's driver too, so I haven't tried that (yet).
The Arduino website indicates "This (loading) problem does not occur on Linux", I don't think that it takes into account what I found, so it's possible the problem could exist on Linux.
So why doesn't the Teensy driver work? Because it knows nothing about that backdoor to get the 101 to load code. I think that is done via a special downloaded script (intel-arduino-tools/cluploadArduino101_win.sh at 4fa4d12957d397e938721f0e44dec6abe1685c5d · intel/intel-arduino-tools · GitHub). I'm not a Linux guy (mostly deep embedded with a little PC), but I noticed that the script above has the line:
dfu_cmd="$dfu -d8087:0ABA"
So THAT'S where the earlier 0aba came from! A quick search revealed that the dfu command is Linux's Device Firmware Upgrade command for AVR (and apparently Intel) processors. So that implies the Curie has a mini version of Linux running.
In spite of me spending several hours on this, that's as far as I got so far. I originally thought "blink" would take a few minutes. Boy was I wrong! Hope it helps someone to figure out the rest!
At least for now, I can use the other PC to play with my Arduino 101, but I still want it to work on my main PC!