I'm working on extending an existing USB device driver, and have been struggling learn how the .INF file works. I believe that I have it right now, the driver installs and works. It also shows up in the "Add/Remove Programs" list.
I find that when I uninstall the driver from Add/Remove, it seems to do little if anything. This was in the .INF as I inherited it:
[myUninstall]
DelReg = myDelReg
[MyDelReg]
HKLM, "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\myName"
I can find no other references, not even where "myName" is installed in the registry Uninstall.
I've changed the .INF to have this:
[DefaultUninstall]
myUninstall
[myUninstall]
DelFiles = ... a list of files ...
DelDirs = UNINST.Dirs
DelReg = UNINST.Regs
Cleanup = 1
[UNINST.Dirs]
%16422%\%InstallDir%
[UNINST.Regs]
myDev.AddReg
myDev.CommonRegs
[myDev.AddReg] ; same definition used for installing
HKR,,Drivers,Subclasses,,"wave,midi,mixer,aux"
...
[myDev,CommonRegs] ; same definition used for installing
HKR, Parameters, BufferSize, 0x0010001, 256
...
Still, whether I uninstall from the Control Panel Add/Remove programs or do it from the device manager, the system doesn't complain and nothing seems to happen. I've looked at the output of "dpinst /c" and the setupapi.log, and neither tell me much. dpinst shows no error but is clearly not even trying to execute my uninstall section.
I find a lot of verbiage online and examples of uninstall sections, but very little in the way of explanation. I did stumble across one sentence in 1 forum today that implied that PnP device .INF's don't use Uninstall. Perhaps this is my issue?
am I wrong in thinking that I can have Uninstall in this .INF?
is there some other way to tell what is happening?
is my only recourse to write a separate uninstaller?
AFIK, the INF files do not participate in uninstallation.
You will need to write a separate uninstaller if you want to perform proper cleanup.
Further note that with Vista and beyond, Windows also includes a Driver Store, where it silently copies the driver package (inf and files references from the inf). If you want to perform a full cleanup, the driver store should also be cleaned up.
I don't think DefaultUninstall is a standard section in the way DefaultInstall is. Often you will see the UninstallString ARP entry just calling DefaultUninstall by name.
The documentation in this area is pretty bad and there is a split between the basic SetupAPI/SetupX INF files and the Advanced INF files (AdvPack).
The only 3rd-party exception I know of is TweakUI.inf from the Windows 95 PowerToys.
It has parts that look like this:
...
[Optional Components]
TweakUIInstall
[TweakUIInstall]
CopyFiles = ...
AddReg = ...
Ini2Reg = ...
...
InstallType = 10 ;Typical, Custom.
Uninstall = DefaultUnInstall
[DefaultUnInstall]
DelFiles = ...
DelReg = ...
But I think that only works with the optional components feature, not basic uninstallation. TweakUI v1.33 (Tweakui.exe SFX archive) has some more NT related entries and I believe the way it writes the UninstallString for NT even writes the wrong INF section. Wrong or not, it manually has to specify a INF section for normal uninstall.
Related
First:
I know there are other questions that ask similar/the same thing, I have looked at them tried all of them but no solution has helped.
The problem:
We use Epson Iprojection (downloaded from here: https://www.epson.co.nz/products/projectors/software/) However I can not find a way to get an MSI out of it (I am starting to think there is no MSI bundled in the .exe), and I can not seem to install it through CMD on computer start using AD. Any help will be greatly appreciated.
Vague Answer: Let me try to formulate an answer out of those messy comments above. I only briefly tested this software, it might not deploy as badly as expressed. Remember that this is a generic answer for whoever would find this in the future, and not for OP per-se (there is no real answer in here).
Due Diligence: I always try to consult package tip databases if I have problems with a package. Somebody, somewhere will have seen the same problem (eventually).
Silent Installation: Silent installation of legacy setups is usually possible (not always), but never really reliable. For Installshield it involves recording answer files (setup.iss) that record dialog answers. However, unknown dialogs can show up suddenly on some systems (low disk space, reboot prompts, unexpected lock or application in-use warnings, unexpected service running warnings,etc...) and hence halt the install unexpectedly as the response file has no recorded value for the dialog in question. This particular Epson setup also has an unfortunate reboot requirement on uninstall that is hard to deal with for large scale deployment (spontaneous reboot likely - without warning).
Repackaging: Personally I would try to capture the install using a repackaging tool. Most of these are expensive, but can output MSI, MSIX or other deployment package types. Repackaging fails when the package contains complex, custom logic that - for example - create dynamic content (ciphers, unique GUIDs, etc...) and in a number of very specific technical cases.
Contact Vendor: If you capture an MSI that doesn't work, why not try to send it back to the vendor with some comments on how hard this software is to deploy and maybe mention the major benefits of MSI? I would tell them you have to ditch the whole software from your network if they can't deliver a deployment solution that works. Time is of the essence. "Some solutions are only free if your time is worthless" (quote from Joel Spolsky himself - slightly out of context, but the same issue: we need solutions that work in a timely fashion).
Note: I once had to compile a special setup to deal with a client's
deployment problem that was our fault. Deployment problems need fixing at a standardization level. Standards!
Buried within the single-exe download is iProjection_inst.exe, some sort of wrapper that prompts for language selection, and doesn't seem to have a standard "non-interactive" mode.
Inside this is instData\Setup.exe, a vintage "full screen" InstallShield installer with external ini / cab files.
Running this with Setup.exe /? doesn't give any command line arguments, as it would for a modern InstallShield setup.exe.
Although it supports recording an answer file via Setup.exe /r, when I try to replay the answer file with Setup.exe /s it seems to still prompt for EULA, and then fails to install.
So this is really a design flaw in the innermost installer to do with the dialog sequence.
Assuming Epson won't fix it and repackaging is too hard, a hacky alternative is to use Powershell to automate the UI of instData\Setup.exe once the "Welcome" screen is showing, but I don't think this will work running as an AD script.
$wshell = New-Object -ComObject wscript.shell
$aName = "Epson iProjection Setup"
function Next() {
if ($wshell.AppActivate($aName)) {
$wshell.SendKeys(' ');
start-sleep 1;
}
}
function AcceptEula() {
if ($wshell.AppActivate($aName)) {
$wshell.SendKeys("{TAB}");
$wshell.SendKeys("{TAB}");
$wshell.SendKeys(' ');
start-sleep 1;
}
}
Next; AcceptEula; AcceptEula; start-sleep 20; Next;
I know this is an old thread but it looks like it may be easy now. The latest 2.41 from here
http://www.downloads.epson.com.au/DownloadFile.asp?filename=iProV2411Win%5FWEB%2Eexe&path=Drivers
seems to have an MSI in it. Just jump into the %temp% folder and organize by date so you can see the latest files. Run the installer and a new folder named with a GUID should show up, in my case {27CDEEE8-B6F2-45a7-A48E-696862573D9B}.
Under this folder there is a series of InstData folders like InstDataX64 where you can find an MSI.
Summary
I'm developing an installer for an application that involves installing a USB device based on WinUSB. Everything works except for an annoying issue in which the USB device shows up in the notification pane after installation with the option to safely remove it:
I don't want this option to appear but I'm not sure how to go about preventing it. I believe it should be possible by adding the right directives to the INF file for the device, but Microsoft have done a fantastic job making the INF file format stupidly overcomplicated and I'm having trouble figuring out exactly what to do from the docs.
What I've Tried
The Microsoft docs really aren't helpful enough, but I managed to find an old document called Designing Hardware For Surprise Removal Under Windows XP that seemed promising:
Based on this I tried adding the following content to my INF file:
[USB_Install.HW]
...
AddReg=Dev_AddReg_HW_Removal_Policy
[Dev_AddReg_HW_Removal_Policy]
HKR,,"RemovalPolicy",0x00010001,2
After installing this driver, I went to device manager and was able to confirm that the "Removal policy" property was set to 00000002 (it was 00000003 before). However, the device still showed up with an "Eject" option.
My next attempt was with "Safe removal required", which is currently set to <true>. I had a stab at including the directive for this in my INF file:
[USB_Install.HW]
...
AddReg=Dev_AddReg_HW_Removal_Policy
AddReg=Dev_AddReg_HW_Safe_Removal_Required
[Dev_AddReg_HW_Removal_Policy]
HKR,,"RemovalPolicy",0x00010001,2
[Dev_AddReg_HW_Safe_Removal_Required]
HKR,,"SafeRemovalRequired",0x00010001,0
I used infverif to confirm my INF file was valid, but after installing this version of the driver the "Safe removal required" property is still set to <true> and the device still features an eject option.
Is anyone familiar enough with the convoluted (and quite frankly retarded) INF format to suggest what I need to change to make the "Eject" option disappear?
On our 1200 windows clients we are using KES 10 antivirus.
By error on some desktop workstation we installed the firewall component "klim6".
We need a silent uninstall. Not found within Kaspersky tools.
Which is the working and proper way ?
RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection DefaultUninstall 132 KES10.inf
NETCFG.EXE -v -u KLIM6
devcon.exe remove =net *klim6*
We need also the explanation of the different behaviour of these tools.
UPDATE : info from the INF file :
; KLIM6.INF -- NDIS Usermode I/O Driver
[version]
Class = NetService
DriverPackageType=Network
[Manufacturer]
%Klft%=KLFT,NTx86,NTia64,NTamd64
As you've noted, there are a variety of tools to work with .INF files. The reason is that there are different flavors of .INF, used for different purposes.
I don't know if there's any official terminology, but here's the terminology that I use:
DefaultInstall-style INFs. Use "rundll32.exe SetupApi.dll,InstallHinfSection" to work with these. You can identify this style of INF because they have "[DefaultInstall]" in them.
PNP-style INFs. Use pnputil.exe (built-in, so more convenient) or devcon.exe (more powerful) to work with these. You can identify PNP-style INFs because they have a "[Manufacturer]" section, and they are not NetCfg-style INFs.
NetCfg-style INFs. Use NetCfg.exe to work with these. You can identify NetCfg-style INFs by the line Class=NETTRANS or Class=NETSERVICE or Class=NETCLIENT. Only those 3 classes are NetCfg-style INFs -- in particular, Class=NET is not a NetCfg-style INF; it is a PNP-style INF.
There are other types of INFs used for Windows Drivers, e.g., storage minifilter-style, or upper/lower-filter style INFs. And other people use INFs for things that have nothing to do with Windows Drivers... so it's a confusing area.
That being said, it's often a mistake to attempt to manually remove a driver. Usually an application's installer will install many 100's of things, only one of which is the driver. If you delete only the driver from an application, you could easily leave dangling bits that damage the system in obvious or subtle ways.
If you really want to do this anyway, you should check the INF file. If it says Class=NET, then use devcon.exe. If it says Class=NETSERVICE, you should use NetCfg.exe.
I also had to remove kaspersky NDIS filter (for different reasons).
The proper way to do this is with netcfg.exe
You need to disabled the Kaspersky's Self-Defense mechanism and exit the product. You can then uninstall it with this command:
C:\Windows\System32\netcfg.exe /v /u kl_klim6
Unfortunatly, I couldn't find an easy way to uninstall the filter in Windows XP but one method is provided Here
So i recently got myself into a sticky situation, it seems like windows 'forgot' about a program I had installed (some drives changed letters / not really sure what happened).. I could find files that it created, but in 'Programs' and 'Add/Remove Programs' it is not there.
Also, when I use the 'programs' installer, it says it cant install because it exists already (to some extent), and I can un-install because windows doesn't know it exists.
BUT! I have an executable of the 'program' that works.
So I am wondering what the difference is between an executable, and what windows considers to be, and keeps track of, a 'program'.
This is definitely the kind of program that would show up in 'add/remove programs', as I have several other very similar ones from the same company that show up there, and I know it used to show up there.
I am not looking for wikipedia answers, I am interested in what exactly a 'program' is. What are the necessary pieces that make up a 'program' as far as windows is concerned?
For a program to show up in "add/remove programs", it needs to be installed. Typically, this is done through an installer that takes care of registering the program with windows and modifies the environment so that the program functions properly.
It may modify the registry to store user preferences for example...
When you have just an executable, it's not necessarily installed. It may be standalone.
Some programs don't absolutely need to be installed even if it's the canonical way to add a program in the Windows system. That's why it may work.
Another executable may fail because it relies on modifying the state of the system to work properly.
I hope it helps :)
Well, I'm using Visual C++ 2010 Express and ResEdit
for my midi sequencer's SETUP app.
Win32 API, no MFC, some custom window and control classes and such.
Now that I got Windows 7, my dang SETUP program is broke.
Windows gives me the ole "Did this app install correctly??" thingy.
Which implies that SOMEthing is wrong with my installer.
I'm tryin' to figure out what that might be...
I've seen these 2 SO threads:
"This program might not have installed correctly"
"This program might not have installed correctly" message in Windows 7 RC
Which have lead me to these places:
http://msdn.microsoft.com/en-us/library/dd371711(VS.85).aspx
http://msdn.microsoft.com/en-us/library/bb756937.aspx
http://msdn.microsoft.com/en-us/library/aa905330.aspx#wvduac_topic3
http://blogs.msdn.com/b/cjacks/archive/2009/06/18/pca-changes-for-windows-7-how-to-tell-us-you-are-not-an-installer-take-2-because-we-changed-the-rules-on-you.aspx
http://community.flexerasoftware.com/archive/index.php?t-189007.html
Only registry entries I use are the standard uninstall spot and
associations for filetypes.
SETUP writes a dat.cfg file in program files\pianocheater dir
that points to where all the app's data is. (just a text file with a path in it)
(And an etc.cfg for a temp dir within that data dir to use.)
So I'm only READING from programfiles\pianocheater post SETUP.
Can anybody think of why Windows wouldn't like the install?
Source code is at http://shazware.com/_etc/SETUP_PIANOCHEATER.cpp
It uses my library of window, control classes similar in spirit to mfc.
I could send useful parts of it, too.
It's not toooo bad for a setup app.
Should be pretty ledgible for a win32 guy/gal.
I could uuuuuse some he'p...:/
Oh yeah, I should point out that Go() is the entry point instead of main().
The DBG()s just do OutputDebugString() and seem to all run just fine.
TStr is just a big char[MAX_PATH] (and I don't do unicode)
And the trick PROBably is that I'm on win7 64 bit, but this is a 32 bit app.
I'm pretty sure I'm using the registry correctly for assoc's and uninstall spot, though.
So is THE thing I SHOULD do the manifest xml thing?
Or is there a more correct way to do things?
thanks much,
...Steve
First off, check whether that message is a false positive or not. The message you're seeing is designed to use heuristics (which can be wrong!) to determine if an installer failed due to Windows Vista/7 compatibility issues. If your installer is in fact compatible with Windows 7/Vista, then all you need to do is add a manifest declaring itself compatible. You'll also want to add a requestedExecutionLevel entry to your manifest as well to request elevation.
If your installer is in fact failing, of course, then you ought to fix that first.
Finally, if the error is showing up because a launcher executable exits early or something like that, consider suppressing installer detection by adding the appropriate manifest entries to the launcher as well (you may be able to use a requestedExecutionLevel of asInvoker if the launcher doesn't need administrative access; the presence of a requestedExecutionLevel manifest entry should suppress installer detection). Note that you should make sure you use ShellExecute to invoke your main installer process, not CreateProcess, or UAC may not elevate the child process.