Summary
I'm developing firmware and a PC test application for a custom USB device, using the STM32F072 Discovery board. The device includes Microsoft Windows Compatible IDs (WCIDs) to enable automatic installation of the WinUSB driver on the PC.
The device is enumerated correctly on other Windows 10 hosts, but not on my Windows 10 development PC. My development PC had previously tried to enumerate the device when it had the same VID/PID combo, but with different descriptors/metadata. If I change the PID to some other number (new to my development PC), it does enumerate correctly.
Questions
How can I get this to work with my desired VID/PID combo on my development PC?
Is Windows caching USB metadata the cause of the failed enumeration on this one PC?
What are best practices on the (Windows) PC-side for testing/development of USB device firmware, during the stage when device descriptors and metadata are in flux? Is it possible to avoid chewing up PIDs just to avoid the Windows caching?
Details
Because of the way Windows caches USB descriptors and the like from previous enumerations, during firmware development, I was incrementing the device Product ID (PID) in the firmware after each time I made other changes, to ensure that Windows wasn't caching things from previous iterations of the descriptors, and messing up stuff that would otherwise work.
Now I've gotten the device to enumerate successfully on Windows 7, 8, and 10 PCs as a WinUSB device, and I've established communication. But when I change the firmware back to using the VID/PID that I started with, and then connect the device to my development PC, it shows up in Device Manager under "Other devices" with an error icon. I think this is because my (Windows 10) development PC previously had seen this VID/PID combo as having different descriptors, so it's getting confused by some bad cached stuff.
I've tried using regedit to delete the device's registry keys under HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy, but the problem persists. (Also, I get an error, because it can't delete the VID_xxxx&PID_yyyy\zzzzzzzzzzzzz\Properties subfolders.) I also tried using USBDeview to uninstall old iterations of the device, but that hasn't made a difference either.
Also of note is that I can no longer pass the device through to Virtual Box virtual machines. I'm not sure what happened there.
Try removing any relevant registry keys of the form:
HLKM\SYSTEM\CurrentControlSet\Control\UsbFlags\vvvvpppprrrrr
The MSDN article Microsoft OS Descriptors for USB Devices says:
The operating system creates a registry entry, named osvc, under this registry key that indicates whether the device supports Microsoft OS Descriptors. If the device does not provide a valid response the first time that the operating system queries it for a Microsoft OS String Descriptor, the operating system will make no further requests for that descriptor.
I know the OP has resolved his issues, but for future reference for anyone else having this problem: I had similar issues while developing a USB device with a vendor-specific class. Specifically, (similar to your experience) I was unable to delete the keys from:
HKLM\SYSTEM\CurrentControlSet\Enum\USB\VID_xxxx&PID_yyyy,
so I had to increment the PID every time I modified my device code.
The reason why these keys can't be deleted is that the Properties registry subfolder is owned by the System user, so even running as Administrator you can't delete this subfolder nor change its permissions.
Running Regedit via PsExec (which is part of the SysInternals suite from Mark Russinovich) from an elevated command prompt with: psexec -s -i regedit.exe runs regedit as System user, which means you can delete that pesky Properties subfolder and the parent VID_xxxx&PID_yyyy keys.
I'm confronted with the same issue and uninstalling the device did not help.
Messing around with the registry makes me feel uneasy.
I still don't see a real answer to question #3.
What worked in my case: open device manager, select the non-working device and do "update driver". Select the driver manually from the list of locally available (Microsoft) drivers.
This did not solve all my problems but at least Windows does not ignore my device anymore and I can continue developing.
EDIT: I found a very helpful description on a github project named WCID Devices by Pete Batard. I strongly recommend reading the section Implementation and the following on this page WCID Devices
there are tools for removing hidden traces of USB devices like USBOblivion http://www.thewindowsclub.com/usboblivion-remove-usb-traces-windows , USBDeview,...
sources of USBOblivion are here: https://sourceforge.net/projects/usboblivion/ (https://www.openhub.net/p/usboblivion)
http://www.techerator.com/2010/05/how-to-remove-hidden-duplicate-copies-of-usb-device-drivers-in-windows/
To Remove TrustedInstaller Owned Registry Keys
Unfortunately the old PsExec trick of running RegEdit doesn't always work. In that case try to use:
ExecTI - Run as TrustedInstaller
Run it to open the ExecTI GUI and enter: C:\Windows\regedit.exe
To repair file and registry permissions
You can also try using the very old tool: subinacl.exe
Example:
subinacl.exe /subkeyreg HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Enum\USB\VID_0000&PID_0002\
Further described here. And has been shown to still work on Win10.
Related
On your computer, when you connect a USB device such as a camera, you get a pop up saying "Installing drivers please wait" or something along those lines. It runs the driver EXE file without requiring any permission from the user and without having the AutoPlay feature enabled.
I have a USB Key with 4gb of storage and I would like to let the same process happen to it upon inserting it, but using an EXE file I created instead of a real driver. (The file I created isn't in anyway harmful to the PC)
How I would want it to happen:
USB key is inserted to PCs USB port
Windows finds a required driver on the USB key
Windows runs the .exe
The fake driver carrys out it's duties on the PC
The .exe I have created is called "start.exe". It is a exe which was converted from a batch file which contained commands that do the following:
Deactivates muted volume
Sets volume level to highest value possible
Opens Google Chrome and Internet explorer on various different videos from the internet
The reason I want to do this is because the PC the USB is inserted into may not have Autorun enabled and therefore it won't run the autorun.inf I have placed in the USBs storage which also runs my "start.exe"
Any help is appreciated:)
This is probably a pretty easy question to answer for someone that is experienced with FS minifilters. I am trying to script the removal of a filter driver and device.
Some background... this driver is running on Windows 8/10 x64. The vendor that created the driver has not been helpful in fulfilling my request for a removal tool. Unfortunately their MSI uninstall is buggy and only works about half the time you run it... They want us to upgrade to their newest version that doesn't have the bug we are encountering during uninstallation. We aren't interested in continuing use of this software so a paid upgrade seems frivolous... Their only suggestion has been to reimage the computers without the software that includes the FS minifilter device... That's out of the questions because it is on 1000+ computers...
Basically, their official uninstaller does an API callback to one of their servers and verifies the machines eligibility to uninstall:
Does the MAC address of the primary network adapter exist in their
database?
Does the password you entered for uninstallation match
what is set in their database?
If you are eligible, it runs an MSI uninstallation and disables the FS filter, removes the driver file, service files, configuration, and restarts... The bug that is keeping us from doing a normal bulk removal (their way) is that the MSI freezes during the removal process (after checking eligibility) and requires us to restart a client computer up to 3 times to finish the uninstall.
I have been able to successfully remove the software and device/driver by externally mounting the Windows file system and manually removing the driver file under System32/Drivers and also removing all of the actual program files/services. I have not been able to do this booted onto the same partition where the minifilter is loaded. The minifilter driver that is running is protecting those program files, a registry key, and the actual .sys file under System32...
I've done some basic reverse engineering of their MSI... They are using custom actions to perform the removal... First step is the removal of the service, second step is the removal of the minifilter. Both actions are done via an executable that is packaged in the MSI... I've extracted that and attempted to use it by running the same commands that they do during the MSI... I haven't had any luck. The minifilter just doesn't want to die.
They have some other custom actions that are loaded via DLL. Initial investigation makes me think its all of their custom uninstall eligibility craziness.
It looks like their minifilter doesn't have an unload routine built in. Using FLTMC I get this error attempting to detach and/or unload:
0x801f0010 Do not detach the filter from the volume at this time.
0x801f0014 Do not detach the filter from the volume at this time.
Does anyone know of a good way to unload a minifilter that is throwing those errors?
Try to kick out FltMgr.sys of the kernel by:
Renaming %SystemRoot%\sytem32\drivers\FltMgr.sys
Or changing HKLM\SYSTEM\CurrentControlSet\Services\FltMgr\Type to 0x4 (Disabled)
Reboot
Minifilters can't work without Filter Manager.
If you are desperate enough, look into Windows PE, available as part of the Windows Assessment and Deployment Kit.
A Windows PE image can be remotely installed onto a machine's hard disk and configured to perform whatever task you need done and then automatically reboot back into the original operating system. Doing it this way gives you the same access as externally mounting the infected file system, but can be automated. I've used this approach in the past to automate offline maintenance tasks on several hundred machines (e.g., changing a registry setting that Symantec Endpoint Protection was "protecting") and while getting it working is fiddly, once it is working it works well.
My email address is in my profile, you're welcome to contact me if you decide on this approach and have questions about implementing it.
Alternatively, depending on your jurisdiction and circumstances, you might want to consider threatening the vendor with a lawsuit if they refuse to provide a proper solution. They broke your computers, it should be their job to fix it. From the sounds of it, they wouldn't even need to do any work, just let you have the upgraded version for a few weeks free of charge.
I am trying to check if drivers are installed for a particular USB device as part of an installation process. Unfortunately the manufacturer has several different installers for the same driver and there seems to be no consistent place in the registry to check if the driver is installed. However it's obvious that Windows must know if a driver is installed for a given USB device ID (Eg VID and PID) and I presume this is recorded in the registry?
How can I check to see if the driver is installed only by querying the registry, without relying on looking for installer-specific keys such as references to the uninstaller (which is unreliable) or calling Windows API functions?
Don't query the registry. There's no documented location for this, and it changes. Definitely between versions, possibly with service packs.
The proper way is to use Windows API functions, and it's unclear why you would reject this solution.
I faced the same Problem as you as I wanted to check in Installshield if a device driver was already installed.
I first tried the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ path as mentioned in USB Device Registry Entries, and it worked on 2 Windows 10 systems I tried but on a 3rd System it was not located here anymore but in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceMigration\Devices\USB\, I assume it has with a Windows 10 update to do but I am not sure…
I finally found out, that on all Systems I was able to find the VID/PID text (in my case VID_0483&PID_DF11) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class, which is pretty much what people programmatically do here .
Anyway as MSaters suggested I would rather use a C# Windows query like System.Management.SelectQuery query = new System.Management.SelectQuery("Win32_SystemDriver"); (see How to check whether a driver is installed?) as I am not sure, that the registry query allways work but it is in my case not possible.
Edit:
I found out, that Windows creates the registry entry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ as soon as the device is connected, even without drivers installed, that means that it is an incorrect way to check if the driver is installed.
There is another way though, the registry entry contains "VID_XXXX&PID_YYYY" then a "SERIAL" as subfolder, in my case (VID=1FC9, PID=000C, SERIAL=ABCD) \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1FC9&PID_000C\ABCD, you can then check the presence of an entry called Driver, it seems like it is only created after you install your Driver.
And for some reason the entry to look for under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceMigration\Devices\USB\VID_1FC9&PID_000C\ABCD seems not to be Driver but DriverInfName
I have a removable device setup so it autoruns when plugged into a Windows machine and pops up a message giving the owner's information, so it can be returned if lost. Is there a way to do this in Linux as well? It doesn't need to be complex, it can be an option in a right-click menu, or a splashscreen, or anything.
No. Unlike a default installation of Windows, which looks at Autorun.inf and automatically executes a specified program (or at least asks whether the user wants to run the "default action"), no distribution of Linux does this. Any autorun-like feature upon inserting a USB device on Linux must be explicitly set up by the user.
By the way, the autorun "feature" of Windows can be disabled, and it frequently is disabled by security-conscious computer users.
I haven't understood well what you're trying to do, anyway I strongly suggest to use one of the APIs provided by dbus (expecially the hal service).
Though this approach is not immediate.
http://dbus.freedesktop.org/doc/dbus-tutorial.html
I guess you could just put a file in the root directory called README_Owner_Identification.txt. That way people using certain desktop environments would see the filename when the file browser popped up in response to a USB device being automounted. If I recall correctly, both GNOME and KDE will do this by default.
Of course, people would still have to open the file to see the info, and it wouldn't work on systems that have the settings changed, but it's probably your best option. Anything else would require that people engage in some thoroughly insecure system reconfiguration just to see your ID.
I have an application for Windows XP. This application is deployed with the hardware. The application is the only application that ever runs on these machines. These machines are never connected to the internet. I'm interested in instant-on (or quick-on) options that bypass the Windows XP startup for these machines.
This is similar to Windows XP "hibernation", but not exactly. With hibernation, the memory state is only read from disk once - the very next time the system is turned on. I want a memory state permanently stored to disk, so the system always starts from that same spot every time, regardless of how it was shut down. How can I achieve this?
Sounds like you're looking for the Hibernate Once, Resume Many feature of Windows Embedded.
If you like "hibernation", you may use VMWare.
Install a ArchLinux and VMWare on the host machines.
Prepare your Windows XP as the guest OS.
Customize startup process of the host, let it run VMWare and restore Windows to the snapshot.
Hmmm, the short answer is "not easily!", but one way could be to try playing around with replacing the windows shell with your own application / script that launches your own custom interface / state instead of Explorer as the default. Basically it's done using this reg key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\shell
Info on this actually seems to be reasonably scarce after doing a quick Google search, but this link below provides a little more detail:
http://www.trap17.com/index.php/how-change-windows-xp-shell_t20367.html
I think if you do a Google Groups search on "Windows XP shell replacement" you might get some more informative results.
You could try installing TweakUI on them, and having them autologin. Once you do that, just add your application to the Start Up menu (or in the registry, under:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
Jeff Atwood has a post on this very thing.