SOLVED Program not loading, but only certain profiles

[torin3]

Background.

Machines are Win7 pro, 64bit. Joined to a domain. Roaming profiles.

Administrator profile installs a program (Vantage 6.1 by Epicor, just in case anybody has heard of it, probably not), with a couple of components, and ODBC settings manually set. Shortcut made to launch program from mapped drive. File association set first time loading program. Works as expected.

Add administrator level user profile to the machine. Log into user profile. Recreate shortcut. File association will not set. You can select the program to launch with, but once you select it, it never shows up in the panel of programs to choose from. Use a program to force file association (Default Programs Editor) Says it did it, but actually doesn't. Went in an manually edited the registry to add the file association. Now it shows up in the panel of programs to select from, but won't actually load the program when the shortcut is double-clicked.

Having task manager up and repeatedly clicking on the launch shortcut shows that the program loads for a millisecond and then goes away.

Through all this, if you log in as the profile that installed the program, it works fine. Log into 3rd profile, won't load. Uninstall and reinstall from 2nd profile and it still won't work.

I've been doing this install the same way for about 2 years now. Probably 50 computers. Win 7 64bit and Vista 64bit. No problems with any profile using it. This just started happening this last week. 2 computers so far. Though I've only done the manual editing of the registry on one computer.

The installing profile is also a domain administrator, but I just tried as the main domain admin account and it won't work there either.

Any suggestions?

 

[Automata]

You mentioned there is a mapped network drive. Is it setup exactly the same way for the other profiles and do they have access to it (read/write if necessary)?

What happens if you don't use a shortcut and just run the file directly?

If the program is launching (as you said), are there any logs for it you can check (program's own logging or Event Viewer) or can you put it in a "debug" mode?

Additionally, if the user profiles are not admins on the local machine, make sure they have access to the install folder.

 

[torin3]

You mentioned there is a mapped network drive. Is it setup exactly the same way for the other profiles and do they have access to it (read/write if necessary)?

Yes, they are mapped by the domain group policies, and while we do have a an occasional problem with the mappings being lost for an occasional computer, we have a .cmd file that restores them if lost. Running that doesn't help in this case.

What happens if you don't use a shortcut and just run the file directly?

No change.

If the program is launching (as you said), are there any logs for it you can check (program's own logging or Event Viewer) or can you put it in a "debug" mode?

It doesn't appear to have a debug mode I can use, and checking the Event Viewer shows no events related to this program (cleared log, tried launching several times, checked log. Nothing related to the software)

Edit: User profiles are local admins, and the install folders are on the mapped drives.

 

[torin3]

Ok, only change is I installed it on a new machine from a non-domain admin, but local admin account. Works fine on 3 different user profiles.

 

[Automata]

The account that you installed it from, is it an explicit local admin (not just domain admin)? If it is, no idea. Sounds like a bug in the program install.

 

[torin3]

Yes, I set up the specific domain admin account as a local admin account when joining the domain before doing anything else. The account that worked this time around was set as an explicit local admin account before attempting the install.

I may have to reformat and start over on the two computers having a problem. Not a big deal, just annoying.

I wonder if there was one windows update that changed something, and a later update that changed it back? At this point I'm clueless.

 

[Automata]

No idea either. That is certainly a strange issue.

 

[medo145]

Check the environmental variables (advanced tab in system properties) compare the paths and temp entries between the working and non working computer. You may just need to add a path.

 

[torin3]

Check the environmental variables (advanced tab in system properties) compare the paths and temp entries between the working and non working computer. You may just need to add a path.

The paths are identical. The only differences in the environmental variables are the processors stats and the fact that one of them has a extra line for the Oracle VirtualBox install. I don't think that is the problem. The other computer was having this same problem before VBox was installed.

 

[torin3]

Just as a final follow-up. I've done a couple more installs, including a reformat of one of the machines that had the problem and it hasn't happened again. I'm guessing that there was a windows update that changed something that caused it, and then another one a couple of weeks later that fixed it. I can't think of anything else that might fit.