I am trying to uninstall Crystal Report for Visual Studio 2011, and install Crystal Report for Visual Studio 2019. I got the error message of "Error applying transforms. Verify that the specified transform path are valid." when uninstalling the program. Therefore, the newer version of Crystal Report for VS 2019 can't be installed.
I searched around and some posts says about windows registry entries caused the problem. I can't find out a solution on what to do.
Highly appreciate your response.
Crystal Reports: I am wondering if you have installed from a network share that is no longer available, or one where the UNC path specified to your transform is blocked or in other ways incorrect. What you need is a proper log file. Please see below. And have a quick peek here: https://apps.support.sap.com/sap/support/knowledge/en/1220433
There are also some issues with secure transforms and complications arising from this and newer Windows settings and security features. Maybe have a quick look here. Just a few links on the topic.
How many machines do you see this on? Just your own?
Preparation: A couple of things first:
Reboot: Do a reboot before attempting the next uninstall. Just to have a clean slate. Allow system to settle after reboot (give it a couple of minutes to settle down).
Corrupt installation files: Re-download your new setup to make sure its installation file is not corrupted. Try to malware scan it too. And finally set it unblocked as shown here.
Admin Rights: Second, make sure you run with proper admin rights? Run the msiexec.exe command from an elevated command prompt. Please launch an elevated cmd.exe (right click => run as administrator).
Anti-Virus: Disable your anti-virus first to prevent any locks from failing your uninstall.
Debugging "Ideas Lists": Common causes of setup runtime issues
Logging: Now the most important. You must also ensure proper logging for the uninstall effort. You can either use logging by policy
or define it at the command line level. It would be best to enable the
logging policy so the log file is automatically created in the tmp
folder. Please see this answer for more on logging.
When you have done the "Preparation" above, please run the
uninstall and create a proper log file. Here is the command line
(prefer the policy):
msiexec.exe /x "mysetup.msi" /L*V "C:\Temp\msilog.log"
Please open the log you created (or get the log from the temp folder
if you have logging policy enabled). Then inspect the log and match
against this sample log here:
https://www.itninja.com/question/transform-issues
What do you see? Just read line by line and don't be intimidated by
all the "line noise".
Common Technical Issues: If you have problems with all other MSI packages and their operation, you could have a bigger problem. Then you should rule out some runtime issues. Note that some issues are commonly caused by malware (or just technicalities that occur randomly sometimes):
Visual C++ Runtime - reinstall it. There are many versions. See what your package needs. The latest supported Visual C++ downloads.
Unregister / re-register msiexec.exe (can be necessary because of malware or normal technical glitches).
Run chkdsk.exe and sfc.exe to check for file corruptions and corrupt OS files.
Microsoft FixIt: You can use the Microsoft FixIt method as a last resort to clean out your existing installation. This generally works (unless you have hacked too much already), but is not ideal: http://support.microsoft.com/mats/Program_Install_and_Uninstall/ - this approach does not clean up or uninstall, it just unregisters the installed package and leaves all its files and registry settings in place. You can try to install the new version, but some interference issues are likely with the garbage left behind. Yes, you can try to clean up manually, but I would just try to overwrite first.
Links:
What is the root cause of "Error Applying Transforms. Verify that the specified transform paths valid"?
All About the Four Types of MSI Transforms
"Error applying transforms. Verify that the specified transform paths are valid."
Related
I have C/C++ application and I am trying to run cov-build and getting a warning “ NO FILES EMITTED”. Can you please help me as we doing the POC on Coverity for static code analysis.
C:\Users\Master\bamboo-agent-home\xml-data\build-dir\DEC-L11PROJ-JOB1>cov-build --dir cov-int IarBuild.exe MainApplication\EWARM\L11_P4_uC1.ewp -build *
Coverity Build Capture (64-bit) version 2019.03 on Windows 10 Enterprise, 64-bit (build 18362)
Internal version numbers: 2c0f9c8cf4 p-pacific1-push-35439.872
IAR Command Line Build Utility V8.4.8.6680
Copyright 2002-2020 IAR Systems AB.
Total number of errors: 0
Total number of warnings: 0
[WARNING] No files were emitted. This may be due to a problem with your configuration
or because no files were actually compiled by your build command.
Please make sure you have configured the compilers actually used in the compilation.
For more details, please look at:
C:/Users/Master/bamboo-agent-home/xml-data/build-dir/DEC-L11PROJ-JOB1/cov-int/build-log.txt
First, if you are involved in a pre-sales Proof of Concept (POC), then there should be a Coverity Sales Engineer assigned to help with the POC. That person's role includes providing instructions and information similar to what I'll offer below, as well as answering technical questions such as yours. There may have been a miscommunication somewhere. Get in contact with the Sales Engineer, as they will be able to help more reliably and completely than I can.
Now, what's going on? The primary purpose of cov-build is to watch the build process for invocations of compilers, and when one is found, compile the same code using the Coverity compiler (called cov-emit). But in order to recognize a compiler, cov-build needs to know its command line name, what kind of compiler it is, where its include files are stored, etc. This is accomplished by a helper tool called cov-configure that must be run before cov-build. If cov-configure has not been run, then no compiler invocations will be recognized, which appears to be the case for you, as indicated by "No files were emitted".
Synopsys has a page called CLI Integration Cheat sheet that gives these commands for use with IAR:
cov-configure --comptype iar:arm --compiler iccarm --template
cov-build --dir <intermediate directory> "c:\Program Files (x86)\IAR Systems\Embedded Workbench 6.5\common\bin\IarBuild.exe" sample_project.ewp -build Debug -log all
I can't personally vouch for these commands (I don't have IAR, nor access to the Coverity tools anymore; I'm a former employee), but something like that will be needed. Again, your assigned Sales Engineer should be able to help.
Finally, for new Coverity users, I recommend using the cov-wizard tool. cov-wizard is a graphical front-end to the command line tools, and has help text explaining the concepts and procedures, along with a convenient interface for performing them. There are several steps even after cov-build, and cov-wizard will walk you through all of them. Its final screen shows exactly what command lines it used in case you want to script them.
I have tried many of the common approaches(MSI, PowerShell) to silently uninstalling the following application:
MSI
$ReportViewer2012 = Get-WmiObject -Class Win32_Product -Filter "Name = 'Microsoft Report Viewer 2012 Runtime'" | Select-Object -Expand IdentifyingNumber
if ($ReportViewer2012)
{
echo "Unistalling: Microsoft Report Viewer 2012 Runtime"
msiexec /passive /x $ReportViewer2012 | Out-Null
}
Powershell
(Get-WMIObject Win32_Product -Filter 'name="Microsoft Report Viewer 2012 Runtime"').Uninstall()
Without any effect, I did however get a verbose log for the output(/L*V):
MSI (s) (20:84) [14:42:57:903]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (20:84) [14:42:57:903]: Note: 1: 1706 2: -2147483647 3: ReportViewer.msi
MSI (s) (20:84) [14:42:57:903]: SOURCEMGMT: Processing URL source list.
MSI (s) (20:84) [14:42:57:903]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (20:84) [14:42:57:903]: Note: 1: 1706 2: -2147483647 3: ReportViewer.msi
MSI (s) (20:84) [14:42:57:903]: Note: 1: 1706 2: 3: ReportViewer.msi
MSI (s) (20:84) [14:42:57:903]: SOURCEMGMT: Failed to resolve source
MSI (s) (20:84) [14:42:57:903]: MainEngineThread is returning 1612
MSI (s) (20:5C) [14:42:57:904]: User policy value 'DisableRollback' is 0
MSI (s) (20:5C) [14:42:57:904]: Machine policy value 'DisableRollback' is 0
MSI (s) (20:5C) [14:42:57:904]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (20:5C) [14:42:57:905]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (20:5C) [14:42:57:905]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (20:5C) [14:42:57:905]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (E8:EC) [14:42:57:906]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (E8:EC) [14:42:57:906]: MainEngineThread is returning 1612
This subject is discussed here but with no conclusion. I'm wondering what is causing the issue and how to resolve it?
Missing / Inaccessible Source
Just so it is clear, it is not normal behavior for Windows Installer to ask for the installation source for an installed product to allow uninstall.
Quick Fix? Maybe look under "Uninstall MSI" below for the Microsoft Install / Uninstall Tool
which you can use to try to resolve the situation with your un-uninstallable MSI package in a quick, automatic and - I believe - reliable fashion.
UPDATED: The Microsoft tool, should be able to resolve your problem. The rest of this answer is written in the spirit of "let's obsess over this" :-) and tries to explain potential causes as well as some other fixes.
Also see below for how to do verbose, debug logging to gather more "intel" for your particular uninstall / install problem (could pinpoint the exact culprit in the MSI - for example a specific custom action).
The likely, potential causes of your problem are:
Missing Cache MSI: The cached MSI that is supposed to be created in a protected, system folder during intial installation is missing - for some reason. Details explained below.
Missing Source Resource: It could also be that the uninstall process requires a resource that is missing on disk and prevents the uninstall from running.
The uninstall process will then try to resolve the source for the original installation media in order to get hold of the resource that is needed (binary?), and it then fails to do so because the original source MSI has been deleted and is nowhere to be found.
This generally indicates MSI design problems. The uninstall breaks and you are stuck with a catch 22 (can't uninstall, can't upgrade). See the Microsoft tool linked to below for a potential way to resolve this.
If an MSI design issue is indeed the cause (and certifiably so), you must try to work with the vendor for a reliable, future fix for their package - or it will obviously affect your own product's success and reliability. Goes without saying I guess.
Other Causes: A number of other, potential external causes are listed below ranging from anti-virus blocking, disk space issues, user / admin tinkering, system restore, etc...
The following log entry makes me suspect an anti-virus blocking issue, however a missing resource requiring original source resolution is just as likely:
SOURCEMGMT: Source is invalid due to missing/inaccessible package.
Since the anti-virus does not seem to block the full, downloaded MSI of yours from running, I am led to believe that the issue is a missing resource that the MSI is trying to erronously resolve and retrieve from the source media during uninstall. Likely a MSI design issue - will check more tomorrow.
Full, verbose, debug logging might provide further clues:
msiexec.exe /x {ProductCode} /L*vx! C:\Your.log (logging details from installsite.org).
The text below was written before deciding to suggest the above three primary candidate causes. Leaving in the content for reference.
Uninstall MSI
Microsoft Install / Uninstall Tool: there is a tool from Microsoft available for the case
where unresolvable install / uninstall problems occur: Fix problems that block
programs from being installed or removed.
The normal approach to uninstall an existing installation, is generally to use the product GUID of the product in question and kick off the uninstall as follows - silent uninstall with verbose logging:
msiexec.exe /x {00000000-0000-0000-0000-00000000000C} /QN /L*V "C:\My.log" REBOOT=ReallySuppress
Quick Parameter Explanation:
/X = run uninstall sequence
{00000000-0000-0000-0000-00000000000C} = product code for product to uninstall
/QN = run completely silently
/L*V "C:\My.log"= verbose logging at specified path
REBOOT=ReallySuppress = avoid unexpected, sudden reboot
You already have the list of other uninstall approaches (my favorite is section 3).
I am no good at Powershell, but here is an answer from earlier on its use to install / uninstall products: How can I use powershell to run through an installer? Maybe check that new Windows Installer PowerShell Module linked to at the top.
Potential Source Prompt Causes
The below is partially explained in the answer you link to above (section 12), but I will contextualize it here:
Cached MSI: Windows Installer caches MSI files in %SystemRoot%\Installer during original installation. This folder is super-hidden, you may need to show operating system files to see it in Windows Explorer. Windows Key + R + paste %SystemRoot%\Installer + hit ENTER. Read next bullet point before searching for your MSI.
Ranom, Hex Name: This cached MSI is assigned a random hex name and is used during maintenance and uninstall operations, and there should be no need to point to the original source MSI that was used to install from for any such operations. More details on this caching (Microsoft keeps changing how this caching works). Whatever you do, do not make any changes whatsoever inside this OS folder!
To find your MSI, hover over the random MSI names in sequence with the cursor, and a yellow pop-up should show you what product the MSI is for. Repeat until you find your MSI. Or...
You can also add the subject column to the Windows Explorer view to see a full list of product names. See this article for how to do this. Note that for localized systems it can be hard to find the right attribute to show, but if your system is English this is a great approach - full overview in seconds, no tedious "wait for hover pop-up".
In the olden days the Windows Explorer status bar also showed the MSI's product name - I am not sure it does anymore (View => Status Bar).
ResolveSource or Custom Actions: It is possible for this cache file to be missing for many, external reasons, but beyond external causes it is possible that the MSI in question is badly designed and specifically tries to resolve the original source by calling the standard action ResolveSource. I believe this could trigger the problem you describe. I suppose the MSI could also contain custom actions that could trigger the problem as well - I am not sure.
UPDATE: I downloaded the MSI in question, and I do not see any ResolveSource issues - frankly I am not even sure if this standard action can be used anymore. There are many custom actions though - several of which look suspicious. I can not install the MSI to test (lacking pre-reqs).
Missing Cached MSI: In some cases the cached MSI is missing in %SystemRoot%\Installer - either because it was never cached there during installation, or because it was removed or blocked by some later process or mechanism. Some possible causes (just theories):
Your anti-virus or security software could have quarantined the whole, cached MSI file. I have seen this problem of late. This could become a major problem as malware gets worse and security is tightened.
If you are low on disk space, I suppose weird problems such as this missing cache file could result. I would think you would be properly warned about the space issues though, but could the low disk space in turn cause file / disk corruption?
Beyond lacking disk space, disk corruption could also happen on its own for other, technicial reasons than disk space - obviously - and this would in turn certainly cause the missing / inaccessible cache-MSI. Malware is one culprit for disk corruption. Faulty I/O drivers another. Disk surface problems / flash wear as well. Bad security software intervening everywhere with faulty blocking. And the big one: power outage and new NVMe disks with massive cache capacity and no onboard capacitor power to ensure cache is committed if the power goes out. Disk corruption is inevitable. The list goes on.
In a related issue to disk corruption and disk space, some users try to redirect the MSI OS-protected cache folder %SystemRoot%\Installer to network locations or other partitions because their SSD system disk is out of space. Perfectly understandable, but this can cause complete failure for MSI operations. See this answer for the problem and some suggested workarounds.
Related to the previous bullet point, overzealous computer tinkerers sometimes delete system folder files that should never be touched (despite the folder being "super hidden" and difficult to access, it is still found). Some custom, third-party cleanup apps may also delete cached MSIs accidentally, as can custom, administrator cleanup scripts.
I have long suspected system restore to be a culprit when it comes to deleting cached MSIs, but I have not been able to catch the delinquent in the act yet!
I've got summary judgement ready, with system restore's name on it, should there be the slightest forthcoming evidence ("...burnt child, smells burnt").
Could system restore in combination with other problems be the cause? (file / disk / registry corruption?). It might have been previously, and the problem might have been secretly fixed?
Be careful with system restore - it is a source of mystery and weirdness. I have seen it delete my data files from the desktop. Why? Maybe use it against blue screens of death (driver failures) and malware only.
As mentioned above, I suppose a crash or bug towards the end of the product installation could cause the cached MSI to never make it properly into the cache folder, as could a power outage (for desktops).
Seeing as the caching would likely happen before the install process starts, this cause seems less likely, but I'll mention it. One would think the install would be incomplete, not the caching.
There could be complications when temporary files / rollback files are removed? And again: could system restore get confused about the file status? (a cache file present with a corrupted product registration? Remove it?)
For your own setups, repetitive installation and testing of your MSI can trigger weird edge cases (unlikely to occur "in the wild") where you see this lacking MSI caching phenomenon rear its ugly head. I have seen complications where identical package codes have been reused. Very technical - should not affect anyone but setup developers and / or their QA people.
And highly technical causes relating to the configuration of your system and network could potentially be involved triggering this problem - maybe particularly on (terminal) servers: custom group policy, custom privileges, custom ACL, impersonation contexts for scripts, etc...), but then you should generally see it for all packages. You need a real server expert to talk with sense about these issues - they may have very good reason to lock things down.
Some Links:
https://www.advancedinstaller.com/forums/viewtopic.php?t=34318
It appears as thought when you do a silent uninstall error's are suppressed as well, when I attempted to uninstall the package in the UI, I was presented with a dialog asking me to located the MSI file for the application. Not sure how it got this way but I fixed it by re-downloading the package and uninstalling it from there. Would be nice not to have to package a MSI with my powershell script just to uninstall an application, but right now I don't have a better resolution.
(NOTE: the following problem after appeared after the production server in question underwent system hardening):
I have a PowerShell module that contains the following line:
[OutputType([Microsoft.SharePoint.Publishing.PublishingPage])]
When I open a PowerShell console running as Administrator (as well as being logged in to the server as a sys admin), I get the following:
Unable to find type [Microsoft.SharePoint.Publishing.PublishingPage]: make sure that the assembly containing this type is loaded.
I am able to "force" the Microsoft.SharePoint.Publishing DLL to load with both LoadWithPartialName as well as Add-Type, but then I get the same error with regard to Microsoft.SharePoint when I try to execute my module.
Both DLLs are definitely in the GAC (version 14.0.0.0 as this is SharePoint 2010) and when I view permissions on the GAC, the permissions are sufficient.
As stated previously, the module executed fine previously, and the "Unable to find" error only started occurring after the server in question underwent some system hardening by a third-party. I have tried to investigate the issue from a permissions and group policy standpoint, but so far I do not have any leads.
I am able to somewhat reproduce the error in my dev environment if I completely trash the permissions on my GAC, but this does not truly reflect the situation in production, as the permissions in production appear to be more than sufficient for being able to "see" a DLL in the GAC.
Any help would be greatly appreciated.
You might have better luck with [Microsoft.SharePoint.Publishing.PublishingPage] ;-)
That said, for types that are not part of the BCL, you should use a string instead of a type literal. This allows the module to be loaded - at least - on a machine without sharepoint. That would look like:
[outputtype("Microsoft.SharePoint.Publishing.PublishingPage")]
As far as powershell is concerned, the constraint is the same.
In the end, right-clicking on the PowerShell icon and selecting "Import System Modules" was the solution.
When I changed my OutputType to use quotes instead of brackets, I then received an error that Get-SPSite was not recognized as a cmdlet (selecting "Import System Modules" resolved this error.) I then went back to using brackets for the OutputType and confirmed that "Import System Modules" was all that I needed.
I have an MSI package I maintain with Installshield 2012 Pro.
The package was created a few years again and requires periodic maintenance as new versions of the application is installs are released by our development team. This MSI has been used in many locations, on many machines without issue.
At one customer location, they've install about 20 copies of the application on 20 machines. Each machine is built exactly the same.
Periodically, for an unknown reason registry entries relating to that application go missing. Not all of them, a select one or two... the same entries always go missing.
We so far have failed to track the exact root cause, however one of our support engineers noticed the MSI repair dialogue appearing when they opened the application shortcut. Following this, the registry entries went missing.
On each instance of the registry entries going missing we have removed the MSI from the c:\Windows\Installer directory. On machines we've made this change too, the registry changes so far have not disappeared again.
This leads me to think the MSI is somehow removing the selected registry entries during the repair, but I don't understand how.
There are at least 50 registry entries under the same key as the entries that get removed. (these are created by the application not the installer)
The MSI package doesn't insert any keys at all during install
There are no custom actions at all
I only have one key file set in the whole MSI, and this is for a component installed in Windows\system32
None of the shortcuts are 'Advertised'
There appears to be a clear link between removing the MSI from the Installer directory and no further occurrences, but I fail to see what in my MSI could cause specific registry keys to disappear.
I realize the exact reason this this is subjective to my MSI or the customers systems, so as generally as possible I ask:
Why would Windows launch the MSI repair function, considering the above
Can an MSI alter the registry, considering the above
Is there anyway post installation of an MSI to disable the auto repair function for this MSI?
How should I alter the MSI to ensure auto repair doesn't occur?
Thanks
Start by proving whether the auto repair is related to your product. Check the application event logs for the component id that caused Windows Installer to kick off the auto repair. Then, if it's part of your installer, figure out why.
It seems unlikely that your MSI would alter the registry. Although you do not specifically say there are no RemoveRegistry table entries, it's hard to imagine any snuck in accidentally.
There are only bad ways to disable auto repair (some global, some involving not registering your installer). Avoid them.
First figure out what's wrong. Then figure out how to fix it. For instance if in step 1 you determine the component triggering auto repair is part of your install, perhaps set the logging policy on a machine where this occurs so you can get a verbose MSI log.
In one of the projects our team is working on, we are trying to make an automated deployment system for an existing desktop application. In order to do that we need to understand how InstallShield installs the application to begin with.
We have access to the InstallShield manifest, but there is an OCX file that we cannot figure out how to install manually (without InstallShield). This particular OCX file is set to 'Extract COM Information'.
Here's a screenshot:
The other OCXs in this application are self-registering, so they can be registered with Regsvr32.exe. But the OCX we are having problems with cannot be registered in that fashion.
How would one manually install an OCX file that is set to 'Extract COM Information' in an InstallShield manifest?
RegSvr32.exe calls the LoadLibrary API to load your DLL and then invokes the DllRegisterServer entry point inside your DLL. The code inside that function does the actual COM registration. If RegSvr32 is failing, that typically means a dependency of your DLL is missing or invalid.
InstallShield does all of this along with some really low level bit hacking to virtualize all of this and then harvest it. An old article on the subject is:
Spying on Registry Entries
InstallShield doesn't actually use this technique per say ( they have several techniques, most of which is not documented and various filters and transform engines to clean up the data ). If you are just looking for a way to do it without InstallShield, then look at Windows Installer XML's "Heat" command line tool. This can "harvest" COM metadata into WxS XML elements.
Also WiX is open source so if you are really curious you could go looking at their code.
As Christopher mentioned, InstallShield extracts COM information from your .ocx by seeing what it registers when invoked similarly to regsvr32.exe will invoke it. Its various forms of redirection (for capturing purposes) have the added benefit of working around several potential permissions problems while the file is registering in your build environment. However if I'm not missing the point of your question, it's "why doesn't regsvr32.exe your.ocx work on the target machine?"
This is a bit of a stab in the dark, as you haven't included enough information. While missing dependencies can cause this, I'm going to guess you only see this failure on Windows Vista/Server 2008 or higher. If this is the case, there's a good chance your application is trying to write to registry keys that are protected by Windows Resource Protection (WRP), or is being tripped up by a per-user typelib registration problem.
When a poorly behaved self-registration routine encounters WRP, it attempts to write to a registry key it lacks permission to modify, then fails the entire registration. I'm uncertain what happens to the keys it wrote before that point, but all ones after it definitely never make it to the machine. You should be able to confirm whether this is the case with a tool like Process Monitor.
What do you do if this is the case? Well, you can stick with an extraction approach like that of InstallShield (which you say you want to leave). You can fix the file to not attempt to write to protected keys (which you say you cannot modify). Or you might be able to use the Application Compatibility Toolkit (ACT) to shim things, but I don't see how you can generally do that downstream. Generally speaking, I would recommend fixing the file, or continuing to use a working approach.