How do you disconnect a Bluetooth device in a Windows driver so that Windows doesn't lose it's pairing? - windows

I'm currently working on a Windows driver for Nintendo Wii remotes and I want the PC to be able to disconnect the device without removing it's pairing. I know this behavior exists since my mouse is capable of doing it. What I want it to do is, when looking in Devices and Printers, the device should show as grayed out when off/out of range. Unfortunately I can't find any documentation on how to do this, either because I don't know what this exact behavior is called or because it's never clearly stated in the documentation. Does anyone have any idea how this is implemented?
EDIT: Realized this was probably not a Bluetooth specific feature since printers also make use of this and removed the Bluetooth tag.

Related

Force bluetooth legacy pairing in Windows 7

I recently acquired a Bluetooth headset (Philips SHB9100) for my smartphone, but also wanted to use it with my Windows 7 PC, so I bought a cheap USB Bluetooth adapter without noticing it was a v2.0 adapter, while the headset is v2.1 + EDR.
The USB Adapter installed correctly on Windows 7, and I am able to discover my headset, but when they try to pair, an ugly Error 0x80004005 appears, never asking me for a PIN.
After some googling, and founding many people had this pairing problem, I read that the major improvement in Bluetooth v2.1 is SSP, which permits pairing without the need to enter a PIN, and also that Windows 7 chooses the "best pairing mechanism" automatically. And so I started to suspect that this is what's happening:
Windows discovers a SSP capable device.
Windows tries to pair with that device using SSP.
The USB Adapter, being v2.0, is unable to permit pairing with the headset via SSP.
Windows does it's best showing a 0x80004005 error.
I searched for a v2.1 or superior USB Bluetooth Adapter in my city but couldn't find any (I'm from La Plata, Argentina) and even though I think I'll end buying one, I'd like to make this work, or at least know for sure why the devices aren't pairing.
And so my question is (and I swear I did some more googling before asking here):
Can I force Windows to try a legacy pairing with my headset?
Any info on the subject is welcome.
Thanks!
I recently faced a similar issue and after a lot of trial and error together with research, I finally fint a compatible driver. I downloaded a few drivers from the intel site and tried it with each one of them. Finally I was able to fix my issues with the driver below.
https://communities.intel.com/thread/103579
https://downloadcenter.intel.com/download/26191
This link can also help with the issue, worth sharing.
https://superuser.com/questions/471767/bluetooth-headset-pairs-and-appears-in-sound-devices-but-shows-as-disconnected

Is there any way Not to detect USB from windows PC?

Is there any way Not to detect USB from windows PC?
The USB device should not mount on windows PC ,It should be handled by my application..
Suggestions please...
As far as I know there is no way of stopping the mount on the windows PC, however, you could set it up to autorun so that when it is plugged it in attempts to launch your application. This answer has some information on how to do this: https://stackoverflow.com/a/255067
There is also the option to hide a drive in windows by removing is drive letter (http://www.howtogeek.com/97203/how-to-hide-a-drive-in-windows-so-that-no-one-will-know-its-there/) however, this is almost certainly going to stop your application from reading it too.
If this is for a specific security reason then perhaps you could look at encrypting the drive and allowing only the application to decrypt the data. Thus, whilst mounted in windows it will be of little use.
Sorry I couldn't be of much more help.
Microsoft provides a utility called devcon for free download.
It's a "Command Line Uility Alternative to Device Manager".
It can actually do many things that I won't get into here, but removing a plug & play device is a simple operation once you know the unique name of the device you want to manipulate.
Refer this to check how to work with it.
It sounds like you don't want your device to show up as a drive in My Computer. In that case, why are you using the Mass Storage Device class at all? You could make a custom, vendor-specific device and talk to it using control/interrupt/bulk transfers with WinUSB. You would need to change the Device's USB descriptors to indicate it is a vendor-specific device and not a mass-storage device.

WiFi NDIS driver does not appear in the WHQL ndistest device list

I maintain an NDIS 6.0 native WiFi driver. One of my missions is passing a WHQL test. To that end I installed version 1.6 of the Windows Logo Kit. I also installed my driver on a a Windows 7, 32-bit test machine. The device appears in the device manager and works correctly.
As a first step I tried to pass the stand-alone NDIS test. However when I run ndistest.exe, the device does not appear in the list of devices. The following screenshot demonstrates the problem:
My device should have appeared in the 'Support Devices' list, or in the 'Test Device' drop box, but it fails to appear in either.
Can someone point out what may cause a device to not appear in these lists?
Thanks!
Well apparently we forgot to implement a couple of obligatory OIDs. If you encounter this problem, make sure that you implement all required OIDs.

How should I get ActiveSync / Mobile Dev Center to recognise my Windows CE device via USB?

We develop a custom Windows CE-based device. To connect this to the PC via ActiveSync / Mobile Device Center, we have to set up entries so that the WCE USB Serial Host (wceusbsh.sys) recognises our Vendor ID (Vid) and Product ID (Pid).
To do this, to date, we have distributed a modified version of wceusbsh.inf and wceusbsh.sys: when the user first connects the device then ActiveSync basically says it does not recognise the device, and the user is asked to identify a driver for it. If they now point at the location where they've stored our wceusbsh.* files then all is well. However this is pretty clunky.
What we really want is a slick way to do this, preferably by running an installer which just gets everything ready, so that as soon as the device is plugged in it is recognised by wceusbsh.sys.
Any clues how to do this? There seem to be a ton of registry entries which relate to WCEUSBSH, and it's not clear how these are set: just "installing" the .INF file doesn't seem to allow for setting them all, so it does look like ActiveSync reads the .INF file and then adds some more information before appending the new info to the Registry.
Thanks
Well, in case anyone else comes looking for an answer to this, we managed to do it via this link from MSDN WinUSB (Windows Driver Kit). We now have a driver install program which sets up USB / Mobile Device Center so that when you plug in the CE device it is recognised correctly.

How do I reset USB devices using the Windows API?

Do you know a way to use the Windows XP API to reset the USB bus? In other words, I'd like the OS to kick out any USB devices that are currently connected, and then auto-detect everything anew.
I'm aware of devcon, and I suppose I could do system calls out to it, but I'm hoping for a direct call into the API.
From kernel mode: You can force a specific USB device to be re-connected, as if it was unplugged and replugged again, by sending an IOCTL_INTERNAL_USB_CYCLE_PORT to its PDO. (This can only be done from a kernel mode, e.g. through a helper driver.) This 'cycle' operation will cause a USB reset to occur, after which the device would be re-enumerated. For example, if the device comes back with a different USB device descriptor, a different driver may be matched for it.
From user mode: You can do this by ejecting the device through the CfgMgr API. For example, to go over all USB hubs and eject all devices:
Find all devices having device interface GUID_DEVINTERFACE_USB_HUB with SetupDiGetClassDevs(... DIGCF_DEVICEINTERFACE).
Enumerate over the returned device information set (SetupDiEnumDeviceInfo).
For each device, get the DevInst member:
Invoke CM_Get_Child(DevInst) and then CM_Get_Sibling repeatedly to go over all child nodes of the hub (i.e. the USB devices).
For each child node, call CM_Request_Device_Eject.
Well, use can use the Setup API (SetupDiXXX functions) to enumerate the USB devices in the system, and then call WinUsb_ResetPipe on each one, but I'm not sure if that's what you're looking for. It's been a while since I worked with USB devices, but as I recall, there is no standard way to reset a device (i.e. simulate a power off/power on cycle). If it's possible for a particular device, you'd have to send an appropriate IOCTL (using DeviceIOControl) to the driver. The IOCTL would vary from manufacturer to manufacturer.
It's possible to cycle the parent port on the USB hub the device is attached to, as well. This will result in, among other things, apparrent unplug/replug actions, as you will see a balloon popup when this occurs.
Much of this is poorly documented, and honestly, I've gotten the impression there are only a handful of people at Microsoft who really understand it well. The design decision I've made for future devices I design is that I intend to include watchdog functionality on both sides, as well as a device-side full reset function. That way, if the device figures out it is confused, it can just cut its own power for a second and fully reset, if the host can't communicate with it, it could do the same thing, and if the device thinks everything is fine but the host knows better, the host could order it to reset.
There are at least three APIs worth looking into for this problem: the Setup API, the Config Manager API, and various WMI extensions. However, be cautious about diving into WMI if you intend to use an Embedded XP target, as you will have to include a lot of other things in your OS image you might otherwise not need.
As far as I know, there is no way to do this - you can issue a command to have PnP rescan the bus for new devices, but that isn't the same as issuing a bus reset.
Furthermore, just because from a hardware perspective you issued a bus reset doesn't mean that Windows will remove the PDOs that represent the children of the hub and redetect them; the USB bus driver can (and does) do just what I describe (i.e. issue hardware bus resets without disturbing the device tree), and only after the device doesn't respond does it issue the surprise removal and yank it from the tree.

Resources