-
me97mlg:
Your logs show that something is killing the installer's secondary processes (ISBEW64.exe) the moment they are started. This indicates something very low-level, most likely anti-virus or part of the OS configuration itself, which is stopping the process from starting.
InstallShield extracts ISBEW64.exe to the temp directory and runs it a few times during the course of the installation. On a normal installation, this is what the startup of the first instance looks like, and it carries on running for a few seconds (sometimes in parallel with other instances):
You can see it loads ntdll.dll (the main Windows DLL, always loaded first), then goes on to load some registry settings and several other Windows DLLs.
However, when this is attempted in your log, it seems to be killed during or just after the ntdll.dll load, and we can see it happens each time ISBEW64.exe is launched by the installer, each one failing instantly:
Since something is killing the process before it can properly start, I can't say much more and you may need to investigate your OS settings and antivirus. e.g. If your OS is configured to not allow .exe files in the temp directory to run, then that could be causing the problem (but would also cause a lot of other InstallShield installers to fail, I would expect).
Antivirus logs and the Windows Event Viewer logs may contain some useful information if you check for events around the same time as the installer was run.
-
matcat:
Your logs show something quite different. The installer seems to get a lot farther and looks like it is working in general, but there is one very strange thing going on: You are on a 64-bit version of Windows, and the installer is installing the 64-bit version of Windows, but it has chosen to put the files under C:\Program Files (x86) instead of C:\Program Files.
That may not be part of the problem but it's definitely fishy. I recommend uninstalling Opus if any previous version is installed, and then re-downloading the installer. Make sure no compatibility settings are turned on for the installer, and run it again by double-clicking it from the Desktop. (Avoid launching it from anything else, in case the launcher is causing some part of its environment to be inherited by the installer).
Note that uninstalling Opus will wipe the Opus config (if any). If you need to back it up first, see here. (If it's the first time Opus is being installed there won't be any config to worry about.)
Please also try the suggestions in Problems installing Opus if you haven't already.
Hello Leo.
Thanks for the information. Now I understand what's wrong. We were hit by ransomware a few month ago forcing us to limit the possibility to execute installers in the temp directory and that's probably what's happening here.
I'm however confused, because we have the same limitation in our Win7 enviroment and in win 7 I have now problem installing Dopus. This problem occured when we shifted to Win 10. Is the installer working in different ways in Win7 and Win10?
Now I have to talk to the people that knows Windows inside out to see if they can help.
Thanks for all help!
You can change TEMP directory - eightforums.com/tutorials/23 ... ndows.html.
After DOpus installation you can revert to default values.
It works the same in both. Must be a configuration difference between the two setups. (Maybe the Win7 setup allowed signed executables but the Win10 one doesn't allow any at all, or similar?)
It must be something like that. For me the problem is now solved, there was a way around the limitations in the environment when knowing what to fix.
What got me confused to start with was the strange error message. Normally when this protection funktion strikes in, I get a message saying that I am "prohibited to install this program due to a group policy" and the installer never starts. And since Dopus installer worked in Win7 I didn't see the problem from the right perspective.
I followed the instructions for removing the InstallShield folder and the other subsequent files as well as tried redownloading the installer and attempting to install again. I am not running in compatibility mode. No joy, same error. I don't currently have directoryopus installed, I purchased the humblebundle and this is the first time I've tried to install the software. As far as why the installer is attempting to install to the x86 folder, I'm not sure. Any other suggestions?
I don't see a way to edit my previous post, however I wanted to add I checked the corresponding registry values for the ProgramFilesDir and ProgramFilesDir (x86) and they are correctly assigned to their respective locations.
There may be some registry entries that shows default path for Opus wrong. Personally I don't like when programs install in two separate folders (I think it's useless in 99% cases and directory name doesn't determine type of execute file; I also like to see all my programs in one folder), so I created junction "progs" that point to "Program Files" directory, because some programs install in x86 folder anyway, no matter if you force them to install in main "Program Files". If you want to force programs to install in "Program Files", make junction (junction c:\progs "c:\Program Files" - technet.microsoft.com/pl-pl/sys ... 96768.aspx in case that your system doesn't native support this) and select c:\progs\ as installation directory.
If you have no Opus installed, check registry for "Program Files (x86)\GPSoftware" - maybe there is some old entry with that wrong path somewhere.
Another strange idea is to create new windows administrator account, switch users then try to install Opus (for all users).
All my advices are just guessing, unfortunatelly. I'm just want to help by give some ideas.
I don't have any solid ideas beyond the ones you've already tried, I'm afraid.
I've spent a long time comparing your log to the log from a successful install on Windows 8.1 (64-bit) and, apart from the install path oddity, everything looks about the same up until the point that the uninstaller information is recorded into the registry. (I'm not sure if that is actually important, though. I can't see any errors in your log showing that it tried to write that information but failed, so it seems unlikely it is the cause.)
The log shows the Windows antivirus scanner working through everything the installer is writing just after it writes it, which might be significant. Disabling the scanner may be worth a try. A different installer may also be wroth a try, just in case there's something peculiar going on with a particular file/signature in the one you're using.
(I recommend the 12.2.4 beta installer linked in my signature, if you want to try a different one. It's proven to be a stable release, and the only reason it's still called a beta is there are some English strings that haven't been translated to other languages yet.)
Going back to the install path oddity, was the system migrated from 32-bit to 64-bit at some point int he past, using one of the tools that attempts to do that? That might explain the confusion there.
I also noticed some registry access to do with application compatibility flags, which could be causing both the install path oddity and the overall problem, but may also be perfectly normal. It's hard to tell from what's in the log. Those settings are in the registry but I'm not sure if there is a good way to view them. If you're comfortable using RegEdit, you might want to check under these places:
-
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags
- Compatibility Assistant
- Persisted
- Store
- Layers
- Compatibility Assistant
and the same HKEY_LOCAL_MACHINE equivalents
for any keys/values with DOpusInstall.exe or ISBEW64.exe in their names.
The ISBEW64.exe one in particular, since it's possible another InstallShield installer triggered compatibility flags to be turned on by the OS automatically for something with the same name.... It's quite a long shot, though.
Peterb's suggestion of trying the install from a different account is a good idea. Sometimes a profile or permissions problem can break things, where a fresh account allows them to succeed. (The program may then work from the main account, or it would at least give us something more to go on.)
The other installer and/or disabling antivirus would be the first things I would try though, since they are the most simple.
OK I figured out what the problem was. Quick answer, I had changed the location of my local user temp folder to a custom location by changing the environmental variable, as well as used a symlink at some point because moving the temp folder had caused me issues with installing nvidia geforce experience updates at one point. I can't remember exactly what I was using the symlink for but it allowed me to have the temp folder moved to where I wanted it and still be able to upgrade geforce experience without getting errors. I changed the environmental variable back to the default location and the dopusinstaller detected where to install correctly, being Program Files, and not Program Files (x86). The install completed without error after that. I had been trying to spare my ssd the unecessary writes but I'll just leave it at default at this point, being this is the second time I've run into trouble. Thanks for your time and effort in looking into this issue for me and I'm sorry to have used up some of your time on a likely rare issue. Have a good one.
Glad you got it sorted! And thanks for letting us know what the fix was. That might come in handy if someone else runs into a similar problem.
Same problem for me. But, im on Win7 64bit. I have my tmp and temp on a different drive (not C), its also an SSD. Why do I have to change my system just to make this program install? Surely this is a problem with the programs installer not our computers?
I have a code from Humble Bundle which I never used until they reminded me this week the code (allowing one-off install) is going to run out on May 1st. I guess you wont be fixing this in the next couple of days since it was first reported almost a year ago 
The deadline is only to redeem the Humble Code, not to install the program. If you haven't already, I believe you can redeem the Humble Code here. If you have problems, please email Sales and I'm sure they'll help there.
For the installer, Opus uses the standard InstallShield installer, so any problems with the Temp folder I would expect to also affect other things. It may not be that the temp folder was moved, but something to do with the permissions in the new folder, using symlinks (if you've done the same as the earlier poster), or not updating all of the environment variables and other system settings to point to the new folder.
If the temp folder is moved then I'd expect things to work OK, as it has not always been in the same place in every version of Windows, without problems, and its path in modern versions of Windows depends on the account name. So InstallShield definitely doesn't have the temp path hardcoded, or it would not work at all.
It's possible InstallShield needs temp be on the C drive, if it assumes it can rename things between the temp folder and other C drive locations, but I can only speculate. We have never seen the issue on our own machines to investigate it, nor had more than the three reports (including yours) in this thread over the years, or full knowledge of how those machines were set up.
If you open a Command Prompt and type set t, where does it indicate the TEMP and TMP env-vars are pointing? Do they point to the correct location on your machine?
What are the file/folder permissions, and (account) ownership, on the temp folder?
Thanks for the suggestions, I tried to register the code via the website with the following issues:
- the code is too long to fit in the form. So had to take out one of the hyphens
- it rejects the form saying 'The Boxed Product Code you provided was either not valid or has already been registered.
Resonably sure it rejects it because the form you linked appears to be for the boxed product only
What do you mean by the instruction saying 'Do they point to the correct location on your machine?'. I can point my tmp and temp anywhere I want? Do you mean does the location I point my variables to, actually exist?
When you copy and paste the code make sure there's no white space before or after it.
1 Like
Are the variables consistent with where the folder is? Windows has several independent settings that point to the temp folder and it's possible to change some and not all of them, which will break things which use one method to find the folder instead of the others.
The permissions on the temp folders and files within them are also vital. For example, if SYSTEM doesn't have access to the temp folder then many installers will break. The ownership may also be important, from what I've read.
It's also worth keeping in mind that Windows has multiple temp folders. The user-specific temp folders and the Windows/system temp folder. Different accounts will use different folders, and should have independent env-var/registry settings pointing to them, and the folders will be permissioned differently and owned by different accounts.
(I would also ask myself whether the possible benefits of moving the temp folder to another drive are worth the potential to cause problems due to a non-standard configuration or missed setting/permission. It's your PC and up to you if that trade-off makes sense.)
See Jon's post just above mine regarding the licence code.
Managed to register the code via the website (thanks Jon for the suggestion), must have been white space in the code
No joy with the temp/tmp
'set t' shows locations which do exist and it is where I expect the files to go (ie to folders on secondary SSD - not on C)
System has full security control settings on both directories and subdirectories
I encountered the same problem when installing Opus 12 and Autocad LT 2018 on HP Spectre 360x 15".
In the forum for Autocad I found the described solution that helped me for both installations:
Hi! I am having the same issue as quite a few others seem to have had, with the error 0x8000fff coming up every time I try to install the program. I have attempted all of the suggestions listed here, to the best of my limited ability, and have no idea what else to try. I created a log file using the Process Monitor program, as suggested, and would like to send it to whoever knows how to read the result. Would you please let me know who I should send this to? Thanks in advance!
Please save the log in .PML format and then zip it, and email it to crashdumps@gpsoft.com.au and we'll take a look.