Run in the background indefinitely

To provide the best experience for users, Windows imposes resource limits on Universal Windows Platform (UWP) apps. Foreground apps are given the most memory and execution time; background apps get less. Users are thus protected from poor foreground app performance and heavy battery drain.

However, developers writing UWP apps for personal use (that is, side loaded apps that won’t be published in the Microsoft Store), or developers writing Enterprise UWP apps, may want to use all resources available on the device without any background or extended execution throttling. Line of business and personal UWP applications can use APIs in the Windows Creators Update (version 1703) to turn off throttling. Be aware that you can’t put an app into the Microsoft Store if it uses these APIs.

Run while minimized

UWP apps move to a suspended state when they are not running in the foreground. On desktop, this occurs when a user minimizes the app. Apps use an extended execution session in order to continue running while minimized. The extended execution APIs that are accepted by the Microsoft Store are detailed in Postpone app suspension with extended execution.

If you are developing an app that is not intended to be submitted into the Microsoft Store, then you can use the ExtendedExecutionForegroundSession with the extendedExecutionUnconstrained restricted capability so that your app can continue to run while minimized, regardless of the energy state of the device. В

The extendedExecutionUnconstrained capability is added as a restricted capability in your app’s manifest. See App capability declarations for more information about restricted capabilities.

Add the xmlns:rescap XML namespace declaration, and use the rescap prefix to declare the capability.

For more information, see the Restricted Capabilities section of App capability declarations.

When you use the extendedExecutionUnconstrained capability, ExtendedExecutionForegroundSession and ExtendedExecutionForegroundReason are used rather than ExtendedExecutionSession and ExtendedExecutionReason. The same pattern for creating the session, setting members, and requesting the extension asynchronously still applies: 

You can request this extended execution session as soon as the app comes to the foreground. Unconstrained extended execution sessions are not limited by energy quotas or by the operating system battery saver. As long as a reference to the session object exists, the app will stay in the running state and not enter the suspended state. If the app is closed by the user, the session will be revoked.

Registering for the Revoked event will enable your app to do any cleanup work required. In the suspending state, you can create an extended execution session with ExtendedExecutionReason.SavingData to save user data before the app is terminated and removed from memory.

Run background tasks indefinitely

In the Universal Windows Platform, background tasks are processes that run in the background without any form of user interface. Background tasks may generally run for a maximum of twenty-five seconds before they are cancelled. Some of the longer-running tasks also have a check to ensure that the background task is not sitting idle or using memory. In the Windows Creators Update (version 1703), the extendedBackgroundTaskTime restricted capability was introduced to remove these limits. The extendedBackgroundTaskTime capability is added as a restricted capability in your app’s manifest file:

Add the xmlns:rescap XML namespace declaration, and use the rescap prefix to declare the capability.

For more information, see the Restricted Capabilities section of App capability declarations.

This capability removes execution time limitations and the idle task watchdog. Once a background task has started, whether by a trigger or an app service call, once it takes a deferral on the BackgroundTaskInstance provided by the Run method, it can run indefinitely. If the app is set to Managed By Windows, then it still may have an energy quota applied to it, and its background tasks will not activated when Battery Saver is active. This can be changed with OS settings. More information is available in Optimizing Background Activity.

The Universal Windows Platform monitors background task execution to ensure good battery life and a smooth foreground app experience. However, personal apps and Enterprise line-of-Business apps can use extended execution and the extendedBackgroundTaskTime capability to create apps that will run as long as needed regardless of the device’s resource availability.

Be aware that the extendedExecutionUnconstrained and extendedBackgroundTaskTime capabilities can override default policy for UWP apps and may cause significant battery drain. Before using these capabilities, first confirm that the default extended execution and background task time policies do not meet your needs and perform testing in battery-constrained conditions to understand the impact your app will have on a device.

Start a detached background process in PowerShell

I have a Java program which I would like to launch as a background process from a PowerShell script, similar to the way a daemon runs on Linux. The PowerShell script needs to do a couple of things:

1. Run the program as a separate and detached process in the background, meaning the parent window can be closed and the process keeps running.
2. Redirect the program’s standard output and standard error to files.
3. Save the PID of the background process to a file so it can be terminated later by another script.

I have a shell script on Linux which starts the program like so:

I’m hoping to replicate the same behavior on Windows using a PowerShell script. I have tried using Start-Process with various combinations of options, as well as creating System.Diagnostics.ProcessStartInfo and System.Diagnostics.Process objects, but so far I am not having any luck. PowerShell starts the program as a background process, but the program abruptly terminates when the DOS window which started the PowerShell session is closed. I would like it to start in the background and be independent of the command window which started it.

The output redirection has also been troublesome, as it seems that the output and error streams can only be redirected in the process is being run in the same window (e.g., using -NoNewWindow ).

Is this sort of thing possible in PowerShell?

How to run a command in the background on Windows?

In linux you can use command & to run command on the background, the same will continue after the shell is offline. I was wondering is there something like that for windows…

5 Answers 5

I’m assuming what you want to do is run a command without an interface (possibly automatically?). On windows there are a number of options for what you are looking for:

Best: write your program as a windows service. These will start when no one logs into the server. They let you select the user account (which can be different than your own) and they will restart if they fail. These run all the time so you can automate tasks at specific times or on a regular schedule from within them. For more information on how to write a windows service you can read a tutorial online such as (http://msdn.microsoft.com/en-us/library/zt39148a(v=vs.110).aspx).

Better: Start the command and hide the window. Assuming the command is a DOS command you can use a VB or C# script for this. See here for more information. An example is:

You are still going to have to start the command manually or write a task to start the command. This is one of the biggest down falls of this strategy.

Worst: Start the command using the startup folder. This runs when a user logs into the computer

Can I run a GUI program in the background on the windows command-line?

For example, in Bash, I can do this:

Is there any equivalent in Windows? I can’t seem to figure out a way to do this with the windows version of emacs.

7 Answers 7

The command to launch programs from the command-line in Windows is «start»

You may want to use the MIN option to start a program minimized

I don’t know if it will be sufficient, but try

It will not go into background but it will rather start separate cmd.exe window for the command.

HaHa,I successed ,To use sublime text3 as a server of markdown preview is my propose,after I closed sublime text’s window,i won’t work. I’d try many methods,at last it works. first,you should create a bat to start this program.

sencond,run this bat by schedule task.

This result is that it works to avoid to show sublime text window.and it work conflict with sublime text normally opened.

Maybe you had guessed ,I use OmniMarkupPreviewer plugin to preview markdown.I had fixed this bug(or not perfect feature) that it uses different view id every time.

Depends on which version of Windows you’re using.

In Vista you should be able to type the name of the exe in your path and have it live after the command prompt is closed.

The START command is used at an MS-DOS prompt to start an MS-DOS-based or Windows-based program. The program is started as a separate task that can be run in the foreground or background.

Unfortunately I do not think that this is possible.

You can do this in a Windows Scripting Host script, with something like:

Where the «0» states that the resulting window should be hidden (for other options, see the documentation at http://msdn.microsoft.com/en-us/library/d5fk67ky(VS.85).aspx) and the «true» states that you want to wait for the command to complete before your script carries on.

It would be a simple exercise to wrap this up in a generic «run this command hidden» script that you could use from the command line.

If you have Microsoft’s new new PowerShell installed, then there may be an easier way to do this (I’ve not worked with PowerShell yet).

If you are happy to have the window minimised then you can do that with the «start» command that other mention. Unfortunately the «/B» option (which sounds like it is what you want) is only for commands and it doesn’t stop windowed applications appearing on screen.

Note: which ever of the above you use to you start a program with a hidden/minimised main window, there is nothing to stop it creating new windows that are visible, or bringing the main window up and into focus, once it is running.

How can I execute a Windows command line in background?

How can I execute a windows command line in the background, without it interacting with the active user?

11 Answers 11

Your question is pretty vague, but there is a post on ServerFault which may contain the information you need. The answer there describes how to run a batch file window hidden:

You could run it silently using a Windows Script file instead. The Run Method allows you running a script in invisible mode. Create a .vbs file like this one

and schedule it. The second argument in this example sets the window style. 0 means «hide the window.»

This is a little late but I just ran across this question while searching for the answer myself and I found this:

which, on Windows, is the closest to the Linux command:

From the console HELP system:

One problem I saw with it is that you have more than one program writing to the console window, it gets a little confusing and jumbled.

To make it not interact with the user, you can redirect the output to a file:

I suspect you mean: Run something in the background and get the command line back immediately with the launched program continuing.

Which is the Unix equivalent of

the above one is pretty closer with its Unix counterpart program &

You can use this (commented!) PowerShell script:

Save it as a .ps1 file. After enabling script execution (see Enabling Scripts in the PowerShell tag wiki), you can pass it one or two strings: the name of the executable and optionally the arguments line. For example:

I confirm that this works on Windows 10.

This is how my PHP internal server goes into background. So technically it should work for all.

A related answer, with 2 examples:

1. Sometimes foreground is not desireable, then you run minimized as below:

call START /MIN «my mongod» «%ProgramFiles%\MongoDB\Server\3.4\bin\mongod.exe»

Hope that helps.

If you want the command-line program to run without the user even knowing about it, define it as a Windows Service and it will run on a schedule.

You can see the correct way to do this in this link:

Summarizing, you have to checkbox for ‘Run whether user is logged on or not’. Task user credentials should be enter after pressing ‘Ok’.

I did this in a batch file: by starting the apps and sending them to the background. Not exact to the spec, but it worked and I could see them start.