Inspecting a Running WinUI App With the New DevTools Preview

<Button
    Content="Save"
    Style="{StaticResource PrimaryButtonStyle}" />

Run WinUI application
        |
        v
Connect development tools
        |
        v
Inspect live UI
        |
        +-- Visual tree
        +-- Properties
        +-- Layout
        +-- Resources
        +-- Runtime state
        |
        v
Identify unexpected behavior
        |
        v
Fix source code
        |
        v
Run again and verify

Page
└── Grid
    └── StackPanel
        ├── TextBlock
        ├── ContentPresenter
        │   └── Button
        └── Border

1. Build the WinUI application.

2. Start the application.

3. Open the supported WinUI DevTools experience.

4. Select the running application instance.

5. Attach or connect the inspection tools.

6. Select the UI element you want to investigate.

Launch application
        ↓
Open Settings
        ↓
Open Account dialog
        ↓
Observe incorrect spacing
        ↓
Inspect live visual tree

<Grid>
    <StackPanel>
        <TextBlock Text="Customer" />
        <TextBox Text="{Binding CustomerName}" />
        <Button Content="Save" />
    </StackPanel>
</Grid>

Grid
└── StackPanel
    ├── TextBlock
    ├── TextBox
    │   └── Template-generated elements
    └── Button
        └── Template-generated elements

Visual problem
      ↓
Select visible control
      ↓
Inspect properties
      ↓
Inspect parent
      ↓
Inspect generated template elements
      ↓
Find property or layout constraint
      ↓
Return to source code

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto" />
        <RowDefinition Height="*" />
    </Grid.RowDefinitions>

    <TextBlock
        Grid.Row="0"
        Text="Orders" />

    <ListView
        Grid.Row="1" />
</Grid>

<Button
    Margin="20"
    Padding="12"
    Content="Save" />

<Style x:Key="PrimaryButtonStyle" TargetType="Button">
    <Setter Property="Padding" Value="16,8" />
    <Setter Property="MinHeight" Value="40" />
</Style>

<TextBlock
    Text="{Binding CustomerName}" />

The problem may be:

• The DataContext is incorrect.
• The binding path is incorrect.
• The property is null.
• The property is not notifying changes.
• The data has not loaded yet.
• A converter changed the value.
• The control is connected to a different data object than expected.

The runtime UI can help you confirm which element is actually receiving the data and whether the visual hierarchy matches your expectations.

This is especially useful in pages that contain nested controls and DataContexts.

Debugging Generated Controls

Some WinUI controls generate significant internal visual structures.

For example, controls such as ListView, TreeView, ComboBox, TextBox, and other templated controls may create additional visual elements.

You generally should not treat every generated element as application-owned UI.

Instead, use the generated hierarchy to understand behavior.

For example:

ListView
    |
    +-- ScrollViewer
    |
    +-- ItemsPresenter
          |
          +-- Generated item
                |
                +-- ContentPresenter

If scrolling or item layout behaves unexpectedly, inspecting this hierarchy can show whether the problem is related to the item itself, the ItemsPresenter, the ScrollViewer, or another part of the control structure.

The hierarchy is diagnostic evidence.

It is not an invitation to modify internal implementation details directly.

Debugging a Slow Screen

Runtime inspection is not a replacement for ETW profiling.

These tools answer different questions.

Suppose a page takes a long time to become responsive.

DevTools may help you inspect:

• Which elements exist
• How deeply nested the visual tree is
• Which controls are being generated
• Which properties are applied
• Whether unexpected elements are present

ETW can help determine:

• How much CPU the UI thread uses
• How long operations take
• Whether the thread is waiting
• Whether disk or network activity is involved
• Whether frames are taking too long

The two approaches work well together.

WinUI DevTools
      |
      +-- What does the UI look like at runtime?
      +-- Which elements exist?
      +-- Which properties are applied?
      |
      v
ETW / WPA
      |
      +-- How long does the work take?
      +-- Which thread is responsible?
      +-- What is the application waiting for?

This is a much stronger debugging workflow than relying on either tool alone.

Inspecting a Real Layout Problem

Consider a dashboard with three panels:

<Grid ColumnSpacing="12">
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="*" />
        <ColumnDefinition Width="*" />
        <ColumnDefinition Width="*" />
    </Grid.ColumnDefinitions>

    <local:SalesPanel Grid.Column="0" />
    <local:OrdersPanel Grid.Column="1" />
    <local:CustomerPanel Grid.Column="2" />
</Grid>

The developer expects all three panels to have the same width.

However, the third panel appears smaller.

Instead of immediately changing the column definitions, inspect the running visual tree.

You might discover that CustomerPanel contains a child with a large MinWidth.

That child forces the panel to request more space than expected.

The problem is therefore not necessarily the Grid.

The runtime hierarchy gives you the path:

Grid
    ↓
CustomerPanel
    ↓
Child control
    ↓
MinWidth
    ↓
Unexpected layout constraint

Now you can return to the source code and decide whether the MinWidth is intentional.

This is a much safer fix than randomly changing Grid sizing.

Inspecting Visual State Problems

WinUI controls often use visual states for interaction.

For example, a button may have different states for:

• Normal
• PointerOver
• Pressed
• Disabled
• Focused

A control that looks wrong only when hovered or focused may therefore have a state-specific property or style.

If the problem occurs only after an interaction, reproduce that exact interaction before inspecting the element.

For example:

Normal state
      ↓
Pointer over
      ↓
Select element
      ↓
Inspect runtime values

This can help distinguish a permanent style problem from a state-specific problem.

Inspecting a Navigation Scenario

Navigation can expose problems that are not obvious on the initial page.

Suppose the application uses several pages:

HomePage
   ↓
OrdersPage
   ↓
OrderDetailsPage
   ↓
Back to OrdersPage

After navigating back, the OrdersPage may contain duplicated controls, stale data, or unexpected state.

Runtime inspection can help determine whether the page was recreated or retained and whether the visual tree contains the elements you expected.

This is especially useful when a navigation problem appears only after repeated transitions.

Combine this with application lifecycle logging when the problem involves page creation and disposal.

Do Not Modify the Runtime UI as the Final Fix

Runtime inspection is diagnostic.

It should not become a substitute for maintaining the source code.

Suppose you discover that a button has an incorrect Padding value.

The correct workflow is:

Inspect runtime value
        ↓
Identify why value is applied
        ↓
Find source style/template/resource
        ↓
Change source
        ↓
Rebuild
        ↓
Inspect again
        ↓
Verify result

Avoid creating a workaround that only changes a runtime object during debugging unless the application design specifically requires dynamic behavior.

Otherwise, the next application launch will simply reproduce the original problem.

Common Problems When Using DevTools

The application does not appear

Check that:

• The application is running.
• The build is compatible with the preview tooling.
• The required Windows App SDK components are installed.
• The development tooling is using the expected version.
• The application is not running under an unsupported configuration.

Because this is a preview feature, compatibility can change between releases.

The inspected value is not what the XAML says

Look for:

• Styles
• Resource dictionaries
• Templates
• Data binding
• Visual states
• Parent layout constraints
• Runtime code that changes the property

The local XAML value is not necessarily the final runtime value.

The visual tree is larger than expected

This is normal for templated controls.

Do not assume every generated element represents unnecessary application code.

First determine whether the additional elements are part of the control template.

The layout changes when resizing

This can be expected.

Resize the window while observing the affected element and compare:

• Available size
• Alignment
• Grid definitions
• Min and Max constraints
• Responsive state changes

A layout that works at one window size may expose a constraint problem at another.

Common Mistakes

Looking only at source XAML

Source code shows what you requested.

Runtime inspection shows what the application actually created.

Both are necessary.

Treating every generated element as a bug

Templated controls naturally generate internal elements.

First understand the control template before removing or replacing anything.

Changing several properties at once

If you change Width, Margin, Padding, Alignment, and Grid definitions simultaneously, you will not know which change solved the problem.

Change one logical cause at a time.

Ignoring parent controls

A child often appears incorrect because its parent imposes a constraint.

Inspect upward in the visual tree.

Using runtime inspection for performance timing

DevTools can explain structure and runtime state, but it is not a complete performance profiler.

Use ETW, WPA, or .NET diagnostic tools when timing and resource usage are the actual problem.

Depending on preview behavior in production

Preview development tools should remain development tools.

Do not design your production architecture around an experimental debugging interface.

A Practical WinUI Debugging Workflow

A useful workflow for daily development is:

1. Reproduce the UI problem.

2. Identify the visible control that behaves incorrectly.

3. Open the WinUI DevTools preview.

4. Inspect the live visual tree.

5. Select the affected element.

6. Review its runtime properties.

7. Inspect the parent hierarchy.

8. Check styles, templates, resources, and visual states.

9. Determine the source of the unexpected value.

10. Fix the source XAML or C# code.

11. Rebuild the application.

12. Reproduce the same scenario.

13. Verify the runtime tree again.

14. Use ETW profiling if the remaining problem is timing or responsiveness.

This workflow keeps diagnosis separate from correction.

That separation is important because runtime behavior can be complicated, especially in large WinUI applications.

When to Use DevTools, Visual Studio, or ETW

The tools overlap, but they have different strengths.

Problem	Best starting point
Exception or code failure	Visual Studio debugger
Incorrect runtime property	WinUI DevTools
Unexpected visual hierarchy	WinUI DevTools
Binding-related UI issue	WinUI DevTools + debugger
Breakpoint and call-stack investigation	Visual Studio
CPU bottleneck	ETW / WPA or Visual Studio Profiler
UI frame performance	ETW / WPA
Disk or system I/O	ETW / WPA
Memory investigation	Visual Studio / .NET tools / ETW
Application startup timing	ETW / WPA
Thread scheduling	ETW / WPA

The most efficient approach is to choose the tool based on the question you are trying to answer.

Advantages and Disadvantages

Advantages:

• Lets developers inspect the running WinUI interface.
• Helps explain the difference between XAML source and runtime UI.
• Makes visual tree problems easier to investigate.
• Helps identify unexpected runtime properties.
• Useful for styles, templates, layout, and visual-state debugging.
• Complements the Visual Studio debugger.
• Works well alongside ETW performance analysis.

Disadvantages:

• Preview tooling can change between releases.
• Not every runtime behavior is exposed through visual inspection.
• Large visual trees can be difficult to navigate.
• Generated template elements can be confusing at first.
• It does not replace performance tracing.
• Some issues still require source-level debugging.

The biggest benefit comes from using DevTools to answer structural questions and other diagnostic tools to answer timing and resource questions.

Production-Oriented Checklist

Before shipping a WinUI application, use runtime inspection during development for important screens.

Check:

• Main navigation pages
• Login and authentication screens
• Large data lists
• Forms
• Dialogs
• Responsive layouts
• Custom controls
• Shared styles
• Theme resources
• Visual states
• Data-bound controls
• Navigation transitions
• Window resizing
• High-DPI configurations

For each important screen, verify that the runtime hierarchy matches the design you expect.

Also check the application at the window sizes and display scaling levels your users are likely to use.

Summary

The most useful part of WinUI DevTools is the ability to investigate the application as it actually exists while it is running.

XAML tells you what you declared. Runtime inspection helps you understand what WinUI constructed from that declaration.

That difference becomes important when debugging styles, templates, visual states, data binding, layout constraints, generated controls, and navigation behavior.

A practical approach is:

Source XAML
    ↓
Run application
    ↓
Inspect live visual tree
    ↓
Find unexpected runtime behavior
    ↓
Trace it back to source
    ↓
Fix source code
    ↓
Rebuild and verify

Use DevTools when the question is about what the UI looks like internally and why a particular element has its current state.

Use ETW and WPA when the question is about how long the application spends doing work.

Use Visual Studio when the question is about code execution, exceptions, breakpoints, and call stacks.

Combining these tools gives WinUI developers a practical way to debug both the structure and behavior of a running application before those problems reach users.