I am trying to find out how a driver is being installed on the system from a MSI setup package. I am currently using a program called InstEd to try and get an idea of what its doing:
http://i.imgur.com/b9USo.jpg
I am interested in "MsiProcessDrivers" and "MsiInstallDrivers".
Can anyone reccomend how I can see how the drivers are being installed?
The MS Sysinternals suite has some tools for monitoring registry and disk operations. Just run them prior to running the installation, and note the actions that are performed by the installer.
Sysinternal's Process Monitor will show file system and registry changes being made: filter by msiexec processes.
Warning: for a non-trivial install this is likely to be a lot of operation.
The two custom actions you reference (MsiProcessDrivers, and MsiInstallDrivers) are part of the DIFx Driver Installation Framework as used with Windows Installer.
Related
I am running into an issue when trying to add Brosix as an application to MECM for quick and easy deployment upon imaging of a laptop. This requires the Brosix installer to run in unattended mode (aka silently/quietly) but I cannot find such a command when running the installer and I am also planning on running their installer with the /advanced command so that it installs for all users instead of a singular one. So far /silent has not worked for me and neither has /unattended when running these installers in cmd or Powershell.
It seems Brosix did not make support for silent or unattended installs using their advanced installer which installs for all users, although I was unable to confirm this from Brosix despite calling them and making a support ticket. Therefore, it seems the solution for MECM is to have it be a per-user install (that is silent normally) which is something you need to set up when you build it in MECM.
I have a freeware software, which i want to install on a network share. The reason is, if the software is installed on a network share, all users which has access to this network share folder should be able to use the program.
Now, I run the setup.exe on my machine and choose on the step "destination installation" my network share \sharename\TestFolder.
The software was installaing on this sharefolder and after the installation it was possible to run the program on my computer without any errors and use it..
After that I try to start the program on other client but there is always an error message, that it starts with a false operator.
Now my question is, is there a software, which can observe on which files the program want to access when I make double click on the (program.EXE).
Thank you, I hope you can help me.
Yes, there are several tools that can monitor or observe system changes performed by a setup.exe.
Many of these tools are quite old and may not operate correctly in new versions of Windows. The most recent one I found that looks acceptable was EMCO MSI Package Builder. I never tested the monitor feature, but it is at least an updated capture product.
In my experience these monitor tools capture way too much low-level system stuff, and you will need to spend quite a bit of time to sort out what is really needed for the software to operate. If you have experience with software development you may get just as much information from using a System Internals tool such as RegMon, FileMon or ProcMon. See Microsoft site: http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx . These tools are exceptionally useful and known for their small size and great feature set. You can run a ProcMon on the launch of the application executable.
It is also possible that the setup.exe is a wrapper for an MSI file. These files can be viewed with free tools such as Orca and EMCO MSI Package Builder and you can basically see what registration settings are needed for the application to operate. Try opening a command prompt and write setup.exe /a and see if it offers to create an "administrative installation point" - or similar.
If I were to guess I'd say that the software needs to have COM servers registered locally, registry keys added to each local computer and possibly you need to install a couple of runtimes on each system - for example Microsoft C runtime of a particular version. This is just a wild guess. What is the name of the software? If it is a .NET application you may need assemblies installed to the Global Assembly Cache GAC.
We have an ERP application which is built in VB6 and it was running just fine till a few of our customer upgraded all their systems to Win7.
This software is programmed in such a way that it registers a few plugins (found in plugin folder) which are COM based at runtime. Now when the software is run by user without setting Compatibility Mode and Run as Administrator setting it fails and crashes.
I know we can manually set both Compatibility Mode as well as Run a Administrator by right clicking on program executable and then going to its properties. But this looks very unprofessional.
I think there will be some way to tell Win 7 to automatically run a software in Compatibility Mode and Run as Administrator.
Please help me.
Compatibility is an administrative function, not a development or deployment function. It is better to fix the application where possible, especially to remove any requirement for elevation.
There are plenty of tools for investigating the issues so you can correct them. However globally registering "plug ins" at runtime is a nasty one. VB6 component self-registration is always global unless registry virtualization can redirect it. Why not create installers for the plug-ins that can run elevated once during installation?
There are ways to set compatibility less manually, even as part of installation - though Microsoft discourages this. Maybe take a look at:
Compatibility Fix Database Management Strategies and Deployment
However the effort required might be better spent on remediating the problem. Support costs will be less over time.
As the other answers have said, you shouldn't need to run all the time elevated.
If you want to register the plugins after its started (as a normal user), you can use ShellExecute() with the "runas" verb to run regsvr32.exe, or use COM elevation which has been discussed many times before.
You can indicate that an application must run as admin by specifying it in the Application Manifest, which in an xml file that you can either embed or deploy with your application.
Once your application is running with admin rights it should be able to register and load the plugins. You should not need to run in compatibility mode to access the COM plugins.
Is there a integrated Rollback-Action in any of the Installer-systems mentioned above? I know it's available in Windows Installer, but it seems to be missing in any other system I looked into.
Is there any system like Windows Installer that actually supports automatic Rollbacks?
NSIS does not support this because a script could do anything (Call any Windows API, use NSIS plugins to perform advanced tasks etc) and it would be impossible to know what and how to roll-back. But if you code the uninstaller to handle half-baked installs, you execute the uninstaller.
Innosetup does not do what I'd call a rollback. Case I tested was installing a newer version of a file over an older file, when cancelled IS displayed a box saying 'rolling back changes' however the newer file was still present (old file gone).
NSIS does not support automatic rollbacks, you have to code it yourself.
InnoSetup, however, does provide automatic rollback support. Special care needs to be taken to invoke it if you are using special scripts or hooks, but a simple install will have it "for free."
We have a usb device and the drivers (.inf, libusb.dll, libusb.sys) and can install it using Windows' Device Installation Wizard (by pointing to the .inf file). However, we need to install the drivers without using the wizard (passively, so the user doesn't need to do anything). Does anyone know how this can be achieved?
You added the "installer" tag, so I'm assuming you're talking about some kind of installation package, like Windows Installer, InstallShield InstallScript, etc.
If that's the case, you should probably use Microsoft's DIFx framework.
DIFx makes it easier for you to create
high-quality driver packages,
customize the installation of driver
packages, allow the installation of
driver packages in combination with
application software, and use the
standard Windows APIs and installation
tools. DIFx also makes it easier for
end users to diagnose device and
driver problems. End users can be
confident that, if necessary, drivers
can be uninstalled or rolled back.
I've used DIFx from both Windows Installer-based installs and InstallScript installs. Very user-friendly, easy to debug, and effective.
My colleague came up with an answer that is working very well. It appears that, unless you hardware/driver combination is WHQL signed, the Add New Hardware Wizard will always appear in Win XP. However, with the following method it is possible to have the "Search" button in the wizard find your driver automatically. In Windows 7, there is no prompt and the device installs just fine. You'll need to watch out on 64-bit machines, though, as they have much stricter signing enforcement.
So here is the relevant excerpt from the whole document:
Use the DIFxAPi merge module. (Read a good introduction to drivers in Windows, the use of INF files, and DIFxAPP.) The DIFxAPI merge module is included in the WDK in the ‘WDDK//redist\DIFx\DIFxApp\MergeModule\’ directory. The merge module can be included in an MSI package and can be set to install multiple device drivers. Here are the steps to create an MSI with the DIFxAPP merge module:
In the setup folder, create a separate directory in the Application Folder for the driver package and add the driver files to the folder.
Add the DIFxApp.msm to the setup project.
Build the setup
Use Orca to edit the MSI database table and add the INF component to the DIFxAPP merge modules table.
The Orca installation is included in the Windows SDK in the ‘C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin’ directory. (The Windows SDK can be downloaded from Microsoft)
Run Orca and select the MSI package that needs to be modified.
Read part 5 for automation.
In the ‘File’ table, locate the INF file of the driver package you would like to install and copy the Component value.
Create a new row in the MsiDriverPackages table. Add the Component value into Component field. The following flags can be used (although some are ignored by Windows 7):
0 - Not set (default)
1 – Force installation of driver, even if it the currently installed drivers is
a better match than the driver being installed
2 – Suppress message box telling user to plug in devices after the driver
has been installed.
4 – Suppress adding an entry in Add/Remove Programs for driver.
Driver will be uninstalled when main application is uninstalled.
8 – Install unsigned driver packages
16 – Remove driver binaries during uninstall.
Save the MSI. In order to automate the process, the editing of the MSI database can be recorded to a Transform and then the Transform can be applied in a post build process.
Open the MSI in Orca.
Select Transform->New Transform
Complete steps 3 and 4 in the above directions.
Select Tranform->Generate transform and save the transform.
Add the following line to the post build of the Setup Project
MsiDb.exe -t transform.mst -d $(TargetDir)\DriverInstall.msi
Note: MsiDB.exe comes with the Microsoft SDK and is located in
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin
If you get an error installing from the MSI (e.g. I got error code 2356 which ended up being due to an invalid Flag value), use Orca's Validate function to see if there are any errors. EDIT: Fixing these errors still has not gotten rid of the error. I remember reading that inf files should be in their own sub-directory, but that didn't fix my problem either.