What device manager selections in Windows Hardware Lab Kit (HLK) I should use for setting up WHQL for a windows filtering platform driver?
When I build my project in HLK I see many options in the Select (device manager) section and I'm unsure of how to proceed. Am I missing some additional file I'd load in to provide a WFP option? I see I can load in test playlists but before I do that I must first select something in this area.
Microsoft docs don't seem to cover this for WFP. Before I go back to the developers, I'd like to have a good idea what it is I'm looking for.
Do you know of good documents or references on this?
Thanks
The UI for HLK studio can be challenging.
In selection, do not choose device manager as this is for hardware. Instead, select software device. Provided you installed your driver prior to installing the client, you should see it.
Related
I'm very new to windows driver development.
I've written a KMDF windows driver and I'm able to test deploy it to my target machine using VS deploy. It worked fine and now I'd like to ship this driver with the application that uses this driver.
Here the problem comes... I couldn't find anything on Google that telling us how to distribute a KMDF driver(like making an installer). This driver is an upper class filter driver and it is only needed for my application so it should not be published to windows update.
My question is how to make something like an installer to distribute this driver? Thanks for any suggestion or tutorial.
EDIT 1
It is a fake device driver(meaning there is no physical device to drive)
Usually, device drivers for software won't be pushed out through Windows Update. There's exceptions for vendors like Intel, AMD, NVIDIA, but that is because of what those companies are and how popular/well-used they are (they will be working with Microsoft for such). You can't just have your driver pushed out via Windows Update.
You're going to need a digital signature to sign your kernel-mode software with as long as you're going to be distributing it onto machines using modern versions of Windows x64 (for the record, even Windows Vista x64 will enforce this requirement). This requirement will not be present on x86 versions of Windows as-of right now, but in all truth, it would be unethical to not sign your kernel-mode software anyway.
Starting on Windows 10 on a specific patch which was released really early-on, the requirement changed from having a normal digital signature which could work for signing kernel-mode binaries to it having to be an EV digital signature; to get your hands on an EV digital signature for kernel-mode software signing, you will undoubtedly need to be legally registered as a company (and likely require a company bank account as well).
See the following for more information about this.
https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/04/01/driver-signing-changes-in-windows-10/
Here's the twist though... For systems which are using Secure Boot (new modern systems tend to have it enabled by default now, it is a security feature), you will need to have your kernel-mode software co-signed by Microsoft themselves. This will require you to share your kernel-mode software with Microsoft by uploading it via an online portal, but you'll still need your EV digital signature before you can move to that stage.
See the following for more information regarding the Microsoft co-signing requirement (depending on the environment):
https://www.osr.com/blog/2017/07/06/attestation-signing-mystery/
Note: Please do not try to come up with ideas to circumvent this (e.g. enabling Test Mode on a clients system and then using a Test certificate for your driver, or disabling Secure Boot on a system which relies on it... such work-arounds come with a huge price of reducing the security on the system, and should never be applied as a solution to this problem in the real-world).
For actually installing the device driver, you could programmatically use the .INF file with the Win32 API and then use the StartService routine to start the service post-installation with the .INF. Also see: https://msdn.microsoft.com/en-us/library/aa376957%28v=vs.85%29.aspx
Alternatively, you can register the service yourself with the CreateService routine and then start it with the StartService routine (or reboot and have it load on start-up depending on the flags for the service creation).
Bear in mind, sometimes using the Service Manager, you'll miss important things in registration for some driver types (e.g. Filesystem Minifilter), and you'd need to handle this manually otherwise it won't work. Check the .INF and make sure anything that needs to be done as an requirement is done when you use the Service Manager for installation (if you decide not to rely on the .INF).
Hope this helps you get to where you need to be.
I need to create an automated process in which a script detects the graphics card type on first boot, then installs the appropriate drivers, which will be included in the image, before performing the next steps. The target platform is Win XP Pro.
I came across some WMI code which can get hardware information but since it uses a PNPSignedDriver class I would presume that it requires drivers to be installed before it can detect the device.
I can't use devcon, as it isn't redistributable. Am I right in assuming that WMI cannot help me here, and if so what are my other options?
Thanks,
Bill.
WMI does seem to be the way to do this, as found here. I will confirm after testing.
EDIT - Not sure if this is possible, WMI can only get the name of the display adapter not the device ID of the card, and before the drivers are installed this is something generic like "Video Controller (VGA)". I will update this page if I find a way.
I am working on a program that requires to install a driver for Plug and Play. My issue is that the first time the device plugs into, by default, windows 7 32-bit automatically search online for drivers that better match to device. As i observe, it takes too long (15m) to correctly install the driver.
How can i turn off the automatic search on windows 7?
Thank you for any useful information.
Apparently you do this through GPO, as described here:
http://www.verboon.info/index.php/2010/12/windows-7-device-installation-without-administrative-rights/
Look for "Prevent Clients from searching for drivers on Windows Update" on this page.
Read up on applying GPO programatically and you should probably be able to get the job done. However, mind that you'd be changing the policy for the whole system, not just installation of this device.
If you install a driver package for your driver before you insert it, Windows will not search online.
If you really want to disable online serach on your machine - take a look here.
I am looking for a programmically API on how to restart any device that allows enable/disable in the device manager,
such as Audio devices and Network adapter
You will have to use SetupApi / ConfigManager API. But be aware that under x64 you app. must be also x64 to enable/disable device (so you cannot do it in Delphi directly right now - first I thought that it's a problem with file/registry redirection for x86-app under x64, but it didn't help). Device enumeration works fine. There was something about it in one article on MSDN but I cannot find it right now. I've made FP/Lazarus x64 application for enable/disable devices under x64 OS.
You can download WDK and look for source code of DevCon (C:\WinDDK\7600.16385.1\src\setup\devcon). In cmds.cpp there is function ControlCallback which enables/disables device using SetupApi). But first you need to enumerate device classes (by GUID or ClassName), and then enumerate device instances or open device by DeviceInstanceId string. It's in C but it should be easy to learn how to use that API.
Not sure what you are doing, but maybe it would be easier to use that devcon.exe (don't know if license permits it) and enable/disable devices by it?
I have no experience with it but I think you can use the DeviceIoControl API.
I'm using InstallShield to install my application, a driver and a service.
I need to install the plug-N-play driver only if it's hardware ID was found in the device manager. The driver installation is done using DPInst.exe.
My problem, is that a user can sometimes manually uninstall the driver (After it was installed or even uninstall the "Unknown driver" under "Other devices") and then I can't find the hardware ID in the device tree, although the device is plugged.
If I rescan the device tree during installation using CM_Reenumerate_DevNode_Ex (The code equivalent of "Scan for new hardware"), I can find the hardware ID but this brings up the "Found new hardware wizard".
Is there anyway to rescan the device tree but suppress the "Found new hardware wizard" or to avoid rescanning but still making sure my device hardware ID is present in the system?
I'm writing a new answer since we already have too many comments on my older one, and its content was based on a small misunderstanding of the situation.
The actual problem, as I understand it now, is the "Add new hardware" wizard that pops-up when rescanning for devices, before installing your driver. Unfortunately, this wizard pops-up whenever no suitable driver is found to handle a new device in the system, so in order to overcome it, the only option is to make sure that such a driver exists in the system. This leads to two possible solutions that I can see:
Go for a software first installation, and make sure that your driver is suitable for the device (the inf is well formed, and you have WHQL signing). As far I understand, this is not an option, because you do not want to install the driver on machines that don't have the device connected (I would love to hear why).
Make sure that some other driver in the system is suitable to handle it. In that case you need to choose one of the built-in drivers (one that wouldn't wreak havoc if it were to act as a function driver for your device), and give your device a matching compatible ID - one that would cause the built-in driver to be found suitable. This way you will not have to wait for the user after re-scanning for devices, but depending on your device, finding a fitting built-in driver might be impossible.
It sounds like you're going about it the wrong way. If you have an MSI based installation, why not use DIFxApp instead of DPInst?
As for the "Found new hardware" wizard, you'll need two things here:
Make sure that your inf file is correct (so that your driver is associated with the hardware id)
Get a WHQL signature from MS. This step is needed for XP, as untrusted drivers will not be automatically assigned to devices. With Vista and 7 you can digitally sign the driver yourself, but you'll get a warning during installation, asking the user whether he/she wishes to trust this publisher (you).