Devcon Failed Windows 10
Timothee Cazares
I can't use the ia64-version of devcon.exe on my Windows7 professional x64 (AMD CPU). error message tells me, that the version of this applcation is not suitable for this version of windows and I should check whether I need to use a x64 or x86 version of this application.
That is for the Itanium architecture. Just because Itanium is 64-bit, it is VERY different from the 64-bit Windows OS'es you see here day to day. It requires a different set of chips and a different type of processor. It will not work.
Hi all, I am trying to get my head around windows drivers. I am using WDM (I was thinking of writing some drivers for some old hardware, windows 2000 type stuff), but currently using latest Windows 10 for devel.
I understand the inf is not technically neccesary for non-pnp devices, and in my case the driver is really nothing more than a service? it is only used for certification?
I try to install my driver by running >devcon install MyDriver1.inf root\mydevice.
Why does devcon not create the node that I told it to? It always seems to default to the ROOT\SYSTEM\xxxx node. Other drivers seem to be able to create their own nodes no problem, but mine always defaults.
Ive also recently read that the Manufacturers section in the .inf is only for PnP devices, and one should use the DefaultInstall section. I tried this, but in both cases devcon still didnt create the device node that I wanted.
But this had seemingly no effect; the devcon tool still insists on creating a node called ROOT\SYSTEM\xxxx when I look through the log. Furthermore, If I remove the [Manufacturers] entry, how do I specify what hardware ID it should match?
I had the 64-bit version of the WDK toolset in my path, but I was building 32-bit .SYS file. I just needed to switch Visual Studio to build the x64 build, and when I loaded that, devcon finally did something interesting.
dlinear:
I think the problem is with the driver on the PC. I'm attaching waveforms I collected from the Arduino (pins 1 and 2) showing the data being sent/received and I can see signals on the USB lines (differential and occurring much much faster). But I still can't receive data (can send).
I can use the "devcon" command from Microsoft to reset the Arduino USB port from the command line, and this resets the serial communication. I have to waive the white flag and use this hack as a solution, but this is hardly solved.
Could you detail what you're doing with the devcon command? I think I've been having this same issue and haven't found anyway to fix it. Is it a disable/enable command on the arduino.? Maybe you can just post the code that you run? Thank you for your help.
With pleasure. It was complicated for me because you need Administrator permissions to reset the USB port and I don't want my program to run with Admin permissions. Thus, I had to add a task to the "Task Scheduler" in windows, and checked the "Run with highest privileges" option under Security options. This allowed me to bypass the UAC in windows.
Critically, I must close the port first and also wait 3 seconds before reopening the serial connection. I didn't test the minimum amount of wait time, but I know you need some time because without the delay, it wouldn't work.
My colleague suggested using a USB 2.0 hub instead of a USB 3.0 hub. It ran for over 3+ hours, no problem. This isn't a solution for me because I need the camera to work at USB 3.0 speeds, but it's a useful clue.
Thus, tomorrow I will try using the Arduino Ethernet I had lying around along with the FTDI friend from Adafruit. This is slightly inconvenient as I would like to use pins 10,11,12, and 13 (which are used for Ethernet on this board), but it will be a great test to determine if the usbser.sys Windows driver is the problem or if it's something else. The fact that the other hardware I'm using also uses the FTDI driver (which never crashes) leads me to believe this is a worthwhile test.
Are there any other Arduinos, with the same connections as the UNO that use the FTDI chip? It seemed like early versions of the Arduino UNO used this chip, but that doesn't seem to be the case anymore.
OK, I've been running 4+ hours with the FTDI enabled Arduino Ethernet, and everything is working great. I believe the usbser.sys file from Microsoft is the issue here. I'm going to post some links to confirm this is the issue.
Looks like this is the culprit. By hardware vendors, it looks like Microsoft is the culprit here. I believe the USB 3.0 camera is making this bug more prevalent than with most users, but look at these links.
The fact that some users continue to claim on this forum indicates the problem is more widespread than I thought. I have ordered an old version of the Arduino with an FTDI chipset for USB and will use this as a solution.
Having recently obtained an new laptop running Win8.1 64, I went through lots of pain and hoop jumping trying to get drivers installed for my hardware ICSP programmers, but you know what didn't cause a bit of trouble? I plugged my FTDI based Nano board in and Windows already had a proper driver ready for it, nothing I had to do.
The FTDI is a great general purpose USB serial COM port bridge and is my preferred solution over the direct AVR usb based solution. I realize that added capability of being able for the AVR to act like a USB host device can be a big deal for some, it just seems over complex and troublesome for those that just want PC COM port communications to be simple and reliable.
Nothing here...
MSP430 with the same issue: MSP430USB versus FTDI - MSP low-power microcontroller forum - MSP low-power microcontrollers - TI E2E support forums
...applies because you are not pulling out the USB cable.
Noise induced on the USB data lines causing a bug in usbser.sys to become problematic. Less noise = fewer problems. More shielding = less noise. Better cable = more shielding. Better cable = fewer problems.
Less noise would be better, but I can't guarantee the noise levels in the background when I deliver this instrument. While it could be true that the many cables I tried were inadequate, I don't believe this explains why the problem goes away when I use the USB 2.0 hub instead of the USB 3.0 hub (unless the two USB 3.0 A->B cables I have are also bad). The arduino cable is already very short at 18".
Not only do I get the FTDI chip, I don't have to cut a trace to prevent the auto-reset. I soldered a wire there so that I can recreate that behavior when necessary, but this is a much more elegant solution
That is the very definition of "specious reasoning": There is a problem with usbser.sys (low speed bulk transfer; whatever that is) so that must be what is causing communications to stop in my case (even though the symptoms are clearly not the same).
While it could be true that the many cables I tried were inadequate, I don't believe this explains why the problem goes away when I use the USB 2.0 hub instead of the USB 3.0 hub (unless the two USB 3.0 A->B cables I have are also bad).
My touch screen is working in bios but as soon as I go to windows, none of my drivers are working. I tried installing from hp website and it said devcon.exe failed. In the hp support assistant app, it says no updates available. This is not hardware because the touch screen is working in bios
Hello! I recently was able to fix my HP Stream 7 after two years of leaving it untouched since it was broken. Now, I have a new problem I am facing with this tablet and that is that I cannot install this touchscreen driver known as "Goodix Touch Controller Driver". When I got through the agree page and all that, now it is the installaion bit. Note that the touch screen works in bios mode.
If it works on bios, it's a software issue, update the drivers from the HP Website, if the issue persists: please reinstall windows using the recovery partition or the recovery media to fix the issue
as many others here, I am affected by the problem that the Intel driver for the integrated graphics doesn't work when a display is connected via DVI or HDMI (VGA works fine). When this happened to me, I was quite disappointed first, but then I started to thinks of ways to solve the problem.
While thinking about it, I remembered that when I first installed the driver, it was working with the Intel driver active until the next reboot. So, as my display has both DVI and VGA inputs, I decided to connect it via both (my PC has both outputs) and see if I could get it to work. After some trial and error, I found out, that when I deactivated and then reactivated the device in the device manager, it would work perfectly normal over DVI. So I concluded, that there must be some problem with the driver initialization when Windows starts. That problem doesn't appear when the driver is initialized later.
(Intel support: maybe this could be a starting point for your engineers to sort this problem out? It definitely works with these displays, the only problem is, that the driver fails to work when it is started with Windows.)
ff7609af8f