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.
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.