Did you try disabling/removing UninstallTool.exe as Leo suggested?
We've installed on that combination without any issues with the installer.
NOD32/ESET was still running according to the logs, so it is possible it's involved, perhaps if configured differently to what has been tested so far.
The first thing I would try personally would be completely removing UnistallTool from the machine. If it is wrapping installers then it could be the cause of all of the problems.
I'd also run the Opus uninstaller (if any exists yet) and wipe the installshield information for Opus (as per the FAQ; don't delete anything that isn't part of the Opus installer) before doing a test without UninstallTool, to give the installer the best chance of getting the right default folder etc. when run in a normal way.
I did not try installation with a completely deinstalled Uninstall Tool so far. Reason for that: I don't want to lose all the deinstallation information logged with it. And there seems to be no way to export (save) that data before de-installation.
Personally, I don't believe in Uninstall Tool causing trouble during installation. It's a lightweight, simple tool just logging the installation process. It writes no data itself or blocks any files/folders. So it should have no impact at all... In the past, it was working stable and reliable even during complex installations, e.g. Microsoft Office.
But to be on the safe side, I also tested Opus installation without any logging. This means that Uninstall Tool wasn't active at all. If activated or not -- the result is always the same.
Using Uninstall Tool, I'm able to delete the Opus installation leftovers quickly & efficient.
Finally (and to be complete), I attach some more screenshots of my user temp folder and digital signatures of installation file.
Digital signatures 1 + 2:
User Temp Folder Permissions:
There's no uninstall information in windows control panel.
As shown below, Uninstall Tool wipes its logged data after Opus setup procedure ends:
Uninstall Tool Installation Log.txt (33.9 KB)
This may be interesting for you because it shows the written data until installer crashes.
Custom uninstallers that interfere with the standard installers can mess up those installers/unisntallers, and cause more problems than they solve in our experience. We don't have any experience with this particular one, so it might be fine, but if I was having problems with an installer then that kind of tool is the first thing I'd investigate, and we can definitely see it getting involved in the logs.
Maybe it has a way to back up its settings. (I'd hope a tool designed around making other uninstallers better in some way had thought about the issue of having to uninstall itself temporarily!)
Hi Jon, hi Leo,
I checked Uninstall Tool and, unfortunately, didn't find any feature to export uninstall logs.
I must explain that The Process Manager logs I sent you before inevitably contain Uninstall Tool entries because the Tool was logging in the background then. Sorry, I should have mention this earlier...
Nevertheless, I'm meanwhile totally convinced that Uninstall Tool or ESET are NOT the problem: I started several new trials to get Opus installed, and during this procedure I tried to eliminate ANY potential influences (AV, firewall, background services, logging tools etc.). For example, Uninstall Tool was COMPLETELY terminated (no background service or task running).
I'll send you new Process Manager logs showing this "undisturbed" installation. Unfortunately, it resulted in the same damn error message
For this, I'm quite sure the problem has to be found somewhere else.
The only thing I was wondering about: When I check the system partition properties (SSD), "TrustedInstaller" is shown as the owner, and parts of the volume seem to be write-protected and/or hidden. I know about Windows security mechanisms, so this is probably normal? All the other software works fine despite...
Thanks for the new logs.
The symptoms seem to be the same: The installer works normally until it's time to run an .exe file, then instead of running it it aborts.
I thought of something to try:
- Open a command prompt, and CD to where the installer is.
DOpusInstall.exe /extract_all:"OpusInstall"to extract the installer contents to an OpusInstall subdir.
- Copy (copy, don't move; that could be important) the OpusInstall dir into
- Go there and double-click the
Does the Setup.exe launch OK from there? And can it then get further than it did originally?
Thanks for your advise. I'll give it a try and report what has happened!
See you tomorrow (it's 0:45 AM in Germany, so I gonna get to sleep...)
bad news: Setup has aborted again -- same game as before
As recommended, I copied manually extracted setup file folder to my User temp folder and started from there, not using Uninstall Tool.
[Same result when installing from another folder (after copying, not moving files there)].
Hm... it's really crazy...
Yesterday I installed another 64-bit software without any problems. Same success with Microsoft Office and many more programs.
Must be a weird bug in Opus installer -- or an odd combination of things (Installer can't deal with my Windows settings; or an installed Windows update blocks something?).
Did you receive similar support requests with this issue? There should be many clients using latest Windows 10 build, having the same effects...
Like before, I'll send you Process Monitor logs.
Additionally, the log of Uninstall Tool showing files Opus installer created during installation.
Remark: Surprisingly, folder C:\Program Files\GPSoftware\Directory Opus is empty after installation terminates. Again, I had to force setup to use this folder, not C:\Program Files (x86)\GPSoftware\Directory Opus.
In case this may help:
I encountered the exact same problem ("catastrophic error" and all that). I couldn't install 12.11. (Tried tweaking public desktop folder permissions etc and it didn't help) So I deleted my dopus folder and went to the page for 12.10 (by googling "dopus 12.10") and downloaded it. And it installed without any problems. Then I found out (by checking the version number etc) that what I ended up installing is actually 12.11. What's going on? Well, in my download folder there are two installers. They are of the same size (54.7MB). Why does one install and the other doesn't? It turns out the only difference is this...
In other words, the file that successfully installed came with the compatibility mode (for win7) checked. Then I remembered that, when a couple of months ago I downloaded dopus trial and tried to install and couldn't, this was the exact setting I tweaked which allowed me to install it. My windows version is 10 (1809).
Thanks for your interesting post. Glad to hear that I'm not the only one... Got the same Windows 10 build (1809).
I didn't test your solution yet. First of all, I've got some questions about it:
(1) Did I get you right that the Opus 12.10 installer contains Opus 12.11 in fact? Sounds really odd... together with the fact that both files have (exact?) equal size.
(2) In 12.10 file properties, the compatibilty checkbox was already activated by GP Software?!?
(3) Is it possible to install 12.10 version without marking that checkbox? (I don't want to run Opus in compatibility mode and the support team told me not to do).
(4) Did you have the same problem that Opus 12.11 proposes wrong installation folder (despite 64-bit OS)? The same with 12.10 installer?
Might be a hidden bug in 12.11 installer, as supposed in my last post. Or one of these mystic faults caused by Windows 10 October Release (according trade press, there are a plenty of them).
Hi Workaholic, that's what I downloaded from this page (Directory Opus 12.10). I was expecting it to be an 12.10 installer, but it turned out (I think) to be 12.11. In fact, I just checked and the download url on both the page for 12.11 and 12.10 are the same, so I guess they always point to the latest version. Hmm. I'm not sure what's going on. Anyway, I initially downloaded 12.11 via "Check for update", so that could be where I got the file with the unchecked compatibiliy box from.
Anyway, re: (2), yes absolutely, one of the two files came with the compatbility boxes checked. That's the one that ended up installing.
Re: (3), on my machine at least, I've never succeeded in installing dopus without having the compatibility checkbox checked. I should also clarify that, although I installed dopus in compatibility mode, it (dopus.exe) does not run in compatibility mode. The app runs just fine after installation.
Re: (4), no, I have not had that problem. It's always "Program Files" and not the other one.
None of the compatibility settings should be needed, and if they get applied to the program itself they could cause the wrong Explorer Replacement method to be used.
If a previous install was done with compatibility settings on, it could cause later updates to only work if the same settings are on, which might be what has happened. We strongly recommend never turning them on, at least on a working system.
If things are working then I guess it's worth a try, but something somewhere is messed up on the system if they are needed or if the installer thinks it should put the program in the 32-bit program files folder.
We have another workaround to try which I'll send shortly (a way to install the update without using InstallShield), but at this point I think something is wrong with the Windows install for these problems to be happening. We don't have any other similar reports, and thousands of other people are using the installer without (reported) issues.
(In the longer term, we are also probably going to ditch InstallShield as it is so opaque at times when there are problems.)
That makes sense. It could be what happened in my case.
I'm not sure what is it about my original OS that made turning on compatibility mode when installing necessary. But I do a lot of tweakings of my windows (registry, group policy, services ... I also moved the location of my desktop & downloads folder. Also, I'm a big user of hardlinks, many of my files have 2 or 3 reference counts - that's often been a source of problem for apps), so I'm accustomed to apps failing to install/run because of some settings aren't as they assumed them to be. No complaints on my end.
(Anyway, fwiw I tried to install the update multiple times. Everytime it fails, I would still be able to run dopus.exe to launch dopus 12.10. Until I attempted (a couple hours ago) to install the update again, and this time the error proved genuinley "catastrophic" (lol), since I was no longer able to run dopus because the program says (irrc) "couldn't find the english language pack" and exits upon launch. That led me to try and download 12.10 and finally solved the problem by luck)
Hi Porpoise, Hi Leo,
thanks for your discussion with its helpful hints.
Of course it's possible that's something wrong with my Windows. Not very likely, because it's a pretty fresh Windows without any sensitive user modifications or many other installations. And, as mentioned, I was able to install other x64 programs using InstallShield without such issues.
So it keeps mysterious. Maybe everything works perfectly when you install Opus on older Windows 10 builds (e.g. 1803) and update Windows later on to 1809.
Can you confirm Porpoise's statement that Opus 12.10 and 12.11 setup files are equal?
I'm looking forward to your workaround (thanks in advance!) and will stay tuned...
As Porpoise said, the URLs he used for both downloads are literally the same.
I wouldn't say your Windows install is in a fresh state as it has a lot of things installed on it, including one thing whose entire purpose is to monitor and modify how (un)installers behave.
No issues here running the installer on Win10 1809, both a fresh install and an upgrade from 1803. Whatever is happening is quite strange, especially combined with the wrongly detected program files dir.
Believe me or not:
Finally, I made it work. Directory Opus 12.11 x64 is running!!!
After many, many attempts and uncounted hours of researching & testing...
(I even was close to get back to my old software solution. )
I tried Porpoise's workaround, used the archived Opus 12.10 setup (which is 12.11 in fact), started installation... and It ran through to the end -- as if nothing had ever happened before.
(The wonder was logged by Uninstall Tool).
To me, it's obvious that there must be something wrong with the "official" 12.11 installer, which failed dozens of times. The "older" 12.10 version succeeded at the very first time!
@Porpoise: Thanks a lot for your perfect tip!
Here's the proof.
They're exactly the same file.
You could have a look at their checksums to know for sure, but the only way you could have 12.11 installed is if you used the 12.11 installer and there's only one version of that that we've released. The link in the "new version" posts always downloads the current version, not what was current at the time it was posted.