Upgrading from 12.13 to 12.14 the program has been deleted by the installer and I get a message:
Error Number:0x8000FFFFDescription: Kernel\serviceProvider.cpp (121)
Setup will now terminate
What can I do to get my installation back?
Thank you
Upgrading from 12.13 to 12.14 the program has been deleted by the installer and I get a message:
Error Number:0x8000FFFFDescription: Kernel\serviceProvider.cpp (121)
Setup will now terminate
What can I do to get my installation back?
Thank you
Sorry that you're seeing this problem with 12.14.
Please try everything here:
If you have already looked there, please see the last few suggestions, as I've just added some additional ones based on threads from a few months ago where people had similar problems. (These usually turned out not to be due to the installer, but due to something else on the system not liking the installer being something new, e.g. antivirus killing an unrecognised process.)
Juan, please email me directly with more details and we can discuss possible solutions. email me greg@gpsof...
Juan,
Just a thought. Are you trying to use Run as Administrator with the installer rather than just double-clicking it? As with Opus itself, this is a no no. Just run the installer as normal.
it doesn't work either. I going to reinstall windows and I'll tell you. Thank you
Have you tried everything in the guide I linked above?
Each thing is worth a try even if the error messages are slightly different, since sometimes InstallShield gives different errors for the same underlying problem.
I am having the exact same issue.
Wish I could go back to 12.13 as that worked perfectly. Now I have no functional system.
Which things have you tried so far? The solution may be in the guide I linked.
The 12.12 installer is here (and may be better than 12.13):
If you find the same issue happens with that as well, the issue may not be the installer but something else that has changed on the system.
The issue could also be that your antivirus is not recognising the newer version of Opus or the installer and is killing the installer part-way through "to protect you" but not telling you what it's doing. That's one of the things mentioned in the guide I linked, and has been causing problems for at least some of the people seeing this problem.
Thanks for linking the 12.12 installer (the 12.13 link just downloads the 12.14 installer). It didn't work though.
I've tried everything that is on that link you posted. It was a PITA to delete the SysWOW64\Installshield folder, but after taking ownership & faffing about, I eventually did it. Deleted everything in %TEMP%. Ran CCleaner just to make sure there were no leftover bits. I have disabled antivirus (Malwarebytes).
One thing I've noticed is that it tries to install in to C:\Program Files (x86) folder instead of C:\Program Files (which it used to do).
I work at home, and this is my main PC. I need to get this working before tomorrow as Easter is almost over. At this point, I'm frustrated enough to wipe the whole partition and start again... but would really like to avoid that if possible.
I also followed the same steps, and the result was the same; finally, I decided to reinstall windows as when I deleted InstallShield some other programs begun doing weird things.
I know it is painful when you work at home as I do, but in the end it was the quickest solution
I don't want to drag this thread way off topic.
See How can one end up with a non-functional system by upgrading Opus for a comment which may or may not be of interest,
That at least tells us it's something that's gone wrong on the system rather than the installer itself, which is useful to know.
If anyone who is still seeing this problem wants to make and send us some Process Monitor logs we can see what they indicate. In the past we've seen this issue caused by part of the installer being killed the moment it runs, probably by antivirus (but we aren't sure). But it also seems that InstallShield can produce similar error messages for various different problem causes, so it may be different causes on different PCs. We're happy to look through logs to see if we can help with a particular machine, or if it points to something we might be able to change at our end to cope with whatever is going wrong.
Knowing which antivirus and registry cleaners (and similar) people experiencing this have could also be useful, in case there is a pattern. (Sometimes those tools can cause problems even when disabled, since they sometimes still install hooks but configure them to do less rather than remove them.)
OK, I have managed to "fix" this.
I didn't re-install Windows, as that would have been too painful & too laborious to do.
Instead, what I did was I went into Control Panel\User Accounts, and followed the links there to create a new Local account, to which I gave administrator rights. I then logged into that user (just did Switch User, no need to log out) and, once it had set itself up, I opened Explorer and ran the DOpus 12.14 installer that I downloaded a few days ago.
Went through the process of installing (which went without a hitch), ran it, then logged out.
Logged back into my own account, and hey presto - Directory Opus is back.
Note if anyone wants to try this, feel free, but to be clear I had performed all the previous steps (deleting Windows\SysWow64\Installshield folder, disabled antivirus, cleaned %TEMP%, etc). I also renamed the Program Files (x86)\Common Files\Installshield folder. I don't know if these previous steps helped the installer to work better or not, but it did work.
In your original account, was/is the TEMP folder in the default location, not moved to another drive/folder or anything like that?
Normal place, I haven't changed it.
C:\Users<MyUser>\AppData\Local\Temp
Thank you, it looks like a solid and smart solution.
When I also performed all the previous steps mentioned (unfortunately not your solution), except renaming the Program Files (x86,) my Printer lost its connection with the PC only for scanning; I reinstalled the drivers with no success, I then tried to restore my system with the latest image I had, without progress on solving the issues, it is then when I decided to upgrade my SSD and reinstall W10 64Pro
Thanks for this out-of-the-box-thinking solution - it worked for me too, although I didn't need to go through the process of deleting the Installshield folder, disabling antivirus (I use standard Windows av), or completely cleanup the TEMP folder. I merely removed all Directory Opus files and folders. All my options and preferences remain.
One thing, for the new user installation, the installer offered the correct install directory (C:\Program Files\GPSoftware\Directory Opus) rather than Program Files (X86) which it the failed install insisted on.
I've spent the whole day combing through Process Monitor logs from an affected machine, and comparing it to ones I've generated of successful installs. Unfortunately, I don't have anything solid.
It looks as though the installer is being told by Windows that it is on a 32-bit system, but I cannot find any information on how that could even happen. Maybe it is something the AppCompat toolkit could do, but if it is it's still not something that's exposed without installing special tools. It cannot be done via the normal Compatibility property page.
I found that if you make the installer fail to load some of the DLLs it writes to temp (e.g. ISRT.DLL), like permissions or antivirus might do, then you get a similar error message from InstallShield (ServiceProvider.cpp etc.), but it happens much earlier in the install, and it doesn't cause the unexpected switch into installing the 32-bit version.
Reports in this thread say the installer works if run from a new Windows account on the affected machines. That suggests the problem is somewhere in the user profile. But I cannot see anything coming from HKCU in the registry or C:\Users in the filesystem that looks like it should cause this kind of issue, or involves compatibility settings or similar. Very little involved with the installer comes from account-specific data/environment.
One exception is the permissions on the TEMP directory. I tried some TEMP permission combinations like denying execute access, and got errors similar to if I forced the installer DLLs to fail, but nothing identical to what is being reported. Maybe I just haven't worked out the right combination of permissions to make it happen.
It could be something antivirus is doing (modifying or causing the DLLs in temp to fail to load), but I'd expect that to behave the same in a new account on the same machines, so I'm not sure about that theory.
One random thing that's worth a try: Rename the installer to something else, and run it from a different folder as well, in case the name or path are triggering something on the system.
Another thing is that the program you launch the installer from could matter. Launch it from File Explorer, if you aren't already, to rule that out. Running the installer from anything else could mean compatibility flags or other environmental details of that process are passed on to the installer.
Failing all else, for those affected by this, it does seem that running the installer from a new Windows account fixes things (at least temporarily) and gives you a working installation of Opus in both the old and new accounts. I am not sure if that then fixes things for subsequent updates done via the original account, as it's still not something we've been able to reproduce on any of our machines.
In the longer term, we plan to replace InstallShield entirely here with something that will produce better error messages and be easier to debug when it goes wrong.