I just upgraded from DOpus 8 - and in fact purchased more licenses.
Unfortunately, on trying to install on a machine that had lacked DOpus, the installer went along fine until the point where it began to copy files - and then abruptly vanished, with no error message at all.
As it all happened rather fast I'm not positive, but as I've tried multiple times and watched closely the last filename I saw before the failure appeared to be something like "stockcert."
This is happening on an Asus EeePC 901 running Windows XP Pro, SP3.
The digital signature on the installer is valid - and the same installer file worked fine on the machine I'm using now.
I tried doing a diagnostic startup with only basic services via MSConfig - and that didn't have any effect. (There are a lot of EeePC specific utilities and I thought one of them might be causing trouble.)
Any suggestions as to where to look would be appreciated!
That's a strange one... Most installation problems like that are caused by an incomplete installer that was only partially downloaded, but then it wouldn't work on any of your machines and the signature would be invalid.
(BTW, when checking the signature via the Properties dialog, you have to select it and click Details to verify it. If you don't then the Properties dialog may not detect a bad file. Seems very unlikely in this case, though.)
The best trouble-shooting suggestion I can think of is to run Process Monitor and see which files or registry settings the installer is accessing just before it exits. That may shine a light on what's going on.
You'll probably see a lot of noise from other programs when you run Process Monitor. Right-click on the names of the programs in the list (i.e. within the Process Name column) and you'll find the option to exclude that process so you can concentrate on the important ones.
(Don't exclude everything but DOpusInstal.exe, though, as it's possible the problem is happening when the installer runs something else.)
If you have trouble making any sense of the Process Monitor output, use File -> Save in the program and save the output to a log file, then zip it up and send it to me as a private message and I'll take a look at it.
Another idea (after thinking about a different installer issue):
If you've got any anti-spyware stuff, see if it logged anything about the installer. It's possible that the tool doesn't recognise/trust the installer and is killing it when it tries to perform a certain action.
(e.g. In the past we've seen Zone Alarm -- at least when configured in certain ways -- silently kill programs when they try to run another program or do an update check on the internet. The installer could do those things.)
From looking at the log and comparing it with one from a successful install, it seems like the setup process exited (or was killed) at the point where it was about to start writing files to Program Files\GPSoftware.
Check that your account is able to create some test files under Program Files\GPSoftware\Directory Opus, in case it's a file permissions problem.
The log also shows that avgamsvr.exe and avgcc.exe (AVG Anti-Virus and/or Grisoft Internet Security Suite) did something just after the Opus Setup.exe ended. It might be a coincidence & normal background behaviour of those processes, but could you try disabling it/them and see if that makes any difference?
Addition: I noticed another odd difference with how your installer is writing the files compared to how my one is writing them.
What's the MD5 checksum & filesize of the installer that you're using? Maybe I'm comparing it against a slightly different version. (Sometimes there are more than one installers for the same version of Opus, e.g. if very minor problems are noticed shortly after release or if a problem with the installer itself is noticed.) I should compare like with like to make sure I'm not reading into an installer difference that's because the installers are actually different.
Edit: You can get the MD5 checksum in Opus (on another machine obviously) but selecting the installer and running "GetSizes MD5". You can either create a button which runs that command or type ">" and then the command to run it without creating a button.
Another question Are you telling the installer to use English or another language? Apparently that could change the way it does things. (It is probably not important but might be. )
The installer filesize is 16,866,032 bytes, and the MD5 is 48d67967b1782cf38e63c8b102cb5784. Also - if it helps - the file version is 14.0.0.162, and the internal build number is 62562.
And I am indeed installing in English.
I believe I turned AVG off on one of my attempts to install, but I'll try again to be certain.
It just dawned on me - my EeePC is set up in a slightly unusual way; it's never caused a problem with any other installer, but....
I don't know if you're familiar with the machine, but instead of a hard drive it has two SSD's - one 4GB boot drive (SLC flash) and one 16gb drive (MLC). When I nLite-ened my copy of XP to slipstream in SP3, I also changed the default location of "Documents & Settings" and "Program Folders" to be on "D:", the 16GB drive.
When you said it failed when the installer was about to write to GPSoftware\Directory Opus - that's when I remembered the difference.
Now, that directory DOES get created, and in the right place - it shows up just fine in the part of the installer where it asks where the program should be installed - and that's why I didn't mention it before. I'm not sure why this would cause a problem later on, but it seemed worth bringing up.
I think all this analysis is a little overkill. Installshield does what Installshield does. It works in all but 0.001% of cases.
I think the analysis is just showing maybe different processes or mechanisms on different OS.
The issue seem to be that the original DOpus library file is somehow locked and not being overwritten by the new install. Normally if a file is locked and can't be directly overwritten (which it normally the case for the DOpus library which is locked by the OS) then the replacement is queued for replacement in the start process after a reboot. If this does not work then there's some issue with this system or the file is somehow with wrong permissions or something similar.
So the solution is to do a full normal uninstall of 906 version. Check that all the files under program files \ gpsoftware \ directory opus \ are gone, then do a normal install of 9115.
Do a backup (Settings menu) of the configuration of your current Op0us install if you have changed things before you uninstall, then import these to the new install of 9115.
I thought I read in the thread that this install came up with a file mis-match?
Opus just uses the industry standard installshield for installs. Actually we have nothing to do with the process until you really start Opus. Up to that point it's a traditional installshield build, as used by millions of installs worldwide.
If this is fresh machine then this machine has some serious system issues or serious administrator issues with file or registry permissions. The kind of thing that those horrible registry 'fixers', antispyware and overzealous anti-virus - sw software can cause.
Maybe the EeePC 901 is running out of memory for the normal installer or somehow the OS is cut down to not work as normal? Any joy looking on Google for InstallShield problems with the EeePC 901 ?
My thanks for all your patience and suggestions... as it turns out, the installer didn't like where I'd redirected the TEMP directory to*; it wasn't so much where it was trying to copy files to, as where they were being cached for installation. When I reset it back to the usual location of %USERPROFILE%\Local Settings\Temp - hallelujah! We have install!
Now I'll have a consistent interface and DOpus goodness on all my computers...!
*a directory on an SD card, as it happens. E:\TEMP\ to be precise. And yes, there was oodles of free space - it's a 512MB card.
