Add parameters to an executable from its .lnk shortcut in Windows

When you work with shortcuts in Windows, it's not all just double-clicking: you often need the .lnk to launch an executable with specific arguments, such as notepad.exe file.txt or switches of the type /EDevThis is key to automating, debugging, or ensuring an app opens with the correct context.

In addition to manual creation via interface, today there are modern methods to generate and manage shortcuts with parameters from PowerShell or with the Windows COM engine Script Host (WSH). And if you come from packaged environments (MSIX/AppX) or you encounter programs that “only start from their shortcut”, there are techniques to Redirect arguments, adjust manifests, and package with PSF without breaking the experience.

What does it mean to add parameters to an executable from a .lnk?

A shortcut (.lnk) is simply a file that points to a destination (TargetPath) and, optionally, attach arguments (Arguments), a working directory (WorkingDirectory), an icon, keyboard shortcuts and other metadata. These arguments are what you see when, for example, you run notepad.exe C:\Notes\task.txt or you apply a modifier like /safe.

In enterprise scenarios, many Start menu apps rely on a launcher that passes a specific parameter to the main executable. If that parameter is missing, the app could crash or start with incorrect behavior. That's why it's important to identify exactly which shortcut is being run and with what arguments.

If you need to clone that shortcut or deploy it at scale, you can do so with a script that builds the .lnk on the fly. This avoids distributing static files like Internet Explorer.lnk and instead gives you flexibility to generate them on the fly in each team.

It's also common to want to convert the experience of a .lnk into something that can be invoked by tools that only accept .exe files. In that case, the key is to reproduce the TargetPath + Arguments + WorkingDirectory from the shortcut, or using a “launcher” that runs the .lnk for you.

Create a shortcut with parameters from PowerShell (modern method)

PowerShell can use the COM object of WScript.Shell to build .lnk files without relying on pre-existing files. It's a modern method, ideal for deployments and automation.

This example creates a shortcut on the public desktop that runs a program with arguments and sets the icon, working directory, and window style. Note how these are assigned. TargetPath y Arguments:

$WshShell = New-Object -ComObject WScript.Shell
$Desktop   = [Environment]::GetFolderPath('CommonDesktopDirectory')
$LnkPath   = Join-Path $Desktop 'MiAplicacion.lnk'
$Shortcut  = $WshShell.CreateShortcut($LnkPath)

$Shortcut.TargetPath       = 'C:\\Rutas\\MiApp\\MiApp.exe'
$Shortcut.Arguments        = '/modo=admin /perfil=Default'
$Shortcut.WorkingDirectory = 'C:\\Rutas\\MiApp'
$Shortcut.IconLocation     = 'C:\\Rutas\\MiApp\\MiApp.exe,0'
$Shortcut.WindowStyle      = 1 # 1=Normal, 3=Maximizada, 7=Minimizada
$Shortcut.Hotkey           = 'CTRL+ALT+M'
$Shortcut.Save()

If you want to replicate the behavior of an existing shortcut (for example, that Internet Explorer.lnk that you copied in your deployments), you can read its properties, and generate another .lnk with the same destiny and argumentsAlthough it's not strictly necessary for most cases, being clear about which values ​​a shortcut copies will avoid surprises.

Create a shortcut with WSH/VBScript (classic model)

Windows Script Host (WSH) allows you to run VBScript and JScript natively and exposes an object model with which you can create shortcuts. Although it is a “classic” way, it still works on modern Windows because WSH is integrated since Windows 98/2000 and available in NT 4.0 through the Options Package.

The logic is simple: you instantiate WScript.Shell, point it to the Desktop folder and use CreateShortcut to build the .lnk. From there, you customize properties like TargetPath, Arguments, IconLocation, WindowStyle, or Hotkey, and save.

Basic example with visual parameters and options Inspired by Microsoft support examples (re-expressed in VBScript/WSH):

Set WshShell = CreateObject("WScript.Shell")
Desktop = WshShell.SpecialFolders("Desktop")
Set Lnk = WshShell.CreateShortcut(Desktop & "\\EjemploWSH.lnk")

Lnk.TargetPath = "%windir%\\notepad.exe"
Lnk.Arguments = "C:\\Temp\\demo.txt"
Lnk.WorkingDirectory = "C:\\Temp"
Lnk.IconLocation = "C:\\miicono.ico"
Lnk.WindowStyle = 3 ' 3=Maximizada, 7=Minimizada, 4=Normal
Lnk.Hotkey = "ALT+CTRL+F"
Lnk.Save

WSH also allows you to create URL shortcuts. In this case, the shortcut has a .URL extension and the TargetPath points to the Web address:

Set WshShell = CreateObject("WScript.Shell")
Desktop = WshShell.SpecialFolders("Desktop")
Set UrlLink = WshShell.CreateShortcut(Desktop & "\\SitioMicrosoft.URL")
UrlLink.TargetPath = "http://www.microsoft.com"
UrlLink.Save

If you're coming from Visual FoxPro, the idea is the same: WSH COM Automation exposes methods like CreateShortcut and equivalent properties, so you can easily translate the pattern into your preferred language.

“My macro only launches .exe, but the app requires opening from its .lnk”

A real case: some games or tools “validate” their Boot from the shortcut itself. If your macro program only runs .exe, no .lnk, you have several practical options.

Option 1: Reproduce the shortcut's startup. Open the .lnk properties and copy it exactly. Target, Arguments y Startup folder. Then, configure your macro to call that exe with those arguments, starting in the corresponding working directory if possible. In most cases, the app's internal verification is satisfied. with the same parameters.

Option 2: Use a minimal launcherYou can create a small executable or script that invokes the shortcut. For example, using PowerShell:

Start-Process -FilePath "C:\\Ruta\\a\\MiAcceso.lnk"

Or with the START order of cmd.exe, which can open shortcuts if you pass it the correct path and a empty title in quotation marks:

cmd.exe /c start "" "C:\\Ruta\\a\\MiAcceso.lnk"

If you absolutely need an .exe, compile a stub (e.g., in C#) that either runs the .lnk or calls the exe with the arguments stored in the shortcut. This tactic “turns” the shortcut into a callable. macro compatible without altering the boot logic.

How to identify if a Start menu launcher requires parameters

Before integrating an app into your deployments, it is a good idea to check if its launchers in the Start menu depend on argumentsA working method to detect it is the following:

1. Install the Windows application on a test computer.
2. Open the Start menu and locate the application launcher.
3. Run each associated launcher. If it starts without problems, it probably doesn't require any specific parameters.
4. Uninstall the application from the test computer.
5. Install it now using its traditional Win32 installer.
6. Come back to Start menu, find the app and right click.
7. Select More > Open file location.
8. For each shortcut found, open Properties.
9. In the countryside Target, examines whether arguments appear after the executable path.
10. Write down these parameters to reuse in your integration or packaging.

With this information, you will be able to exactly replicate the execution pattern (executable + arguments + startup folder) when creating your own Shortcuts or when building startup scripts.

Windows Apps (MSIX/AppX): Redirection, PSF, and Why They Sometimes “Don’t Start Right”

The apps packaged redirect resources to C:\\Program Files\\WindowsAppsIf an application attempts to write inside that isolated container, it runs into permission errors and may fail at tasks such as Save settings or create Temporary files.

To address this, the Package Support Framework (PSF) allows for the introduction of an intermediate launcher and redirection rules that adjust behavior without touching the original binary. At the operational level, the typical workflow goes through four stages:

1. Staging the app in a local directory.
2. Create the config.json from PSF and insert the relevant PSF binaries.
3. Update AppxManifest for the launcher to be PSFLauncher.
4. Repackage and sign the MSIX package.

This approach allows you to reconfigure the launcher, add arguments via PSF, and redirect working paths, all without modifying the original executable of the application.

Tools needed for flow with PSF

To implement PSF and repackage the app you will need:

• Client of NuGet (nuget.exe).
• Package Support Framework (Microsoft.PackageSupportFramework).
• Windows 10 SDK (recent version) with utilities like makeappx y signtool.
• Sysinternals Process Monitor (optional, very useful for diagnosing file access and registration).

Download nuget.exe and place it, for example, in C:\\PSF\\nuget. Then, from PowerShell with elevated privileges, install PSF via NuGet in a working folder:

Set-Location "C:\\PSF"
.\nuget\nuget.exe install Microsoft.PackageSupportFramework

For Windows 10 SDK, during installation check at least: Signing Tools for Desktop Apps, SDK for C++ UWP Apps, and the components of location of the SDK. These pieces provide everything needed for packaging and signing.

App Staging: Unpacking MSIX

First define variables for the package path, staging folder, architecture, and SDK version. An example configuration would be:

$AppPath = "C:\\PSF\\SourceApp\\PSFSampleApp.msix"        # Instalador MSIX
$StagingFolder = "C:\\PSF\\Staging\\PSFSampleApp"         # Carpeta de staging
$OSArchitecture = "x$((gcim Win32_Processor).AddressWidth)"     # x64 o x86
$Win10SDKVersion = "10.0.19041.0"                              # Versión del SDK

With the SDK installed, use makeappx to unpack MSIX in staging:

Set-Location "${env:ProgramFiles(x86)}\\Windows Kits\\10\\Bin\\$Win10SDKVersion\\$OSArchitecture"
.\makeappx.exe unpack /p "$AppPath" /d "$StagingFolder"

After this step, the package contents are stored in an editable folder. This allows you to add PSFLauncher, the runtime and the JSON configuration file with the necessary arguments.

Create PSF config.json and insert binaries

In the staging directory, create a file config.json that describes each application within the package that requires adjustments. The minimum base includes id, executable y case:

{
  "applications": [
    {
      "id": "",
      "executable": "",
      "arguments": ""
    }
  ]
}

Open the AppxManifest.xml of the package and locate the node . Takes the value of its attribute Executable and use it in the executable field of config.json; also align the id with the application identifier in the manifest. If applicable, add workingdirectory pointing to the appropriate relative folder.

A representative example of config.json with specific arguments:

{
  "applications": [
    {
      "id": "PSFSample",
      "executable": "VFS/ProgramFilesX64/PS Sample App/PSFSample.exe",
      "arguments": "/bootfromsettingshortcut"
    }
  ]
}

From the PSF package downloaded from NuGet, copy the binaries for your architecture (x64/x86) to the root of the staging: PSFLauncher32/64.exe, PSFRuntime32/64.dll y PSFRunDll32/64.exe. This equips the package with the launcher and runtime from PSF.

Update AppxManifest to use PSFLauncher

Edit AppxManifest.xml and replace the Executable attribute of the node to point to PSFLauncher32.exe o PSFLauncher64.exe, as appropriate. The EntryPoint is typically kept as Windows.FullTrustApplication:

<Applications>
  <Application Executable="PSFLauncher32.exe" EntryPoint="Windows.FullTrustApplication">
    ...
  </Application>
</Applications>

With this, the actual startup of the app goes through PSFLauncher, which will read your config.json, will inject arguments and apply file/folder redirections when necessary.

Repackage and sign the updated MSIX

Define variables to package and sign the final MSIX: output path, code signing certificate, and password. Make sure you have a valid certificate for signature.

$AppPath = "C:\\PSF\\SourceApp\\PSFSampleApp_Updated.msix"
$CodeSigningCert = "C:\\PSF\\Cert\\CodeSigningCertificate.pfx"
$CodeSigningPass = "<Password>"
$StagingFolder = "C:\\PSF\\Staging\\PSFSampleApp"
$OSArchitecture = "x$((gcim Win32_Processor).AddressWidth)"
$Win10SDKVersion = "10.0.19041.0"

Package from staging to a new MSIX:

Set-Location "${env:ProgramFiles(x86)}\\Windows Kits\\10\\Bin\\$Win10SDKVersion\\$OSArchitecture"
.\makeappx.exe pack /p "$AppPath" /d "$StagingFolder"

And sign the package using signtool.exe from the SDK:

Set-Location "${env:ProgramFiles(x86)}\\Windows Kits\\10\\Bin\\$Win10SDKVersion\\$OSArchitecture"
.\signtool.exe sign /v /fd sha256 /f $CodeSigningCert /p $CodeSigningPass $AppPath

You now have a PSF-packaged MSIX that runs the correct binary with the required arguments, and with redirects in case the application needs it.

Manual method: create a shortcut with a parameter from the Explorer

If you prefer to do it by hand, the graphical process is simple: right click on the Desktop > New> Shortcut and in the location, enter the executable followed by the parameter, for example:

"C:\\Rutas\\MiApp\\MiApp.exe" /EDev

After naming it, open its Properties and adjust, if you need to, the Startup folder, the icon (Shortcut tab > Change Icon) and the keyboard shortcut. This method is quick for validating arguments like /EDev without writing scripts.

Generating the .lnk “on the fly” in deployments: from copying to creating

If your package previously copied an “Internet Explorer.lnk” and you now want the process to be “contentless” (i.e. the .lnk does not exist in the package and is create dynamically), PowerShell is the preferred route in modern environments.

Un script .ps1 example that you could integrate into your deployment tool:

$Shell = New-Object -ComObject WScript.Shell
$Shortcut = $Shell.CreateShortcut("$env:Public\\Desktop\\IE.lnk")
$Shortcut.TargetPath = "$env:ProgramFiles\\Internet Explorer\\iexplore.exe"
$Shortcut.Arguments = "https://intranet.empresa.local"
$Shortcut.WorkingDirectory = "$env:ProgramFiles\\Internet Explorer"
$Shortcut.IconLocation = "$env:ProgramFiles\\Internet Explorer\\iexplore.exe,0"
$Shortcut.Save()

This approach avoids distributing static files and allows you to adapt arguments, icons and routes depending on the team or the organization's policy, all at runtime.

Good practices and quick tips

• Always check the working directory. Many apps assume relative paths, so if you don't set WorkingDirectory to the executable, you may get errors or abnormal behavior when loading configuration files.
• Escape paths and arguments with spaces using double quotes. In Shortcuts, the TargetPath is usually enclosed in quotes; arguments may also require them if they include spaces or special characters.
• If the shortcut uses environment variables (%windir%, %ProgramFiles%), respect them when creating the .lnk. This way, the shortcut will remain the same. portable between machines with different paths (e.g. x86 vs x64).
• For diagnostics on MSIX, rely on Process Monitor. You'll see what the app tries to open, where it fails due to permissions, and what redirection rules you need in PSF.
• Version your .ps1 scripts and document the arguments. A small README along with the script saves time when changing parameters like /profile, debug switches or special boot modes.

More practical WSH examples (inspired by classic documentation)

Argument-focused variation: open Visual FoxPro/Visual Studio with a configuration file, setting window style, icon and startup folder:

Set WshShell = CreateObject("WScript.Shell")
Desktop = WshShell.SpecialFolders("Desktop")
Set S = WshShell.CreateShortcut(Desktop & "\\DevConfig.lnk")
S.WindowStyle = 7 ' Minimizada (0=Maximizada, 4=Normal)
S.IconLocation = "C:\\ruta\\builder.ico"
S.TargetPath = "C:\\Program Files\\Microsoft Visual Studio\\VFP98\\vfp6.exe"
S.Arguments = "-c \"C:\\Rutas\\config.fpw\""
S.WorkingDirectory = "C:\\"
S.Save

Shortcut to a corporate URL with a .URL extension. Useful for distributing access to internal portals or manuals:

Set WshShell = CreateObject("WScript.Shell")
Desktop = WshShell.SpecialFolders("Desktop")
Set U = WshShell.CreateShortcut(Desktop & "\\PortalEmpresa.URL")
U.TargetPath = "https://intranet.empresa.local"
U.Save

When to choose each method

PowerShell: Ideal for modern deployments, GPOs, Intune, SCCM, and deployment tasks. automation. This is the recommended method if you don't want to distribute pre-made .lnk files.

WSH/VBScript: Perfect when you inherit old scripts or if you need to maintain compatibility with legacy environments. WScript.Shell’s COM API is stable and very straightforward.

PSF with MSIX/AppX: Essential when the Start menu launcher requires parameters or when a packaged app needs redirects to function properly. Allows you to adjust behavior without touching the original binary.

Manual method: useful for quick testing, create an ad-hoc shortcut with a parameter (such as /EDev) or demonstrate feasibility before automating it with scripts.

Whether you're looking to add parameters to an executable from its shortcut, need to generate the .lnk "on the fly" with PowerShell, or even have to deal with MSIX packages that require PSF, here's the complete repertoire: identify arguments in the Start menu, create shortcuts with WSH/PowerShell, work around limitations of tools that only launch .exe files, and repackage apps with PSF so that everything starts as the user expects.