How to prevent hardware detection of USB input devices?

Unanswered How to prevent hardware detection of USB input devices?

  • Tuesday, August 21, 2012 4:45 PM
     
     

    Hi all,

    We've got a problem using our USB devices on WES7.

    Devices are recognized as USB Input Devices and work properly. No need of additional drivers.

    But when we plug device in to the target "Restart system" dialog appears ("Restart now" or "Restart later" buttons). We can push "Restart later" and continue working. But on next boot we're getting the same since we use HORM. Also we can disable this dialog using Dialog Filter. But it is not suitable because anyway device detection takes some time before we can operate this device.

    Is it possible to pre-install devices or are there any registry keys to ignore device detection as it was on XPe (it is possbile to set IgnoreHWSerNumXXXXYYYY in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags, where XXXX is VID and YYYY is PID)?

    TIA

All Replies

  • Tuesday, August 21, 2012 7:04 PM
     
     

    what you want to use is:

    group policies (gpedit.msc): computer/system -> admin template -> system -> deviceinstallation
    (don't know the real terms, because of localized version)


    Windows Embedded Developer and Scripting Guy //Germany (Preparing a blog about Windows Embedded Standard)

  • Tuesday, August 21, 2012 11:04 PM
     
     

    There is a solution to USB devices - http://www.annabooks.com/SW_SecureBus.html

    If the device is plugged in and is not on the exception list, you will not get the dialog because SecureBus blocks the port.

    -Sean


    www.sjjmicro.com / www.seanliming.com / www.annabooks.com, Book Author - Pro Guide to WES 7, XP Embedded Advanced, Pro Guide to POS for .NET

  • Friday, August 24, 2012 3:51 PM
     
     

    Thank you, guys, but it's not what I need.

    I want to pre-install a constant set of similar devices (standard USB Input Devices with standard Microsoft drivers) before hibernation (during WES7 installation and configuration, for example) ant don't know how.

    When I try Group Policies, devices are not detected at all and I can't use them.

    Third-party solutions don't suit.


    • Edited by RenatL Friday, August 24, 2012 4:06 PM
    •  
  • Friday, August 24, 2012 4:20 PM
     
     
    you're right. after secound reading you want to pre-install not to exclude. sry for that.
    not completly sure but you might want to try devcon.exe (in windows sdk) maybe it's possible to preinstall drivers.

    Windows Embedded Developer and Scripting Guy //Germany (Preparing a blog about Windows Embedded Standard)

  • Friday, August 24, 2012 5:16 PM
     
     
    I guess driver is already installed, because USB Input Device is a standard device that uses standard Microsoft drivers (input.inf, hidclass.sys, hidparse.sys, hidusb.sys).
  • Friday, August 24, 2012 6:21 PM
     
     

    If you know the set of drivers, then just add them to the image. What exactly is the issue?

    -Sean


    www.sjjmicro.com / www.seanliming.com / www.annabooks.com, Book Author - Pro Guide to WES 7, XP Embedded Advanced, Pro Guide to POS for .NET

  • Monday, August 27, 2012 2:41 AM
     
     
    the driver is provided. not installed/enumerated - you may can enumerate and integrate them with devcon in the system.

    Windows Embedded Developer and Scripting Guy //Germany (Preparing a blog about Windows Embedded Standard)

  • Monday, August 27, 2012 3:29 PM
     
     

    Hi,

    you may try to disable the "Shell hardware detection" service, but check out for unwanted side effects.

    Best regards,
    Willi K.

  • Monday, August 27, 2012 4:45 PM
     
     

    If you know the set of drivers, then just add them to the image. What exactly is the issue?

    -Sean


    www.sjjmicro.com / www.seanliming.com / www.annabooks.com, Book Author - Pro Guide to WES 7, XP Embedded Advanced, Pro Guide to POS for .NET

    They already are, since they are standard Microsoft drivers.

    When I plug my device in OS detects new hardware and starts new device installation. Every time, since we use HORM. It takes some time. And during this time I cannot use my device (issue #1). After a successful device installation I can use my device, but OS asks to restart now or later (issue #2).

    I want to pre-install my devices (I know VID, PID, etc.) during image preparation phase to resolve these issues. And I don't know how (there were some registry settings for XPe that are useless in WES7). 

    the driver is provided. not installed/enumerated - you may can enumerate and integrate them with devcon in the system.

    Windows Embedded Developer and Scripting Guy //Germany (Preparing a blog about Windows Embedded Standard)

    If it is in driver store (and it really is), does it mean that it was installed? Will try devcon, thanks.

    UPD: Devcon fails during device installation. And when I try to get a status using command "devcon status USB\VID_XXXX&PID_YYYY" it says that the driver is running and 1 matching device found. When I plug in my device and OS installs new device, it is found with the same HwID, but with new instance (something like USB\VID_XXXX&PID_YYYY\ZZZZZ). And needs restarting again.

    Hi,

    you may try to disable the "Shell hardware detection" service, but check out for unwanted side effects.

    Best regards,
    Willi K.

    Thanks, I'll try it.

    But I'm afraid, it will affect USB keyboard and touchscreen.

    UPD: "Shell hardware detection" service has been already disabled. So it doesn't help.

    • Edited by RenatL Monday, August 27, 2012 5:59 PM
    •  
  • Monday, August 27, 2012 7:49 PM
     
     
    is installing the devices and creating a new horm state absolutly no option?

    Windows Embedded Developer and Scripting Guy //Germany (Preparing a blog about Windows Embedded Standard)

  • Tuesday, August 28, 2012 11:08 AM
     
     

    You mean installing the devices first and go to HORM then?

    It is an option. But in this case we need to plug all our devices (about 30 types) in to every port one by one manually and then go to HORM.

  • Tuesday, August 28, 2012 6:20 PM
     
     

    i'm still going with devcon. you may should read the (hole) documentation. you might missed something (it's not just "devcon install xxx.inf)

    this bloody dirty workaround might work but is dirty as hell.

    install all devices on all ports (once). - trace all changes. export them (enum\usb hive) with system account (e.g. with psexec) and import them on a new image while fba.


    Windows Embedded Developer and Scripting Guy //Germany (Preparing a blog about Windows Embedded Standard)

  • Wednesday, August 29, 2012 3:41 PM
     
     

    Really dirty.

    Will try devcon more.

  • Friday, December 14, 2012 1:31 AM
     
     

    I have a very similar question, also with WES7.

    We have a single accessible USB port, that may occasionally have USB Flash Device, Keyboard, and/or Mouse connected.

    We initially configure the device with microsoft keyboard/mouse connected.  And we lock that configuration in with EWF.

    But later, the user might plug in a Logitech Keyboard or Mouse.  I don't care if THAT works or not.  I do not want windows to

    get bent out of shape trying to install a driver for it.  The driver installation causes timing troubles for a running application.

    So...how to kill the iinstalling driver business?

    • Proposed As Answer by MaxEntropy Friday, December 14, 2012 4:59 PM
    • Unproposed As Answer by MaxEntropy Friday, December 14, 2012 6:05 PM
    •  
  • Friday, December 14, 2012 5:47 PM
     
     

    The entire USB device alert popup system doesn't seem to work as advertised.
    Here is some discussion, some partial answers, and a new problem that I haven't found a resolution.

    The target device we are working on is medical device. The design has a touch screen for input and 3 USB ports that allow only USB flash drives to capture post surgery data files. Since, like most embedded devices, the OS must not be accessible to the user. So any popup alert dialogs must not appear and must be handled by the application SW.

    Dialog filters only work for the "KNOWN" dialog. So any unknown dialogs wouldn't be filtered.

    In System Services, we set the "InteractiveServiceDetection" = disabled. This did not prevent the popups. However, after setting Shell Hardware Detetetion = disabled, this did prevent the alert dialogs from appearing (Note. Works on next power cycle). The taskbar is hidden, and all the Notifications Area Icons are set to "Hide Icon & Notifications" and OFF. NOTE: The problem with this setup, is still ugly, since devices that show up on the Notifications Area Icons setting page must be known and installed to display, so that they may be disabled. This can then all be locked down by setting the EWF for the entire drive partition used for the WES7. All the specialized (non MS USB drivers are already installed prior to the EWF lock down).
    What was discovered, in the MS help files (maybe. don't remember where) is that the disable for Shell Harware Detection is a misnomer. It doesn't disable. It merely makes it invisible and allows for the default selection to occur(which might be why driver installations attempt). So the programmer must offer the desired response, other than the default.

    New PROBLEM: Our development is near complete and was tested with other conceivable USB devices that might be inserted. I tried printers, scanners (which show up as keyboard class), and everything seemed OK. HOWEVER, when I inserted a keyboard and mouse through an external hub into one of the ports, I once again got the annoying notification dialog. The text was, "unrecognized USB device". When I opened the Control Panel Notifications Area Icons setting page, this option switch now appears, however, after setting it to "Hide Icon & Notifications", it looked like it was set. However, when revisited during the same power cycle or the next power cycle, the setting did not persist. Yes, I did remember to disable the EWF before making the settings. This alert cannot seem to be hidden, which defeats the purpose. ...Any ideas on how to make this notification invisible.

    • Proposed As Answer by MaxEntropy Friday, December 14, 2012 5:48 PM
    • Unproposed As Answer by MaxEntropy Friday, December 14, 2012 6:05 PM
    •