I'm looking for a simple method to prevent Windows Update from installing drivers automatically. Exactly these steps:
http://support.microsoft.com/kb/2500967
Is there any method to do these steps just by modifying registry keys? Or even by doing it with help of a simple bat file?
I've just found an answer. The key I was looking for is located here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching]
"SearchOrderConfig"=dword:00000000
To add this values to our registry, we can use that command in our batch file:
REGEDIT /S NameOfOurRegFile.reg
I don't know of a registry key, but why not change the windows update to download, but not install. Then you can review the updates and use right-click-hide to hide the driver updates.
I like to see the driver updates because that lets me know that I might want to go to the vendor site to look at the real driver info and decide if I need it or not. I then only install the driver (from the vendors site) if there are changes I need.
And since I have hidden it in update, I don't get bothered again until a new driver comes out.
Just a thought (vs. hacking your registry.)
One other consideration. In some cases, a registry hack might have some side consequences that confound you late when you can't figure out why something you thought should work, doesn't. Most support options don't consider registry hacks when trying to figure out why something doesn't work...
I can't comment, so here are some things to consider.
What you want to do will possibly look very much like a virus that wants to prevent things from being fixed. So if you do find a way, I strongly encourage you to test it with a number of AV apps - and then register it with them so they don't add it later.
You do have an option to check the version of the drivers in use for given hardware items. Then, if your app sees a new driver, it can at least warn the user that a new driver was installed (and log that fact) and to roll the update back if they have problems.
Related
I am trying to check if drivers are installed for a particular USB device as part of an installation process. Unfortunately the manufacturer has several different installers for the same driver and there seems to be no consistent place in the registry to check if the driver is installed. However it's obvious that Windows must know if a driver is installed for a given USB device ID (Eg VID and PID) and I presume this is recorded in the registry?
How can I check to see if the driver is installed only by querying the registry, without relying on looking for installer-specific keys such as references to the uninstaller (which is unreliable) or calling Windows API functions?
Don't query the registry. There's no documented location for this, and it changes. Definitely between versions, possibly with service packs.
The proper way is to use Windows API functions, and it's unclear why you would reject this solution.
I faced the same Problem as you as I wanted to check in Installshield if a device driver was already installed.
I first tried the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ path as mentioned in USB Device Registry Entries, and it worked on 2 Windows 10 systems I tried but on a 3rd System it was not located here anymore but in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceMigration\Devices\USB\, I assume it has with a Windows 10 update to do but I am not sure…
I finally found out, that on all Systems I was able to find the VID/PID text (in my case VID_0483&PID_DF11) in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class, which is pretty much what people programmatically do here .
Anyway as MSaters suggested I would rather use a C# Windows query like System.Management.SelectQuery query = new System.Management.SelectQuery("Win32_SystemDriver"); (see How to check whether a driver is installed?) as I am not sure, that the registry query allways work but it is in my case not possible.
Edit:
I found out, that Windows creates the registry entry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\ as soon as the device is connected, even without drivers installed, that means that it is an incorrect way to check if the driver is installed.
There is another way though, the registry entry contains "VID_XXXX&PID_YYYY" then a "SERIAL" as subfolder, in my case (VID=1FC9, PID=000C, SERIAL=ABCD) \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_1FC9&PID_000C\ABCD, you can then check the presence of an entry called Driver, it seems like it is only created after you install your Driver.
And for some reason the entry to look for under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceMigration\Devices\USB\VID_1FC9&PID_000C\ABCD seems not to be Driver but DriverInfName
I am working on a VB6 application which has many executable and an Active X dlls.
And there are to be updated in c;lient machines to lates version once in a while which i am asking the user to update manually.
Can you please suggest me a way using which i can update it automatically from the files that can be available online.
Thanks.
Windows Installer has features supporting Patching and Upgrades. Using those techniques you can create various levels of "upgrade" packages.
Your application would need a separate "update" utility that is spawned when the user approves updating, perhaps in response to a prompt your program raises after checking for new versions.
This updater would check the current version and the remote site's catalog of updates to pick the appropriate package, download it to a temporary location, start Windows Installer to process the package (or packages, sometimes you might need to run several Installer runs), and clean up the temp location. Then you might offer to restrt the updated application or on some occasions need to reboot.
This updater would be a fancy form of the common "installation bootstrapper." As you can tell it needs some "smarts" in order to tell what package or packages to download and install in what sequence, when it needs to request rebooting, etc. This would probably be based on a downloaded "rules script" it obtains as part of selecting a valid update option.
After all, sometimes you can just apply a minor upgrade or patch upgrade, sometimes you need a more complete install or entire reinstall.
If your needs are extremely simple (just an EXE and maybe a few DLLs and OCXs - preferably using reg-free COM) you may not need to go to these lengths. However when you start adding in other considerations like multiple programs, data directory creation and security settings, possibly running a settings file conversion or even database conversion, DCOM, firewall, etc. configuration, database drivers or providers, etc. things get complicated quickly. Too complicated for simple snatch and grab updating.
And admin rights/UAC issues are a factor so you'll probably have to deal with privilege elevation.
None of this is trivial stuff. There are people who do little more than construct and test such deployment systems as their entire job.
If you use soemthing like Inno setup to install the application then an update is simple a matter of running that periodically.
You can either detect there is a new version available by checking a web site/local server, or just prompt to run the update after X days.
I know registry is not a best place to hide something.
Right now I'm writing a Licensing software that require to save trial usage information like first install date on registry, etc.
What hive in Windows Registry that meet this criteria :
Not easily discovered by accident by the Users.
The value can be shared among Windows Users.
Didn't mess up Windows and Registry Cleaning Utility not consider this value as a garbage.
If can, it work without administrator privileges on Windows Vista and Windows 7
Edit : I have excluded items # 4 because it is not possible with item # 2, based on answers from David Heffernan
There are no shared locations in the registry that can be written to without admin rights. So your conditions 2 and 4 cannot both be fulfilled. You need to do this with a file I believe.
If you are prepared to drop condition 4 then you need to store it under HKLM so that it is shared. The obvious place is HKLM\Software\YourCompanyName\YourProductName. Naturally you would encrypt the data to avoid tampering. Once you have done that then you don't really care whether or not your users discover it.
What are you trying to defend against? It sounds like you're putting a lot of effort into "don't let people change their system clock to extend their trial" but none at all into "don't let people edit the Registry key to extend their trial" or "don't let people share Registry keys between machines to turn trials into full keys for free". I actually think those are far more likely. Any software that yelled at me for changing the clock on my own machine would get uninstalled in a hurry.
I recommend you don't try to do this yourself. There are licensing libraries you can use that have thought of the various ways people try to trick software. But if you must, because you want to try it, then take some time to distinguish what happens at install, which might require admin rights, from what happens while you're running and checking, which should not. An app that has to run elevated for no other reason than writing license info to HKLM once a minute would also be uninstalled in a heartbeat from my machine.
So at install, write something obscure/encrypted to a Registry key under HKLM. Make it something that's not super helpful to copy from machine to machine, while you're at it, by combining say a date, an email address, and some other information. At runtime, your code should look partly at the unchanging Registry entry or entries and partly at something else that can change easily, like a file under AppData, an HKCU key, or the current date, to decide whether it's ok for the app to run. (At runtime, if the HKLM key is not there or fails a checksum or whatever, refuse to run and ask for a reinstall. Reinstall can worry about whether the person is trying to get infinite free trials.) Focus on the main ways people try to trick licensing schemes and also on being a usable application. Insisting on elevating or preventing general use of the machine fails on the usability side.
You can, on install, change permissions of somewhere in HKLM so that all users have write access.
If you choose a place other than HKLM\SOFTWARE\Your Company Name\something than you're being foolish.
If you want to implement a time limited trial for an application you would probably want to leave behind some flag (registry key, file etc) so a program couldn't just be re-installed.
Are there any schemes that allow you to do this while still passing the various Windows Certification programs?
Generally :-
Applications must correctly and fully
uninstall from the machine. This
includes removing files, registry
keys, GAC assemblies, database tables,
metabase settings, active directory
accounts, etc. Anything left on the
system after uninstall, including
system components installed by the
application, must be documented and
justified - Windows Server 2008 Software Logo Secification - 2.3 Uninstall Cleanly
You are taking the philosophy of only allowing installation if a flag is NOT there, which means you need to leave the flag there after uninstall. Also this fails when the user finds the flag and deletes it themself.
Better is if you turn it around and only allow the program to work if a flag IS there. This flag would be a registration key that has the date of expiry encrypted into it. When the program expires or is uninstalled, you delete the flag.
I implement this by making my users come to my site to register and get a free trial key. There are probably other ways, but I like this one because it also allows me to collect info about who is trying my program.
If your app is connected to the Internet, then you could store information on your own server about whether it has been installed before or not. However, this almost certainly needs to be designed in from the start with potential investment in hosting your own server to be available to check against.
I'm sure there must be plenty of cases where files are left behind after an uninstall that are perfectly acceptable. For example, I wouldn't expect all my documents to be deleted when I uninstalled Word.
I'm trying to install a DMO which requires me to write to HKCR\DirectShow\MediaObjects\Categories\57f2db8b-e6bb-4513-9d43-dcd2a6593125, this registry path is protected by TrustedInstaller and it seems that this protection is new in Windows 7 (it work on previous platforms).
How am I suppose to install DMOs?
There are plenty of places that suggest to take ownership on the this registry key but this just doesn't feel right.
BTW, were using boilerplate Wix3 to write the registry values.
The Windows Installer cannot be used to update Windows. I know it sounds funny but Windows Installer is for "applications" and the Trusted Installer is for "the operating system". To update pieces of the operating system, you need to use an operating system service pack or KB.
If this is a documented place in the registry that you are supposed to be able to extend then I would guess it would be necessary to contact Microsoft about the key being protected. My guess would be that it is a bug.
If it is a bug in Windows then Microsoft hopefully would provide a work around or fix. Maybe the answer is to take ownership of the registry but I agree that doesn't seem right.