I am using a Windows Service to run my batch file on scheduled times. The batch file runs an .exe file that is a Console application that simply shows a message and creates a file on a folder. When I run this program manually, the program works and the file is created. But when I try to run the program via my Windows Service the program crashes (or in some cases it asks for permission which is not good).
If I do not use the Console in my program however (nothing shown to the user and everything done in the background), the file is correctly created. I need to make sure that the service runs my .exe/.bat files but it looks like running executable files are a bit risky with services.
Is there a way to solve this problem or should I change my program so that it only does things in the background and does not display anything?
Is your service being run in the LocalSystem account -- the default for all Windows Services? If so, then your console application is being launched in that same account, where it may not be able to find its settings.
Try providing your Windows account on the service's Log On tab to see if that gets around the problems. Be sure to set an account where the console application runs normally!
Related
I have a Windows Forms app that is deployed through ClickOnce. In the app, I take advantage of the application settings to store basic connection information. In the two years and 200+ updates since I've published the app and it's been in daily use, I've had no problems with individual users modifying their own settings, and having those settings retained when the application is relaunched and updated.
However, I am working on adding a feature into the app that allows for certain tasks to be scheduled in the Task Scheduler. Everything works fine (the task is scheduled, and the application is called with the correct parameters passed) however when the program is launched, the settings are not read.
I can replicate this by manually launching the application directly from the command line. The application opens, but the only settings available are the settings that shipped with the application initially.
My end question is this: How can I call my ClickOnce app from the command line and have it open the same way as if I'd launched it from the start menu?
Thanks!!
Looks like the answer is to point the Task Scheduler to launch the .appref-ms file that is found in the start menu shortcut. You can't just point to the .exe file.
This is most likely caused by the Command line launching the ClickOnce App under a different user.
Try launching the ClickOnce from Command line or Task scheduler, and loading up task manager and seeing which user the app is running. If it is running on a user other than the user you are logged in as, then you can either log in as the user it is running under (if it's not a system user) and setting what settings you want, or you could try impersonating the desired user through task scheduler.
If none of that is applicable, you could add a Command line switch that, if no settings are found, saves a set of default settings that match what you want.
I have a program that needs to run with normal privileges. To prevent piracy, at the launch of our application we launch a License Manager application that needs to run with Elevated Privileges. Upon enquiring with our vendors, the License Manager seems to have this elevated privileges added in its app.manifest file which is necessary to read some kind of Disk ID information, so it is mandatory (we cannot reduce its privilege requirements).
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
The application successfully launches the License Manager if it is placed in a normal folder. However when it is placed in Program Files folder, it seems to close at launch with no intimation.
We also checked running the application with normal credentials without adding the License Manager (it works fine).
Do we need some sort of settings to be changed either in registry or in some other windows settings to enable launching elevated privileged application from normal account. Or perhaps some code snippet needs to be added at the code launch section which can enable this scenario.
We have even tried pasting the folder created in Program Files to the Desktop (it also runs fine).
OS: Windows 7
Please let me know if any additional information is needed form my side. Any help in this direction is appreciated.
My Humble appologies for assuming problem with Program Files Directory.
It turned out that the logs written by the License Manager were being written in the current application execution folder. The problem was caused by trying to write the log to Program Files folder when the appliction did not have the permissions to write a text file to this folder.
The logging logic was shared between the License Manager (from the program we called a function that was defined in the License Manager, which was writing logs) and the application running from the Program Files folder.
We changed the log creation folder to AppData folder. This has caused the applicaiton to launch successfully.
Cause Conclusion:
Writing log file in Program Files folder from an application that did not have admin privilege.
Note: I have added this post and this answer purely to help other like me, in case they dont have a solution in this type of scenario.
I have a SAS code which works flawlessly when I first open the program and run the code interactively. However, if I try to run it as a batch file or execute it from the command prompt using the -sysin option, it doesn't run and I don't know why.
Part of the reason might be that when I run SAS, I receive this dialog box which I need to manually close:
Screencap 1
When I try to choose the option "Do not show this dialog box again" it doesn't work, and it shows the dialog every time I open SAS. This may be because my registry and profile files are corrupted:
Screencap2
Would this be the reason why? If I run the program interactively after closing the dialog box, the program run just fine. I tried to follow some steps to repair the registry and profile files, but it didn't work. Is that what I should focus on, or is there likely another reason it won't run in batch?
Thanks for your input!
edit: I was able to get the program to run from the batch file, but I get the following errors about permissions in the log file:
ERROR: Insufficient authorization to access //destinationonselecteddrive
NOTE: The SAS System stopped processing this step because of errors.
NOTE: PROCEDURE PRINTTO used (Total process time):
real time 0.01 seconds
cpu time 0.00 seconds
I do not have these issues with insufficient authorization when I run the program interactively, only in batch mode. Could it be a metadata issue?
You have to check with which profile your batch is running. When run interactively it may (and it will normally) use a different profile than the one you are using while running interactively. That means different user and password. You can check in the management console (or ask your administrator to check).
It sounds most likely like there is a problem with the user profile. At my old job I ran into problem with the profile when I ran concurrent SAS sessions. I had to set my user profile to read only using the RSASUSER option (SAS instruction here). If that is not the issue try creating a new profile catalog in a new location and then adding the -SASUSER option with the new location (SAS info on how to do that).
I want to run a batch file that will call openssl.exe to verify signature and after successful verification it will unzip the ziped file. The batch file is working fine manually, but when I call it from classic asp page it is not getting executed.
I have tried everything but it's not executing; it not even showing any message. I'm using a 32bit OS.
Add "Read and execute" permission for files CMD.EXE, OpenSSL.EXE for the user that running your Application pool.
A WinForms program I have developed prints fine and as expected when run as an interactive user. Using the same account but as a scheduled task, the process will run correctly however it prints part of the output in the incorrect font.
The program is a label printer that prints updated pricing labels. It has an option (-s) that the Task Scheduler calls which does not present the GUI but does an update and prints. Executing this as an interactive user through run works correctly (i.e. the correct font is used).
Any clues as to what's happening here? The font that isn't printing correctly is a non-standard system font.
This runs on a server and I thought it might be due to printer redirection but I did a console logon and it worked fine as an interactive process on the console just as it does as interactive through remote desktop.
Interesting problem. Presumably, Windows doesn't load fonts into the non-interactive logon sessions in order to conserve resources.
See this answer for one approach, using the ps tool to create an interactive session when running the task.
I had a very similar issue to yours (running an application through a scheduled task would use the default font but when running locally it would find the custom font I installed) and I found a solution; On Server 2008, there is an issue where custom fonts are not registered immediately after installing for non-interactive users, whereas regular users (i.e. when running on a user actually logged in to the machine) do have the font registered immediately.
The solution that worked for me was to simply restart the machine the font was installed on and the font started working under the non-interactive accounts, as when the computer is turned on it registers correctly. It appears the font installation has a bug where it doesn't register the font correctly for non-interactive users until a reboot.