Dbt-122 Drivers Windows 10

[Pang Murdock]

Onequestion that regularly arises here, is whether something like KernelEx exists for drivers (or indeed, whether KernelEx can help with driver compatibility). Occasionally, 'WdmStub' is mentioned as a possibility, eg. by dencorso here :

Now, 'WdmStub' is a "sample/example" filter driver that was/is included in Walter Oney's book, "Programming the Microsoft Windows Driver Model". Note that 'WdmStub' was originally written as a VXD driver, and you can find a link to this version at the Internet Archive, as posted by dencorso here :

BTW, the licensing of 'WdmStub' basically says that you need to ask Walter Oney for permission to redistribute it and that he will grant this subject to some non-monetary conditions to ensure the quality of the end result.

You also need to add 'wdmstub.sys' to the section invoked by the "CopyFiles=" directive or manually pre-copy it to the same destination directory as "yourdvr.sys" (possibly "c:\windows\system32\drivers").

I wasn't aware there was both a production and a debug build of 'wdmstub.sys'. Well, I may as well try the production build (unless some debugging is needed, in which case, I'd have to learn how to do such debugging).

I've attached the inf from the Garmin GPS (one of the products using it), taken from their driver, as a further example of an working installation of wdmstub.sys. I've also included an inf taken from a SoundMAX audio driver, which also uses wdmstub.sys, albeit it's a more complicated example.

@jds: The Garmin drivers also contain a release version of WDMSTUB.SYS v. 5.0.0.6, but its PE Timestamp shows it's a complation less than one year earlier (and about 1 KiB smaller) than the one in NUSB3.0e, which AFAIK is the latest one available. The SoundMAX driver contains a WDMSTUB.SYS v. 5.0.0.4, which is not relevant, unless for study purposes. However it shows how to get WDMSTUB.SYS permanently loaded, by using it as a lower filter for a device permanently present, such as the onboard soundcard. This approach could be applied even for soundcards not needing WDMSTUB, just to get it permanently loaded, but cannot be generalized: one has to identify a suitable dispositive device in one's own machine and modify the apropriated inf. by hand, on a case-by-case basis.

So despite the description at the MS download page, this SYS file looks to be for Vista, not XP. I don't know the compatiility of Vista drivers on XP. However, for Vista, the "recommended" driver model is "Kernel Mode", whereas what we're interested in is "Windows Driver Model", which is (98)/2000/XP. I don't know what the actual difference is between the two driver models, but suspect this is what is confusing/crashing 'WdmCheck'.

@jds: The Garmin drivers also contain a release version of WDMSTUB.SYS v. 5.0.0.6, but its PE Timestamp shows it's a complation less than one year earlier (and about 1 KiB smaller) than the one in NUSB3.0e, which AFAIK is the latest one available. The SoundMAX driver contains a WDMSTUB.SYS v. 5.0.0.4, which is not relevant, unless for study purposes. However it shows how to get WDMSTUB.SYS permanently loaded, by using it as a lower filter for a device permanently present, such as the onboard soundcard. This approach could be applied even for soundcards not needing WDMSTUB, just to get it permanently loaded, but cannot be generalized: one has to identify a suitable dispositive in one's machine and modify the apropriated inf. by hand, on a case-by-case basis.

Anyway, can you please explain what you mean by "one has to identify a suitable dispositive in one's machine and modify the apropriated inf. by hand"? I can't quite figure it out. I figure "apropriated" should probably be "appropriate", but "dispositive" is a very obscure word (and I was none the wiser after looking it up).

Yes. I know of at least 3 builds of v. 5.0.0.6, with different PE Timestamps. Of course, any of them is more up-to-date than v. 5.0.0.4, of which I know of just one build, the one that comes with the SoundMAX drivers.

Sorry! I'm a native speaker of Portuguese, and despite my best efforts at expressing myself clearly in English, it sometimes shows. By "dispositive" I intended to mean gadget, gizmo, resource, device, but that's a meaning "dispositive" has in Portuguese, not in English. They are "false friends". So I was thinking about an onboard soundcard, or an onboard modem, or perhaps even an onboard graphics card... in any case, something that uses a WDM device driver, but which does not necessarily need WDMSTUB.SYS, and which cannot be removed, so that once the driver is loaded it also loads WDMSTUB.SYS, and it never gets unloaded, because the device cannot be removed. My own board uses the SoundMAX driver, so I do have WDMSTUB.SYS loaded all the time. But I'm talking of using any WDM driver, even one that doesn't actually need WDMSTUB.SYS, just to load it in memory and have it remain there.

Anyway, what is it in 'smwdmVI3.inf' which makes it different, "never unloaded"? I looked at the INF file, which is somewhat large and complex, but couldn't figure it out. Also, what advantage does this bring?

Nothing is different in the .inf. The fact that the sound card cannot possibly be removed while the system is running is what makes WDMSTUB.SYS remain always loaded. The thing is in the WDM model itself. While VxDs can be created to be unloadable, they can also be permanent. WDM drivers usually are unloadable (and I'm not sure whether they can be caused to be permananent, probably so, I would have to study this question some more). But, when one loads, as most of us do, WDMSTUB with USBSTOR, it'll only be loaded when a pendrive (or other USB Mass Storage device) is inserted, and then will be unloaded when it's removed. PROBLEMCHYLD and I just faced a situation where this can be a problem (well, sort of...) because the newer USBSER he adopted needs WDMSTUB. So, the situation created by this is the following: when one inserts a USB Mass Storage device, WDMSTUB is loaded, when one inserts another USB Mass Storage device, WDMSTUB is loaded again, and if, then, one inserts a USB Serial device, WDMSTUB is loaded yet again, and so on. This is harmless, but eats memory, so I think it would be nicer if we could avoid it. Now, in my machine, in which WDMSTUB gets loaded during start-up (by the onboard sound card, thanks to smwdmVI3.inf) and remains in memory, I found out I can omit WDMSTUB as a lower-filter for both (in the .infs), *because* it aready has been loaded by the SoundMAX driver, and provides the needed stubs for everybody else. So, it's more a question of saving memory and avoiding multiple, albeit harmless, loadings of the same lower-filter. Of course, the SoundMAX driver comes with an older version of the WDMSTUB.SYS, so I've just updated it to the newest version and compilation of it I know of. A more general solution, one that involves some intensive programing, but is general, would be to convert the current WDMSTUB.SYS back to VxD (and have it loaded from SYSTEM.INI).

3a8082e126