|
Edited by lemoutan at 2016-7-19 17:42
THanks for that. It's good to know that it will work in Win7-64, so one can be reasonably confident that there is a solution and that one is not wasting one's time trying.
Which particular architecture section of the inf file applied, in your case?
- [DSTDSO.Files.Ext]
- dstusbx86.SYS
- [DSTDSO.Files.Ext.amd64]
- dstusbamd64.SYS
- [DSTDSO.Files.Ext.I64]
- dstusbia64.SYS
Copy the Code
Obviously not the (default) x86 - so is your machine an amd64 or an I64?
As for your rather amusing suggestion that I replace my entire computer because one particular company's drivers are problematic, unless you have a machine for me which I can devote to the 'scope then I think I'll try other avenues first.
For instance I think there's some software knocking around that allows you to 'correct' the vendor/device from 0/0 to (as your inf file shows) 049F and 505A but that may only work for a specific device. Something to do with sigrok? Can't remember. There's also something about disabling windows 7 driver signing checks.
Anyone else can jump in here?
(Later that same reply ...)
I noticed that your picture2.jpg has the device driver in as a completely new windows device class (i.e. Measurement Device) which is completely different from mine which is just getting itself installed as an unspecific USB device within the existing windows device class of 'Universal Serial Bus Controllers'. As long as it keeps installing itself in that branch then I can't see how it's going to create the new Measurement Device class (with its own ClassGuid) - which is of course not already extant on my machine. Is it possible that the inability to create the correct class might be due to an existing, earlier, device of yours (i.e. the Hantek 6022BE - which I still have installed) which uses the same dstusb*.sys driver?
|
|