Windows Application Driver is a Microsoft service that brings Selenium-style UI test automation to desktop software, letting QA teams drive UWP, WPF, WinForms, and classic Win32 interfaces with familiar Appium client libraries.
Windows Application Driver is a Microsoft service that lets QA teams and developers automate desktop software the same way they automate websites: connect a client to a running driver, locate controls, and assert on what the interface does. The service speaks a Selenium-compatible WebDriver protocol, so existing Appium client libraries in C#, Java, Python, or JavaScript work with little adjustment. In a typical session, Windows Application Driver is started on the test machine, then you open a session against an app by its identifier or executable path and query elements by automation ID, name, class, or XPath before clicking, typing, or reading values. That workflow makes it practical to build repeatable regression suites for interfaces that were never designed for testing.
Because it relies on the operating system's accessibility layer rather than hooks inside the binary, the driver can reach controls in packaged and classic desktop software alike, including legacy forms that predate modern frameworks. Teams usually pair it with a test runner such as NUnit, MSTest, or JUnit and with an inspection tool to capture stable automation properties before writing selectors. The same scripts can run locally, on a remote machine, or through a grid for parallel execution in a build pipeline. If your release process also involves hand-launching or packaging a desktop client, the Windows App reference covers that side of the workflow.
Benefits of using Windows Application Driver start with coverage: the same test suite can drive packaged apps, classic Win32 programs, WinForms, and WPF windows, so organizations stop maintaining a different automation stack for every era of their codebase. Because the driver exposes a standard WebDriver surface, testers reuse skills, page-object patterns, and reporting tools they already know from web automation instead of learning a proprietary scripting language. Selectors built on accessibility properties tend to survive cosmetic redesigns better than screen coordinates or image matching, which reduces flaky failures after a UI refresh. Windows Application Driver can also spread sessions across a grid or a remote machine, so long suites finish sooner and integrate cleanly with continuous integration. Finally, the open-source licence and public issue tracker let teams inspect or extend the code themselves when an uncommon control type needs attention.
Key capabilities and highlights.
The Windows Application Driver runs as a local service that accepts standard WebDriver commands, so an Appium client in C#, Java, Python, or JavaScript can connect without a proprietary protocol or custom SDK. Teams keep their existing fixtures, assertions, and reporting, then point them at desktop windows instead of browser pages, which shortens the learning curve considerably for anyone who already tests web interfaces.
Automation reaches Universal Windows Platform apps, Windows Presentation Foundation windows, Windows Forms dialogs, and classic Win32 software. Windows Application Driver decides how to reach each target from the session you request, so a single harness can cover products built across decades of Microsoft UI frameworks rather than forcing separate tools for new and legacy code.
Controls can be found by automation ID, name, class name, tag name, or XPath, so you pick whichever property stays stable as the interface evolves. Because Windows Application Driver reads the accessibility tree rather than pixel positions, a well-chosen locator keeps working after a colour change or a window resize that would break coordinate-based or image-matching scripts.
A desktop session attaches automation to the whole desktop instead of a single packaged app, which gives testers a route into older programs that cannot be launched by an application identifier. This mode is useful when Windows Application Driver has to interact with long-lived Win32 tools, system dialogs, or windows whose ownership changes during a test run.
The bundled UI Recorder watches the interactions you perform, records the events, and generates XPath queries together with C# code as you go. It is the quickest way to bootstrap a suite against an unfamiliar screen, and because Windows Application Driver returns standard element references, the recorded output slots straight into an existing page-object model that you can refine by hand afterwards.
Sessions can send mouse clicks, keyboard strokes, touch gestures, and pen input to the application under test, which matters for ink, drag, and multi-step gesture scenarios that simple click-and-type automation misses. Testers working with Windows Application Driver on pen-enabled or tablet hardware can therefore script input the way a real user would deliver it.
Scripts can target the service running on another machine or route through a Selenium Grid, so a regression suite spreads across several test hosts instead of queueing behind one desktop. Windows Application Driver keeps the same session commands in either arrangement, which means switching from a local run to a distributed one rarely requires script changes.
Published guidance shows how to start the service, launch tests, and collect results on a build agent, so desktop UI checks can gate a release alongside unit tests. Teams that adopt Windows Application Driver in a pipeline catch interface regressions before shipping and keep the manual smoke pass for exploratory work instead of routine confirmation.
Browse historical releases and previous builds.
No old versions have been added yet.
Common questions about Windows Application Driver.
It supports Universal Windows Platform apps, Windows Presentation Foundation, Windows Forms, and classic Win32 programs. Windows Application Driver can launch a packaged app through its application identifier, while other software is usually started by executable path or automated through a desktop session.
No, but most teams do. The service implements a Selenium-compatible WebDriver interface, so any client that can speak that protocol works. Using an official Appium client library is the common path because it handles session setup and element commands for you.
The official setup steps include enabling Developer Mode in Windows settings before running the driver. This applies to the machine where the application under test is installed and where automation will execute.
The protocol is language-neutral, so the practical answer is whatever your chosen Appium client supports, including C#, Java, Python, and JavaScript. The project's samples and tests are written in C#, which makes them a useful reference when starting out.
Inspect the application's accessibility properties first and prefer automation IDs or names over coordinates. The bundled UI Recorder can also watch your interactions and produce XPath queries and C# code, which is helpful when mapping an unfamiliar screen.
Yes. Windows Application Driver can be started on a remote machine and addressed over the network, and it can be registered with a Selenium Grid. Microsoft publishes pipeline guidance for running desktop UI tests on a build agent.
It is an open-source Microsoft project released under the MIT licence, so it is free to download, run, and modify. The public issue tracker is where feature requests and bug reports are collected.
The driver only sees what the accessibility tree exposes. Controls that are custom-drawn, hidden behind a different window, or missing automation properties cannot be located by ID or name, so you may need an XPath based on parent structure or a desktop-level session instead.
Windows Application Driver is a Microsoft service that brings Selenium-style UI test automation to desktop software, letting QA teams drive UWP, WPF, WinForms, and classic Win32 interfaces with familiar Appium client libraries.
Power Automate for desktop is Microsoft's robotic process automation app for Windows. It builds low-code desktop flows that automate repetitive work across applications, websites, files, and email, and Power Automate for desktop can start from a button, a schedule, or an event.
Microsoft .NET Windows Desktop Runtime 8.0 provides the shared components required to run compatible Windows Forms and WPF desktop applications without installing the complete .NET software development kit.
Microsoft .NET Runtime 8.0 provides the execution engine and core libraries needed to run compatible .NET applications, especially framework-dependent console programs, without installing the complete software development kit.
Microsoft .NET SDK 9.0 provides compilers, command-line tools, project templates, build infrastructure, and runtimes for creating, testing, publishing, and running compatible .NET applications.
Comments