# Windows debugging on WoS devices

This section provides developers with steps to debug Windows applications on Windows on Snapdragon (WoS) devices. It covers:

- User-mode crash dump collection.
- Using WinDbg for remote and local debugging.
- Setting breakpoints in delay-loaded modules.
- Symbol loading and troubleshooting.
- Debugging common issues related to apps not launching, slow video rendering, and video playback performance issues.

## Debugging scenarios and tools

The following table lists common debugging scenarios on WoS devices and the recommended methods and tools for resolving the issue. Use it to select the most effective approach for your specific debugging needs.

| **Scenario** | **Recommended Method** | **Tool** |
| --- | --- | --- |
| [App crashes during launch](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-crash-dumps.html#startup-crash) | Registry-based local dumps, ProcDump using IFEO | WinDbg, ProcDump |
| [App crashes during runtime](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-crash-dumps.html#after-launch) | ProcDump (manual), Task Manager dump | WinDbg, Task Manager |
| [Live debugging](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-crash-dumps.html#live-debug) | Visual Studio (F5), WinDbg attach | Visual Studio, WinDbg |
| [Remote debugging](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-windbg-process-server.html#remote-debug) | WinDbg process server | WinDbg |
| [Delay-loaded DLL crash](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-breakpoints.html#delay-load) | `sxe ld`, `bu` breakpoints | WinDbg |
| [Dump analysis](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-analyze-dumps.html#dump-analysis) | `!analyze -v`, `lmDvm`, `k`, `~*k` | WinDbg |
| [Symbol issues](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-symbol-loading.html#symbols) | `.sympath`, `.reload`, `!sym noisy` | WinDbg |
| [Multiple apps crash after installing or updating another app](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-app-conflicts.html#app-conflicts) | Event Viewer, DLL architecture check, dependency analysis, restore correct DLLs, reinstall redistributables | Event Viewer, dumpbin, Dependency Walker, ProcMon, Resource Monitor |

## Best practices

Use the following best practices for Windows debugging on WoS devices:

- Use `!analyze -v` as your first step in dump analysis - it often points directly to the faulting module. See [Set symbol path and run crash analysis](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-analyze-dumps.html#run-analyze-v) for more information.
- Validate symbol paths early to avoid misleading analysis. See [Symbol loading and troubleshooting techniques](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-symbol-loading.html#symbols) for more information.
- Use WinDbg process server for full screen or GPU-heavy apps where local debugging is impractical. See [WinDbg process server setup and remote debugging](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-windbg-process-server.html#remote-debug) for more information.
- Use `sxe ld` and `bu` for delay-loaded modules - don’t rely on bp until the module is mapped. See [Setting breakpoints in user mode (including delay-loaded modules)](https://docs.qualcomm.com/doc/80-62010-1/topic/debug-breakpoints.html#delay-load) for more information.
- Document your findings clearly when sharing with other teams. Be sure to include dump paths, symbol status, and the key commands used.

Last Published: Jun 16, 2026

[Previous Topic
Tuning](https://docs.qualcomm.com/bundle/publicresource/80-62010-1/topics/tuning.md) [Next Topic
Collect crash dumps](https://docs.qualcomm.com/bundle/publicresource/80-62010-1/topics/debug-crash-dumps.md)