Do you have anti-virus software that might be killing it?
Just tested the latest version (10.5.4.0 (5080) x64 ) on WHS2011 (server 2008 R2). Worked as expected, no problems.
So weird! The only A/V I'm using on that is the Microsoft Essentials or whatever that comes with it. It's not much of an A/V, but better than nothing, plus I rarely install anything on it and use Kaspersky throughout the rest of the PCs. I will try it on a 2008 VM and see what it does and report back. I'll even try disabling the A/V, but I run like 10 VMs on that server at any one time, along with security camera software I wrote myself, voice mail system (old school) and many others. And because Directory Opus (which is awesome) was the only one not working, I assumed it was the culprit. I also haven't installed it on many other systems since the licensing limits me, I didn't care to know if it worked on anything else.
Thanks guys!
I always use the USB-version of DO on my customers' 2008 and 2012 servers, never had any problems.
Thanks Sasa. I don't know what's going on. I installed it on a 2008 VM, which I also run from that physical 2008 server, and it worked fine in it. And it worked fine on other machines I've installed it on.
I tried a number of things, including updating to all the latest Microsoft patches, etc., disabled Windows Defender's realtime file monitoring.
That's great it's working for everyone else in the world but me, but it does keep me from buying it. Usually at this point, I would get with the potential customer and try to help them debug it (I'm a developer too), so if anyone from the DOpus team wants to contact me, please do! I'd love to get this working so I can by the dual Pro version. I have no idea why it's not working. I've never seen anything like this before. All other apps work, including 64-bit native ones.
I believe this is written in C++. Is there maybe a "Redistributable Package" I could try? Is it written in C++ 2010 or 2012?
No redist should be needed.
Just to confirm, the installer itself doesn't launch, correct? Problems Installing Opus has some suggestions which may help, dealing with systems where InstallShield has gone wrong in some way.
Is AppLocker in use on the server?
Have you looked in the system Event Logs to see if there's anything in there indicating why the process couldn't run or is failing?
Failing that, it might be worth using Process Monitor to see what's being accessed before the program stops running. (You can zip a PML log file and send it to us to look at if you want. Be sure to include logging for file and registry events, for all processes (since the installer will spawn additional processes, it doesn't make sense to filter them).
I didn't think a redist was needed since the installer should have that if it was required, but I am willing to try anything at this point.
Nope, not using AppLocker, never have.
I looked at the Event Logs and didn't notice anything.
It installs just fine for the most part. No errors, nothing. The point where things stop working is at the end when it asks if I want to run it. When I say ok, it just never does anything. So I uncheck the Run Now option and then click Finish or whatever the button is to continue. Then whenever after that I try to run the app from the installed icons, or the EXE directly, it doesn't do anything. It must run and quit really quick, because when I made a BAT file, set Task Manager to fastest update, put it in the Opus folder with about 200 lines of just "DOpus.exe" and run that BAT, I see it show up in Task Manager briefly. It only shows one at a time though, and I see the PIDs changing, so the system is actually executing the app. It just seems to quit like really fast and doesn't do anything else.
I don't know why I didn't think of Process Monitor, but I did monitor the starting of DOpus.exe and there's definitely activity. I'm attaching a log of just DOpus.exe, since the actual install seems to go ok except for allowing it to run at the end there. I can make an unfiltered log if you'd like.
Thanks for your help!
DOpusProcessMonitorLogfile.zip (8.8 KB)
Is it a full server version of Windows, or is it a Server Core version? (Opus won't run on Server Core.)
It looks like the EXE is exiting very early, while the OS has finished loading its dependencies etc., and before control is handed to any of our code. That suggests something is missing on the system, although the log doesn't indicate what as far as I can tell.
Is the OS fully up to date in terms of service packs & Windows Updates?
Oh no, it's full server (Windows Server 2008 R2 Enterprise 7601 Service Pack 1). After all, I wouldn't think one could run Process Explorer on Core Server. It runs everything for me.. file serving, voice mail, security camera software, VMWare & VirtualBox VMs, FTP server (Filezilla), RAID, etc. I even enabled Aero on it. So it's definitely a fully windowed server install. And before anyone asks, yes, it's fully legal, from Microsoft TechNet. 
Fully updated with all the latest updates.
Interesting it's not even executing actual code. Maybe I should try the beta and see if that does anything different?
Cool, just wanted to rule that out as it's been an issue in the past. A few UI apps run on Server Core but not all of them, and not Opus (at least last time we looked) since Core is missing some key components.
Sure, it could be worth trying the beta.
It's strange when it's only this one server it won't run on, though.
If you're familiar with Dependency Walker, running the 64-bit version of that on dopus.exe and dopuslib.dll might flag up some missing DLLs or something.
Thanks, I will try Dependency Walker (have needed it a few times), but I assumed it only worked for 32-bit. I see now that it works with 64 too. So I'll try that and the beta and let you guys know. It might be a bit before I can spend more time on it. It has to be a strange "DLL Hell" issue. I've actually installed the beta v11 over top of v10 and it wanted me to reboot, but I run so many VMs on it (like 10 of them) that it's not fun to do so. Before I rebooted the other day due to this issue, it had been up for 130 days straight. It's then performed all the latest MS updates I was missing out on.
If I try running the beta (before a restart), I get the following:
dopus.exe - Entry Point Not Found
The procedure entry point ConvertLocalSystemTimeToUTCFileTime could not be located in the dynamic link library dopuslib.dll.
It doesn't really mean a lot since I have yet to reboot, but at least I'm getting some kind of error. I'll report back once I've reported and tried DW, etc. It's just so much work to just get it working. 
I was sufficiently impressed with this para that I excerpted it and sent it to my kids, both of whom follow in their father's footsteps and work in tech support. Glad I didn't have to work on your PC. 
I expect you look after that yourself tho'.
Yeah, I do and trust me, I wish I didn't have to. I'd rather be on my spacious 40 acre property in the country living it up in a nice big house and USD$30 million in my accounts.
Ok, so I just rebooted my server the other day after installing the beta of v11, no go. Does the same thing as v10. I run it and nothing, except I'm sure the Dependency Walker log looks similar.
So I don't know what to do here. No one else seems to have ever had this problem in DOpus's Windows history, and all other software I run on it, both 64 & 32-bit software, work just fine, except Directory Opus. It works on all my other machines I've tried it on, including a 2008 VM, and it works for everyone visiting these forums.
Is this just a problem that can't be solved or is there something else I could try? I'd be willing to work directly with anyone there on it.
If you create a DWORD value called StartupProgress in the registry under the key HKEY_LOCAL_MACHINE \ Software \ GPSoftware \ Directory Opus and set the value to 1 then Opus will print some startup messages that might help, which you should be able to see using DbgView.
Thanks Jon! I'm surprised at this, because I code too, but I've never used DgbView or OutputDebugString(). I should probably start!
Anyway, I tried it a number of times, scrolling back through, starting fresh, double-clicking the icon a bunch, only once, slowly, etc. This is the beta by the way, since that's what I've installed last. It may be a couple builds older than the current one.
All I get back are lines like this:
[69932] [ 3334] type=P Q: 1 length: 77075
[69932] [ 3335] type=B Q: 2 length: 7845
[69932] [ 3336] type=P Q: 1 length: 77390
[69932] [ 3337] type=B Q: 2 length: 7709
[69932] [ 3338] type=P Q: 1 length: 77310
[69932] [ 3339] type=B Q: 2 length: 7703
Once or twice, I've caught something like these:
[5692] 5692: 2014-01-29 15:02:25.535 [CBS] IsCacheStillGood: True.
[5692] 5692: 2014-01-29 15:02:25.785 [Provider] [STAT] DISCOVERY: ComponentInstaller.Initialize() took '241.3055' msec(s) total.
But that's it. I really like Directory Opus, but this is the main machine I'd want to run it on. If it wasn't working on some unimportant machine/VM, I wouldn't care. But I don't know how to move forward on a purchase without being able to have it run. It runs on everything else but this server. Frustrating. I don't blame you guys though. Weird things like this just pop up sometimes.
All those messages look like they are coming from other processes and not Opus. (The first number is the PID which you can match against processes in Task Manager, as long as they are still running.)
The lack of any output from Opus confirms what I infered from the ProcMon logs, which is that dopus.exe is being killed very early during its startup, before any of our code is being run.
It must be being terminated by the operating system, or a third party DLL which is being loaded and initialised at process startup, or by a security tool, or something along those lines. It's not our code that's ending the process as our code hasn't had a chance to run by the time it happens.
How you track down what's causing this is still a question. I would compare software and configuration differences between the server and your other one which is working. There must be some difference there which is causing this as there's no other explanation.
What about other stuff ~similar to AppLocker. Any legacy SRP or other policy driven whitelisting? Some sort of DEP stuff?
Thanks guys. This server was installed by me about a year ago. It's pretty stock except for setting up a domain. It's not some enterprise environment where I'd have SRP, policies at all set up, etc. It could be a DEP thing, but I would think others would have the same issue, since I haven't changed my DEP settings from default. I will probably try disabling DEP just to check.
BUT, I ran into something very interesting today. I noticed there is an "C:\Program Files\GPSoftware\Directory Opus\x86" folder where apparently a copy of the 32-bit copy was installed, but the beta installer I guess? Well, the 32-bit version of the beta RAN! It's running right now! Funny thing is, any 32-bit installer from GPSoftware doesn't all you to install it. It says I must install the 64-bit version, which doesn't work for me. Now, why would the 32-bit version work, but not the 64-bit? Again, I have 64-bit software that runs fine on this machine. And then, why was there a 32-bit version installed? Surely this is being done for a good reason. I just wish someone had mentioned trying it before.
Any ideas on that one?
The 32-bit copy is put there so you can export a 32-bit (or dual bitness) copy to a USB stick if needed.
Compared to 64-bit processes, 32-bit are subject to different DLLs being injected into them (usually just the same DLLs but their 32-bit counterparts, but also potentially entirely different DLLs as the system may be configured to autoload a DLL into 64-bit processes but not 32-bit ones, and things like shell extensions are also independently registered for 32-bit and 64-bit processes).
A different binary may also be treated differently by all the other things that might kill a process (antivirus, DEP, EMET (if installed), etc.).
So knowing that the 32-bit version works doesn't tell us much, as it's not really different to the fact that one program works but 64-bit dopus.exe doesn't.
What it does do is confirm even more that the issue is not something Opus itself is doing, and that it is something external to Opus on your system. The 32-bit and 64-bit code and DLL dependencies they explicitly request (on all systems, vs things registered on your system which Opus is subject to but did not request itself) are virtually identical, other than how they are compiled.
I know you believe the machine's configuration is "stock" but it simply can't be. You have another machine that works fine as proof, along with confirmations (and no other reports of this problem) from other 2008 R2 users that Opus works on their machines. It has to be something on the machine.