# WinDbg process server setup and remote debugging

A WinDbg process server allows developers to remotely debug user-mode applications running on a Windows on Snapdragon (WoS) device from a different machine - even a non-WoS host. This is especially useful for full screen or graphics-intensive scenarios, where running WinDbg directly on the target device is not feasible.

The following setup is required to use this method:

- Target device: A WoS device with WinDbg installed.
- Host PC: Debugging machine with the same version of WinDbg installed.
- Network access: Both devices must be reachable over TCP/IP.
- Executable path: Full path to the app you want to debug on the target device.

## Start remote debugging

Do the following to start the remote debugging:

1. From the target WoS device open **Command Prompt** and **Run as Administrator**.
2. Run the following command to start the process server:

dbgsrv -t tcp:port=65000
        Copy to clipboard

    You can choose any available port. Port 65000 is used here as an example.
3. Note the IP address of the target device using `ipconfig`.
4. Connect from the host PC and launch the target app.
5. On the host PC, run the following command to connect to the process server and launch the target application remotely:

windbg -premote tcp:server=<TargetIP>,port=65000 "<FullPathToTargetApp>"
        Copy to clipboard

    **Example:**

windbg -premote tcp:server=192.168.1.88,port=65000 "C:\\Program Files (x86)\\Steam\\steamapps\\common\\The Witcher 3\\bin\\x64\\witcher3.exe"
        Copy to clipboard

### Example with the Windows Store version of WinDbg

If you are using the Windows Store version of WinDbg, the paths and executables differ slightly:

- On WoS target device:

    `C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2407.24003.0_arm64__8wekyb3d8bbwe\amd64\dbgsrv -t tcp:port=65000`
- On host PC:

    `C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2407.24003.0_x64__8wekyb3d8bbwe\DbgX.Shell.exe -premote tcp:server=10.73.112.66,port=65000 "c:\gfxr\tools\windows\x64\ark survival ascended.exe c:\gfxr\tools\windows\x64\Ark_Survival_Ascended_Crash.gfxr"`

## Common commands

After you are connected, WinDbg allows you to do the following:

> 
> 
> - Set breakpoints (`bp <FunctionName>`)
> - View call stacks (`k`, `~*k`)
> - Inspect threads (`~`, `~<ID>s`)
> - Monitor loaded modules (`lm`)
> - Continue execution (`g`)
> - Break into debugger (**Ctrl + Break**)

See [Commands](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/commands) ![devhw](data:image/png;base64,UklGRt4AAABXRUJQVlA4TNIAAAAvD8ADED/BoG0jSe5SXP5I7gkNRG3byLnX4Tn+2K4I2raNw5/iqPxlEwBAGlwuj8BNBPpnsblrANx3P36s+DHQIcQ0dmEfEGPc8WEcCCcO/M2hXv3rDJTcHCTB1es7l9P2UoywA2a3jSW/pp77EhxGkq1E8zjH3R3e/fxjREOI6P8EcH+lqu/oTK/6kS+YwlHVAMjkP0ErP1UNIZZmnsB32Y2lZjNPO7HUUA1HkVWz73lAIiWM6WaegFcHzNOJ3bv89WhdNu1TDx/txhT2np2bzWU=) for more information on debugger commands that you can use in WinDbg.

### Tips

- Ensure that the firewall rules allow traffic on the chosen port.
- Use the same WinDbg version on host and target.
- Use `!sym noisy` and `.reload` to troubleshoot symbol loading.
- Remote debugging is ideal for apps that crash during full screen or GPU-intensive workflows.

Last Published: Jun 16, 2026

[Previous Topic
Analyze crash dumps](https://docs.qualcomm.com/bundle/publicresource/80-62010-1/topics/debug-analyze-dumps.md) [Next Topic
Set breakbpoints](https://docs.qualcomm.com/bundle/publicresource/80-62010-1/topics/debug-breakpoints.md)