I'm creating setup for my application in Inno Setup, and I will probably need to install driver sometime in the future. However, I need to know some tips about installing drivers in Inno Setup now, so I can easily add the driver into the setup when it's needed.
Should I force the user to install program only into C:\Program Files\<app>\, or it doesn't matter and I should let him install it even on network drive?
Should I install the driver in C:\Windows\, to make it available anytime (even without network drive), or it doesn't matter as well?
Is it possible to start driver on-demand? I want to release new versions of my program, and I need to create the setup so it doesn't require reboot after updating my app. So is it possible to shutdown the driver, overwrite it with new version, and turn on again (as you can with services) without restarting Windows?
Is it possible to overwrite the driver so easily (as mentioned in question 3), or is it recommended to always fully uninstall the program, and then again install the new version?
Could you please include some additional tips about installing/uninstalling/updating drivers you find important? I'm sure I've missed some important points.
I don't have much driver-experience nor knowledge, so I apologize for somewhat confused questions.
And it is probably important what kind of driver would it be, so there is a related question, which should answer that:
Low level mouse hook and DirectX
Driver Development Resources
I've found some helpful links regarding driver development. Use this as a reference.
Driver Development at CodeProject - Part 1, Part 2, Part 3, Part 4, Part 5, Part 6
http://www.catch22.net/tuts/kernel1.asp
Introduction to Device Drivers
Windows Driver Development Tutorial
Please don't do this, installing an upper-level filter driver on all HID devices is an extraordinarily bad idea. That being said, I'll answer your questions anyways.
When you install a driver, Windows manages where the driver itself gets put (in DriverStore), you don't worry about this.
See #1
For some drivers, yes. For a filter driver above HID, no. You'd have to force remove all mice and keyboards on their system and re-add them (which isn't possible with PS/2 devices).
Yes, it's fairly easy to update a driver given that you correctly version it and require a reboot.
Once again, while I don't want to be discouraging, you're only going to get yourself in a world of hurt via doing this.
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 have one drive (C:\) with Windows 2008. Is that possible to install drivers to this Windows while booting from WinPE (another OS)? I couldn't find any software to do this.
So what I'm trying to do is install drivers to one Windows while booting from another Windows on separate disks.
It's not impossible, but not easy either. Installing a driver is basically a matter of copying the files and editing the registry, both of which can be done remotely.
However, the problem comes from knowing which registry entries to create, with which values. This depends on the driver, the OS, hardware and a bunch of other factors. The best approach would be to install the driver normally, and take a diff of the before/after registry, if you can. If not, you could set up another Win2008 system, do the diff there, and start from that.
If you are just updating an already installed driver, copying the newer version files will likely work.
This seems like an XY problem, though - what exactly are you trying to accomplish? There may be a better approach.
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'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).