Shortcut not launching in User account
Hi Friends, I am in the process of creating a package for NumberGo Oil Reader application.It is a Vendor MSI and I am testing it on my Windows XP SP3 Operating system.The problem that I am facing is that the shortcut “numberGo Reader 2.0” fails to launch under user account.
It does not provide any error message but it does not launch.
If the first launch of the shortcut is in administrator account, then the shortcut launches fine on subsequent launches in the user account.
I have already tried the below steps which have been UNSUCCESSFULL:
1.Double-click on the .exe file in the INSTALLDIR location or Installation path.
2.Give permissions to INSTALLDIR location as well as to Registry keys.
3.The Vendor MSI has the shortcut as non-advertised, I created a new advertised shortcut with the .exe as keyfile, still nogo.
4.I also tried using FILEMON to which which file the shortcut is trying to access on launching, but it does not tell me whether the shortcut is accessing anything (gives all success messages).
Any steps/suggestions (other than the 4 steps mentioned above) to try and resolve this issue would be greatly appreciated.
Thanks in advance for your assistance.
Answers (6)
Try to check this folder, C:\WINDOWS\system32\Microsoft\Crypto\RSA\MachineKeys if exist or if you have permissions to write in a user account. I got this sorted a while ago.
Comments:
-
Thanks for answering!! I checked this path that you mentioned, C:\WINNT\system32\Microsoft\Crypto\RSA\MachineKeys path" but it is empty. - satyapai 11 years ago
-
Have you sorted the issue? Try installing just the MSI and see if it's going to work on the users account. I dont see any problem with mine. You could have altered something in your MST. - dj_xest 11 years ago
-
Yes, I have sorted the issue.The issue was with the behaviour of the .exe file itself.The .exe file requires a "first launch administrator" for the application to work correctly under local user account.So, I created a .vbs which will launch the .exe file under system account and then will kill the process.The user can then launch the application under user account without any problems. - satyapai 11 years ago
-
I am not sure if I will agree with what you did. The problem with that is you are not sure if the application itself is creating some user specific files during first launch. And if you have initialized it using the system context, those files might have been created for the system account and not for the logged in user.
if you could only identify the specific files or registries being created during first launch, that would prevent some issues in the future once they are testing the functionalities of it. - dj_xest 11 years ago -
Well, it is a Vendor supplied MSI and the shortcut was non-advertised. I advertised the shortcut so that it will do self-healing, hence user specific entries will get created.However, it was interesting to note that even after the self-healing took place, the application would still not launch.It dosen't provide any error message, but it dosent launch at all.As we install the Vendor MSI using elevated privileges,I only had to launch the shortcut under elevated privileges,provide a delay of 45 seconds for the application to finish launching correctly and then kill the process.I accomplished this by means of a VB script.I tried using the VBS in the custom action but the custom action wasn't recognising the "wscript.sleep 45000" in the custom action (I am not sure why), Hence I accomplished this by using the .vbs file as a separate entity after my MSI installation command using the Deployment tool. - satyapai 11 years ago
I have seen a problem with some teaching software, that it is the programs first run tasks not working. It may need rights to a database file or even create the file and the users do not have permissions to make the needed file changes. I tested and fixed that problem by adjusting file permissions on the \data stucture giving users more rights. You can test this by installing the software and give your test user full rights to the programs folder. One trick to look at, install the software and wait 5 min before starting shortcut as admin. exit the program and search the disk for files modified in the last couple of minutes.
Another one I have encountered was with QWS3270. I have to give domain users full rights to the software's key set and no problem after that
hklm\software\structure.
Comments:
-
Yes, I have sorted the issue.The issue was with the behaviour of the .exe file itself.The .exe file requires a "first launch administrator" for the application to work correctly under local user account.So, I created a .vbs which will launch the .exe file under system account and then will kill the process.The user can then launch the application under user account without any problems. - satyapai 11 years ago
Hi All, Thanks for your responses and suggestions. Well, I am indeed glad to inform you that the issue has been sorted out.
The issue was with the behaviour of the .exe file itself.
The .exe file requires a "first launch administrator" for the application to work correctly under local user account.
So, I created a .vbs which will launch the .exe file under system account and then will kill the process.The user can then launch the application under user account without any problems.
Have you used RegMon? There could be some permission issue with the registry..
Use ProcessMon (RegMon is inbuilt) to identify the permission issue..
Or Else
Use PictureTaker or InControl like this
Install your package
Do Pre-Capture using PictureTaker before launching the shortcut in Administrator account
Launch the shortcut as Administrator
Now, Do Post Capture
You can analyze the .PWC file whether any addtional registries are getting added in HKCR, HKLM when you launched the shortcut as administrator. If so, add them into your package.
One morething, Check is there any SelfReg, IsSelfReg, SelfRegEx table entries are there in vendor msi. If they are there, remove them and extract the com information and add them to the respective component.
Comments:
-
Let me answer one by one: 1.I am in the process of trying out Regmon and ProcessMon..will update you if they manage to "catch" something...
The SelfReg, IsSelfReg, SelfRegEx table entries in the vendor MSI are empty. - satyapai 11 years ago -
Yes, I have sorted the issue.The issue was with the behaviour of the .exe file itself.The .exe file requires a "first launch administrator" for the application to work correctly under local user account.So, I created a .vbs which will launch the .exe file under system account and then will kill the process.The user can then launch the application under user account without any problems. - satyapai 11 years ago
I would suggest you to take a snapshot of the first launch of the shortcut in Admin mode using InstallRite or any other tool and then see what it does. You will get to know where it wants to write, be it file or registry..
Comments:
-
The issue was with the behaviour of the .exe file itself.The .exe file requires a "first launch administrator" for the application to work correctly under local user account.So, I created a .vbs which will launch the .exe file under system account and then will kill the process.The user can then launch the application under user account without any problems. - satyapai 11 years ago
Before running the program, right click on the short cut and look at properties, are there any parameters after the .exe in the target box under the shortcut tab?
Comments:
-
Thanks for answering!! however, There are no additional arguements/parameters passed after the .exe in the target box. - satyapai 11 years ago
-
Yes, I have sorted the issue.The issue was with the behaviour of the .exe file itself.The .exe file requires a "first launch administrator" for the application to work correctly under local user account.So, I created a .vbs which will launch the .exe file under system account and then will kill the process.The user can then launch the application under user account without any problems. - satyapai 11 years ago