Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 9 April 2018

Writing WDF Drivers I: Core Concepts, Manchester, NH, 7 May 2018

Kernel Debugging & Crash Analysis for Windows, Manchester, NH, 21 May 2018


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 10  
11 Apr 18 13:05
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11894
HLK Change for Camera People

I posted some weeks ago about a non-UVC USB camera we have that has passed WHQL several times before, currently passes HCK for Windows 7 and 8, but fails HLK for Windows 10 with an "interface not found" error inside the test code.  I'm currently 14 very frustrating days into my attempt to get Microsoft's tech support people to treat me as something other than an idiot, a battle that I do not recall fighting the last time I submitted a support incident. One of the tidbits that just came out of that exchange is that in the RS4 release (1803), they plan to require that all USB cameras use the UVC driver (usbvideo.sys).  I'm amazed this is being attempted again.  Microsoft tried to enforce that restriction 8 or 10 years ago, but were forced to revoke it after industry backlash.  Nothing has changed since then.  There are still many, many USB cameras in the industrial control world that are not UVC compliant.  Part of that is because of requirements that do not fit neatly into UVC, but part of it is that the industrial control world changes very, very slowly.  I'm still supporting, testing, and certifying drivers for devices designed in 2006, before there was good UVC support in camera chips, and those cameras are still being sold into new installations. So, if any of my colleagues are doing non-UVC USB cameras, now is the time to speak up. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 2 of 10  
11 Apr 18 16:49
Tim Chan
xxxxxx@gmail.com
Join Date: 24 Feb 2017
Posts To This List: 9
HLK Change for Camera People

Hi Tim, Thank you for going through the painful process of MS tech support and keeping us up to date with your findings. My company produces USB cameras with proprietary USB device drivers, so we are very much interested in the points you're bringing up. I'm not sure what next steps to take as one of the non-UVC USB camera people, but I just wanted to answer the rallying call. So far we have been running HCK signing only for our drivers, as HCK signing still appears to validate the driver for use on Windows 10 machines, at least as new as Build 10586. But the RS4 release changes and the enforcing of their UBC driver on our devices would impact our products significantly. Tim
  Message 3 of 10  
13 Apr 18 13:50
Eric Gross
xxxxxx@ni.com
Join Date: 02 Mar 2009
Posts To This List: 6
HLK Change for Camera People

Hi, Can you elaborate on what your affected device actually is? Is it a camera using the USB Video Class but you want to use your own driver matching by VID/PID? Are you trying to hook it into the DirectShow layer? If you are just a USB camera device that doesn't use the USB Video class ID nor tries to hook into DirectShow, I don't see how Microsoft would treat it any differently than any other custom USB device. There would be no way for them to even know it is a camera from the USB device descriptors or the INF file. This is how industrial USB cameras typically operate, so I don't see how they could be affected by a change that you describe. Eric
  Message 4 of 10  
13 Apr 18 14:39
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 6130
List Moderator
HLK Change for Camera People

<quote> If you are just a USB camera device that doesn't use the USB Video class ID nor tries to hook into DirectShow, I don't see how Microsoft would treat it any differently than any other custom USB device </quote> Entirely correct. Because, it IS a custom USB device. It's an Industrial Control Peripheral, an Industrial Vision Controller, and not a camera at all. And it should not be WHQL'ed as a camera. If you WHQL it as a camera, then people have the right to expect it to work like a camera in their commodity system. And that's not what it does., Peter OSR @OSRDrivers
  Message 5 of 10  
13 Apr 18 15:54
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11894
HLK Change for Camera People

xxxxx@ni.com wrote: > Can you elaborate on what your affected device actually is? Is it a camera using the USB Video Class but you want to use your own driver matching by VID/PID? Are you trying to hook it into the DirectShow layer? No, the device is not USB Video Class.  It is in vendor class, but the driver is in Class=Image or Class=Media. > If you are just a USB camera device that doesn't use the USB Video class ID nor tries to hook into DirectShow, I don't see how Microsoft would treat it any differently than any other custom USB device. There would be no way for them to even know it is a camera from the USB device descriptors or the INF file. This is how industrial USB cameras typically operate, so I don't see how they could be affected by a change that you describe. It's not clear what you mean by "hook into DirectShow".  They can't tell anything from the descriptors, but the driver is an AVStream driver, specifically so it can be used through DirectShow.  It's the deadly combination of USB and Class=Image that, apparently, will be a trigger for WHQL. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 6 of 10  
13 Apr 18 16:50
Eric Gross
xxxxxx@ni.com
Join Date: 02 Mar 2009
Posts To This List: 6
HLK Change for Camera People

Hi Tim, Thanks for the clarification. I'm a bit unfamiliar with the video software layers (AVStream) under Windows, so I think my terminology was a bit off. I'm most familiar with USB3 Vision, which has a defined USB sub-class under Misc (EF 05). This is commonly used by industrial cameras. Typically the vendor provides a driver that works with their own API to configure the camera and retrieve images (there is another use case with class drivers provided by another vendor, but ignore that for now). Often they also provide some sort of software filter driver that "hooks into DirectShow" (forgive my terminology, again) as a filter driver to provide compatibility with DirectShow applications. Thus, their main driver is not an AVStream driver or listed as image or media class in the INF. Would splitting your driver into a USB driver plus a filter driver be a reasonable workaround? I don't know any particular downsides on this approach, but I do know that this is the route most of the vendors delivering USB3 Vision devices take. It may have some historical reasons since many vendors also ship similar GigE Vision devices, and those don't typically have a standard kernel driver associated with them since they just talk over UDP. Eric
  Message 7 of 10  
14 Apr 18 01:18
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11894
HLK Change for Camera People

On Apr 13, 2018, at 1:49 PM, xxxxx@ni.com <xxxxx@lists.osr.com> wrote: > > Would splitting your driver into a USB driver plus a filter driver be a reasonable workaround? I don't know any particular downsides on this approach, but I do know that this is the route most of the vendors delivering USB3 Vision devices take. These cameras were designed in 2006, and the driver is common to about 20 different camera front-ends. They are still being sold, but it is quite unlikely that the vendor is going to redesign their software stack at this point, just to satisfy an arbitrary and seemingly pointless rule created by WHQL. They'll just have to tell their clients to complain to Microsoft. ??? Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
  Message 8 of 10  
16 Apr 18 11:59
Eric Gross
xxxxxx@ni.com
Join Date: 02 Mar 2009
Posts To This List: 6
HLK Change for Camera People

Yeah, MS's support when you hit seemingly-bogus WHQL limitations is pretty terrible... Good luck.
  Message 9 of 10  
16 Apr 18 14:55
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 6130
List Moderator
HLK Change for Camera People

<quote> It's the deadly combination of USB and Class=Image that, apparently, will be a trigger for WHQL. </quote> Sorry to be sorta "limited" here... but if you're making the device, and you're gonna use custom drivers anyways, wouldn't you just make it USB and Class = FF and be DONE with it? It's an *industrial* vision device, not a "camera" per se. I apologize if this is a silly question. But I would appreciate it if you would enlighten me. Peter OSR @OSRDrivers
  Message 10 of 10  
17 Apr 18 13:38
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11894
HLK Change for Camera People

xxxxx@osr.com wrote: > <quote> > It's the deadly > combination of USB and Class=Image that, apparently, will be a trigger > for WHQL. > </quote> > > Sorry to be sorta "limited" here... but if you're making the device, and you're gonna use custom drivers anyways, wouldn't you just make it USB and Class = FF and be DONE with it? > > It's an *industrial* vision device, not a "camera" per se. > <...excess quoted lines suppressed...> Exactly.  That's what it is.  If I call it "video class" in the descriptors, then I'm saying I conform to UVC and I get what I deserve.  Instead, we use Class=FF. The issue is that my custom AVStream driver specifies Class=Image in the INF file, which is the only way I can be recognized as a capture driver.  The WHQL testing apparently sees that "this is a capture driver that drives a USB device", and that is apparently the combination they intend to prohibit. But, you know, now that you have pointed this out, this does seem like a totally unreasonable restriction.  I wonder if perhaps my support incident contact (who after 20 days has STILL not offered me any suggestions or advice) does not understand the situation. -- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 08:25.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license