Skip to content

[Windows][Impeller] Snapshotting a GPU-surface external texture calls ResolveTextureSkia and crashes in GrDirectContext::flush #190774

Closed

Description

@NH-Mason

Steps to reproduce

I do not yet have a standalone minimal reproduction. The following steps
reproduce the failure in a larger Windows desktop application that embeds a
native Filament renderer. I am continuing to reduce this to a small plugin/app
sample.

  1. Build and run the Windows application in debug mode with Impeller active.
    Startup confirms:

    Using the Impeller rendering backend (OpenGLESSDF).
    
  2. Through the C++ TextureRegistrar, register a
    kFlutterDesktopGpuSurfaceTexture. Its callback returns a
    FlutterDesktopGpuSurfaceDescriptor backed by a DXGI shared handle for a
    D3D11 texture.

  3. Display the registered texture with a Dart Texture widget. A producer
    thread continuously calls MarkTextureFrameAvailable; the public Windows
    texture-registration API documents this call as valid from any thread.

  4. Push or pop the route containing the texture. The observed stack reaches
    LayerTree::Flatten, consistent with the route/scene snapshot path.

The failure has occurred both several seconds after a route push, while the
texture was animating and without further interaction, and during route pop.

Expected results

Snapshotting or painting the GPU-surface texture should either use the
Impeller external-texture path or reject/skip an unsupported snapshot safely.
The application should not terminate with a native access violation.

Actual results

The raster thread terminates with:

Exception: 0xc0000005
Operation: READ
Address:   0x0
Module:    flutter_windows.dll
RVA:       +0x2c51f7

Two separate crashes were captured and symbolized against the SDK-cache PDB at
bin/cache/artifacts/engine/windows-x64/flutter_windows.dll.pdb. The PDB
CodeView identity matches the shipped DLL.

flutter_windows.dll+0x2c51f7  GrDirectContext::flush
flutter_windows.dll+0xeb4d1   EmbedderExternalTextureGL::ResolveTextureSkia
flutter_windows.dll+0xeaf0c   EmbedderExternalTextureGL::ResolveTexture
flutter_windows.dll+0xeadbb   EmbedderExternalTextureGL::Paint
flutter_windows.dll+0x5477a4  TextureLayer::Paint
                              ContainerLayer::PaintChildren /
                              TransformLayer::Paint /
                              ClipShapeLayer::Paint
flutter_windows.dll+0x5450fd  LayerTree::Flatten

The faulting thread is Flutter's raster thread, not the platform thread or the
producer thread.

Source correlation

At engine revision
bbd15867c003dc66e678cb3c218649fa8bf914f2:

  • Normal LayerTree::Paint supplies the frame's Aiks context:
    PaintContext context = {
    // clang-format off
    .state_stack = state_stack,
    .canvas = canvas,
    .gr_context = frame.gr_context(),
    .dst_color_space = sk_ref_sp(color_space),
    .view_embedder = frame.view_embedder(),
    .raster_time = frame.context().raster_time(),
    .ui_time = frame.context().ui_time(),
    .texture_registry = frame.context().texture_registry(),
    #if !SLIMPELLER
    .raster_cache = cache,
    #endif // !SLIMPELLER
    .impeller_enabled = !!frame.aiks_context(),
    .aiks_context = frame.aiks_context(),
    // clang-format on
    };
  • The Impeller deferred-image snapshot path calls LayerTree::Flatten with
    only the bounds and texture registry:
    sk_sp<DisplayList> display_list;
    if (std::holds_alternative<sk_sp<DisplayList>>(content)) {
    display_list = std::get<sk_sp<DisplayList>>(std::move(content));
    } else if (std::holds_alternative<std::unique_ptr<LayerTree>>(
    content)) {
    std::unique_ptr<LayerTree> layer_tree =
    std::get<std::unique_ptr<LayerTree>>(std::move(content));
    display_list = layer_tree->Flatten(
    DlRect::MakeWH(wrapper->size_.width, wrapper->size_.height),
    snapshot_delegate->GetTextureRegistry());
    }
    auto texture = snapshot_delegate->MakeImpellerSnapshotSync(
    display_list, wrapper->size_, wrapper->pixel_format_);
  • LayerTree::Flatten creates a paint context with no Aiks context, and its
    GrDirectContext argument defaults to null:
    void Paint(CompositorContext::ScopedFrame& frame,
    bool ignore_raster_cache = false) const;
    sk_sp<DisplayList> Flatten(
    const DlRect& bounds,
    const std::shared_ptr<TextureRegistry>& texture_registry = nullptr,
    GrDirectContext* gr_context = nullptr);

    sk_sp<DisplayList> LayerTree::Flatten(
    const DlRect& bounds,
    const std::shared_ptr<TextureRegistry>& texture_registry,
    GrDirectContext* gr_context) {
    TRACE_EVENT0("flutter", "LayerTree::Flatten");
    DisplayListBuilder builder(bounds);
    const FixedRefreshRateStopwatch unused_stopwatch;
    LayerStateStack preroll_state_stack;
    // No root surface transformation. So assume identity.
    preroll_state_stack.set_preroll_delegate(bounds);
    PrerollContext preroll_context{
    // clang-format off
    #if !SLIMPELLER
    .raster_cache = nullptr,
    #endif // !SLIMPELLER
    .gr_context = gr_context,
    .view_embedder = nullptr,
    .state_stack = preroll_state_stack,
    .dst_color_space = nullptr,
    .surface_needs_readback = false,
    .raster_time = unused_stopwatch,
    .ui_time = unused_stopwatch,
    .texture_registry = texture_registry,
    // clang-format on
    };
    LayerStateStack paint_state_stack;
    paint_state_stack.set_delegate(&builder);
    PaintContext paint_context = {
    // clang-format off
    .state_stack = paint_state_stack,
    .canvas = &builder,
    .gr_context = gr_context,
    .dst_color_space = nullptr,
    .view_embedder = nullptr,
    .raster_time = unused_stopwatch,
    .ui_time = unused_stopwatch,
    .texture_registry = texture_registry,
    #if !SLIMPELLER
    .raster_cache = nullptr,
    #endif // !SLIMPELLER
    // clang-format on
    };
  • EmbedderExternalTextureGL::ResolveTexture selects the Impeller resolver
    only when aiks_context is non-null. Otherwise it selects
    ResolveTextureSkia, which dereferences context without a null check:
    sk_sp<DlImage> EmbedderExternalTextureGL::ResolveTexture(
    int64_t texture_id,
    GrDirectContext* context,
    impeller::AiksContext* aiks_context,
    const SkISize& size) {
    if (!!aiks_context) {
    return ResolveTextureImpeller(texture_id, aiks_context, size);
    } else {
    return ResolveTextureSkia(texture_id, context, size);
    }
    }
    sk_sp<DlImage> EmbedderExternalTextureGL::ResolveTextureSkia(
    int64_t texture_id,
    GrDirectContext* context,
    const SkISize& size) {
    context->flushAndSubmit();
    context->resetContext(kAll_GrBackendState);

This is not an observed “Impeller resolution failed and then fell back to
Skia” sequence; the resolver selection is based directly on whether
aiks_context is present.

The failure is not deterministic on every texture paint. The GL wrapper caches
last_image_, and MarkNewFrameAvailable clears that cache. A flatten pass
can therefore reuse a previously resolved Impeller image, or attempt a new
resolution with the flatten paint context:

void EmbedderExternalTextureGL::Paint(PaintContext& context,
const DlRect& bounds,
bool freeze,
const DlImageSampling sampling) {
if (last_image_ == nullptr) {
last_image_ =
ResolveTexture(Id(), //
context.gr_context, //
context.aiks_context, //
SkISize::Make(bounds.GetWidth(), bounds.GetHeight()) //
);
}
DlCanvas* canvas = context.canvas;
const DlPaint* paint = context.paint;
if (last_image_) {
DlRect image_bounds = DlRect::Make(last_image_->GetBounds());
if (bounds != image_bounds) {
canvas->DrawImageRect(last_image_, image_bounds, bounds, sampling, paint);
} else {
canvas->DrawImage(last_image_, bounds.GetOrigin(), sampling, paint);
}
}
}
sk_sp<DlImage> EmbedderExternalTextureGL::ResolveTexture(
int64_t texture_id,
GrDirectContext* context,
impeller::AiksContext* aiks_context,
const SkISize& size) {
if (!!aiks_context) {
return ResolveTextureImpeller(texture_id, aiks_context, size);
} else {
return ResolveTextureSkia(texture_id, context, size);
}

// |flutter::Texture|
void EmbedderExternalTextureGL::OnGrContextCreated() {}
// |flutter::Texture|
void EmbedderExternalTextureGL::OnGrContextDestroyed() {}
// |flutter::Texture|
void EmbedderExternalTextureGL::MarkNewFrameAvailable() {
last_image_ = nullptr;
}
// |flutter::Texture|
void EmbedderExternalTextureGL::OnTextureUnregistered() {}

The same relevant routing and null-dereference structure is still present on
Flutter master as of commit
a6266833e3b7e23a6a36ec7df8982c217a881677, although I have not runtime-tested
that revision.

Backend A/B

The same application binary and navigation path were run with only the
renderer selection changed.

To disable Impeller for the control run:

$env:FLUTTER_ENGINE_SWITCHES = '1'
$env:FLUTTER_ENGINE_SWITCH_1 = 'enable-impeller=false'

Results:

  • Impeller: reproduced after route push and during route pop across
    multiple launches/rebuilds. Two failures have matching symbolized stacks.
  • Skia: survived route push, a 45-second dwell with the texture animating,
    route pop, and a second complete enter/exit cycle.
  • Prior Impeller negative run: one earlier run painted the texture
    continuously for more than 10 minutes and then failed only on route pop.

I did not record a formal pass/fail denominator, so this A/B is presented as a
backend discriminator rather than proof that every Impeller run fails.

Code sample

A standalone sample is not yet available. The relevant registration shape is
approximately:

// Representative excerpt only; the texture variant is retained for the
// complete registered lifetime.
flutter::TextureVariant texture = flutter::GpuSurfaceTexture(
    kFlutterDesktopGpuSurfaceTypeDxgiSharedHandle,
    [](size_t width, size_t height)
        -> const FlutterDesktopGpuSurfaceDescriptor* {
      return CurrentGpuSurfaceDescriptor();
    });

const int64_t texture_id = registrar->RegisterTexture(&texture);

// Called at the producer's frame cadence from a worker thread.
registrar->MarkTextureFrameAvailable(texture_id);

The returned descriptor's handle is the DXGI shared handle for the D3D11
texture. Dart displays the returned ID using:

Texture(textureId: textureId)

Environment

  • Flutter 3.47.0-0.1.pre, beta channel
  • Framework bd1e75d918605c91b411e8789fb911e6c9a84534
  • Engine bbd15867c003dc66e678cb3c218649fa8bf914f2
  • Windows 11 Pro build 26200, x64
  • NVIDIA GeForce RTX 3080, driver 595.95
  • Debug build: flutter build windows --debug
  • Release/profile behavior has not been tested
  • Runtime reproduction on current master/newest beta has not yet been tested

Logs

[IMPORTANT:flutter/shell/platform/embedder/embedder_surface_gl_impeller.cc(126)]
Using the Impeller rendering backend (OpenGLESSDF).

A redacted run log and the complete raw module+offset stack can be attached.

Flutter Doctor output

Doctor output
[!] Flutter (Channel beta, 3.47.0-0.1.pre, on Microsoft Windows [Version 10.0.26200.8875], locale en-US) [388ms]
    • Flutter version 3.47.0-0.1.pre on channel beta at D:\<project>\.fvm\flutter_sdk
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision bd1e75d918 (4 weeks ago), 2026-07-09 13:32:07 -0700
    • Engine revision bbd15867c0
    • Dart version 3.13.0 (build 3.13.0-282.1.beta)
    • DevTools version 2.59.0
    • Feature flags: enable-web, enable-linux-desktop, enable-macos-desktop, enable-windows-desktop, enable-android, enable-ios, cli-animations, enable-native-assets, enable-record-use, enable-swift-package-manager, omit-legacy-version-file, enable-lldb-debugging, enable-uiscene-migration

[✓] Windows Version (11 Pro 64-bit, 25H2, 2009) [1,801ms]

[✓] Android toolchain - develop for Android devices (Android SDK version 35.0.0) [1,361ms]
    • Android SDK at C:\Users\REDACTED\AppData\Local\Android\Sdk
    • Emulator version 36.2.12.0 (build_id 14214601) (CL:N/A)
    • Platform android-36.1, build-tools 35.0.0
    • ANDROID_HOME = C:\Users\REDACTED\AppData\Local\Android\Sdk
    • ANDROID_SDK_ROOT = C:\Users\REDACTED\AppData\Local\Android\Sdk
    • Java binary at: C:\Program Files\Android\Android Studio\jbr\bin\java
      This is the JDK bundled with the latest Android Studio installation on this machine.
      To manually set the JDK path, use: `flutter config --jdk-dir="path/to/jdk"`.
    • Java version OpenJDK Runtime Environment (build 21.0.8+-14018985-b1038.68)
    • All Android licenses accepted.

[✓] Chrome - develop for the web [82ms]
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[✓] Visual Studio - develop Windows apps (Visual Studio Community 2022 17.14.36) [81ms]
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Community
    • Visual Studio Community 2022 version 17.14.37502.11
    • Windows 10 SDK version 10.0.26100.0

[✓] Connected device (3 available) [417ms]
    • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.26200.8875]
    • Chrome (web)      • chrome  • web-javascript • Google Chrome 151.0.7922.76
    • Edge (web)        • edge    • web-javascript • Microsoft Edge 150.0.4078.105

[✓] Network resources [449ms]
    • All expected network resources are available.

! Doctor found issues in 1 category.

Additional crash artifacts

I can provide the minidump, exact raw module+offset frames, and run
instrumented engine builds. I have not attached the raw minidump publicly
because it can contain application memory and local filesystem paths.

Related issue

#189555 reports a structurally similar LayerTree::Flatten external-texture
null-context crash on iOS Skia. That report was closed because its reproduced
iOS Skia configuration is no longer supported. This report is distinct:
Windows, active Impeller/OpenGLES, a D3D GPU-surface texture, and an
Impeller-versus-Skia same-binary A/B.

Activity

  1. puneetkukreja98 commented on Aug 10, 2026

    @puneetkukreja98
    Contributor

    @NH-Mason Thanks for reporting the issue. Could you please provide a minimal reproducible example (MRE) or a sample GitHub repository so we can reproduce it on our end?

    Without reproducing it or having a minimal reproducible example (MRE) provided, I cannot forward this to the team.

  2. added
    waiting for responseThe Flutter team cannot make further progress on this issue until the original reporter responds
    and removed
    in triagePresently being triaged by the triage team
    on Aug 10, 2026
  3. NH-Mason commented on Aug 11, 2026

    @NH-Mason
    Author

    Following up on my own report with a standalone reproduction that has no
    third-party rendering stack involved, plus controls and newer-engine results.

    Repro: https://github.com/NH-Mason/flutter-190774-repro

    flutter pub get
    flutter run -d windows

    That's the whole thing — no environment variables, no scripts. The app registers
    a texture, pushes a route about half a second later, dies on that first
    transition, and flutter run prints Lost connection to device.

    If you want the faulting stack printed to stderr rather than a silent exit, set
    $env:FLUTTER_REPRO_CRASH_TRACE = '1' first; that enables a small vectored
    exception handler in the runner which is off by default and is not part of the
    bug. The repo also has a run_repro.ps1 that runs the control matrix below and
    retains logs, but the crash needs none of it.

    Environment

    Item Value
    Flutter 3.47.0-0.1.pre (beta)
    Framework bd1e75d918605c91b411e8789fb911e6c9a84534
    Engine bbd15867c003dc66e678cb3c218649fa8bf914f2
    flutter_windows.dll SHA-256 7902667F7BE09E606AEC1A8679AD53EC02B1E25CA580F525C114FEE8AD697635
    OS Windows 11 Pro 26200 x64
    GPU NVIDIA RTX 3080, driver 595.95 (32.0.15.9595)
    Toolchain VS 2022 17.14.36, Windows SDK 10.0.26100.0
    Backend Using the Impeller rendering backend (OpenGLESSDF)

    Module offsets below are only meaningful against this exact engine revision.

    What the repro contains

    My original case went through a third-party Vulkan renderer, so I replaced the
    producer with plain D3D11 in the runner — the smallest thing that still hands
    Flutter a DXGI shared-handle GPU surface. It preserves the contract that
    mattered:

    • allocates on Flutter's own DXGI adapter (GetGraphicsAdapter)
    • DXGI_FORMAT_B8G8R8A8_UNORM
    • D3D11_RESOURCE_MISC_SHARED | D3D11_RESOURCE_MISC_SHARED_NTHANDLE
    • IDXGIResource1::CreateSharedHandle
    • GpuSurfaceTexture(kFlutterDesktopGpuSurfaceTypeDxgiSharedHandle)
    • descriptor, texture variant and shared handle retained for the texture's life
    • MarkTextureFrameAvailable from a worker thread at ~60 Hz

    On the Dart side, a Texture widget sits under a ZoomPageTransitionsBuilder
    with allowSnapshotting: true, and a loop pushes/pops a route every ~1.3s so
    the transition snapshots the subtree containing the texture. Dependencies are
    flutter, flutter_test, flutter_lints only; the texture is a 512×512
    surface cleared to a cycling solid colour, with no scene or asset loading.

    Synchronization, stated explicitly: the producer uses SHARED | SHARED_NTHANDLE without a keyed mutex, calling Flush after each clear. I
    don't believe that's the cause here — the stack matches the null-context path
    already identified on this issue — but I'd rather disclose it than have it
    inferred.

    Expected vs actual

    Expected: routes push and pop for 30 seconds, app prints
    clean timeout reached; exiting normally and exits 0.

    Actual: the process takes an access violation on the first route push and
    exits with 0xC0000005.

    This isn't a teardown artifact, and the source shows why rather than relying on
    log timing: route push/pop performs no texture retirement at all. Unregistration
    exists only in the native plugin's destructor, so the texture and its producer
    are still live and registered throughout the transition that crashes.

    Matrix

    Each run used a 30-second configured timeout; the crashing run ends earlier.

    Snapshotting Continuous updates/marks Impeller Result Exit code
    on on on crash, signature matched 0xC0000005
    off on on no failure, 22–23 route pushes 0
    on off on no failure, 22–23 route pushes 0
    on on off no failure, 22–23 route pushes 0

    Each control ran the full 30 seconds and completed 22 push/pop cycles (22–23
    pushes issued, depending on whether the last transition was still in flight at
    timeout), so they exercised the same path rather than failing to start. The
    Impeller-off log contains zero
    Using the Impeller rendering backend lines, confirming the backend actually
    changed.

    Two honest caveats about the middle control:

    • It is not "no frame marks". The texture is always rendered once and marked
      once at registration; the flag only disables the subsequent ~60 Hz worker loop.
    • It changes two things at once — ongoing texture writes and ongoing frame
      notifications — so it can't distinguish new pixel content from the cache
      invalidation that MarkTextureFrameAvailable triggers.

    So rather than claiming all three triggers are strictly required: in one
    30-second run per configuration, the crash was not observed when
    snapshotting, continuous updates/marks, or Impeller was disabled. Each dimension
    would need independent isolation and repeats before I'd state it more strongly.

    Worth flagging for anyone else trying to reproduce this: flutter run does
    not propagate FLUTTER_ENGINE_SWITCHES to the application process, so an
    "Impeller disabled" run launched through flutter run still starts Impeller —
    and still crashes, which reads as "not Impeller-specific." My first
    Impeller-off control was invalid for exactly this reason. The harness builds
    and launches the .exe directly, and fails if -ImpellerOff is requested but
    Impeller starts anyway. Related: flutter run reported exit code 0 even though
    the app process had died of an access violation.

    Still reproduces on the current beta

    I re-ran the repro unchanged against two newer betas (-AllowAnyEngine skips the
    revision pin). Both crash the same way, always a null read:

    Flutter Engine Result Fault address
    3.47.0-0.1.pre bbd15867c003… crash, READ at 0x0 flutter_windows.dll+0x2c51f7
    3.47.0-0.3.pre effb186f3172… crash, READ at 0x0 flutter_windows.dll+0x2c51f7
    3.47.0-0.4.pre (current beta) f88005a259ba… crash, READ at 0x0 flutter_windows.dll+0x2c55f7

    On 0.4.pre the whole chain shifts by exactly 0x400 (+0xeb8d1, +0xeb30c,
    +0xeb1bb against +0xeb4d1, +0xeaf0c, +0xeadbb), consistent with the same
    code at a different link offset rather than a different bug.

    Retained logs: logs\cross_beta_0.3.log, logs\cross_beta_0.4.log. These
    cross-version runs were classified on module + fault type only, since exact
    offsets are not comparable across engines.

    Stack

    code          : 0xc0000005
    faulting addr : flutter_windows.dll+0x2c51f7
    operation     : READ at 0x0
      ...
      flutter_windows.dll+0x2c51f7
      flutter_windows.dll+0xeb4d1
      flutter_windows.dll+0xeaf0c
      flutter_windows.dll+0xeadbb
      ...
      flutter_windows.dll+0x5450fd
    

    Below those frames the debugger shows a deeply recursive pattern alternating
    between two call sites, consistent with a layer-tree walk. This matches the
    LayerTree::Flatten → ResolveTextureSkia → GrDirectContext::flush null-context
    path already described on this issue.

    Caveats: .ecxr returns
    Unable to get exception context, HRESULT 0x8000FFFF, so the frames come from
    the break-in context at the first-chance AV. There are no public PDBs for
    flutter_windows.dll, so the debugger resolves every frame to the nearest
    exported symbol plus a very large offset — I've quoted module+offset only.

    I have a minidump but haven't attached it, since it captures process environment
    data. Happy to produce a scrubbed one, or run additional configurations on this
    hardware, if that would help.

  4. removed
    waiting for responseThe Flutter team cannot make further progress on this issue until the original reporter responds
    on Aug 11, 2026
  5. puneetkukreja98 commented on Aug 12, 2026

    @puneetkukreja98
    Contributor

    @NH-Mason Thanks for the response, I was able to reproduce it using the repo link provided above on latest master.

    Findings:

    Console logs impeller enabled:

    PS C:\Google\flutter-190774-repro> flutter run -d windows
    Resolving dependencies... 
    Downloading packages... 
      material_color_utilities 0.13.0 (0.13.1 available)
      test_api 0.7.12 (0.7.13 available)
    Got dependencies!
    2 packages have newer versions incompatible with dependency constraints.
    Try `flutter pub outdated` for more information.
    Launching lib\main.dart on Windows in debug mode...
    Building Windows application...                                    47.9s
    √ Built build\windows\x64\runner\Debug\external_texture_snapshot_crash.exe
    [IMPORTANT:flutter/shell/platform/embedder/embedder_surface_gl_impeller.cc(127)] Using the Impeller rendering backend (OpenGLESSDF).
    [repro] ALLOW_SNAPSHOTTING=true
    [repro] MARK_FRAMES=true
    [repro] AUTO_EXIT_SECONDS=30
    [repro] ROUTE_DWELL_MS=800
    [repro] requesting native GPU-surface texture
    [repro] registered DXGI shared-handle GPU texture id=2087311068384 size=512x512 format=BGRA8888 mark_frames=true
    [repro] worker produced and marked frame 1
    [repro] texture registered: id=2087311068384
    [repro] texture route presented; starting route loop
    Syncing files to device Windows...                                 208ms
    
    Flutter run key commands.
    r Hot reload. 
    R Hot restart.
    h List all available interactive commands.
    d Detach (terminate "flutter run" but leave application running).
    c Clear the screen
    q Quit (terminate the application on the device).
    
    A Dart VM Service on Windows is available at: http://127.0.0.1:51049/uMz-6Hdpij4=/
    The Flutter DevTools debugger and profiler on Windows is available at:
    http://127.0.0.1:51049/uMz-6Hdpij4=/devtools/?uri=ws://127.0.0.1:51049/uMz-6Hdpij4=/ws
    [repro] cycle 1: immediately before route push
    [repro] cycle 1: immediately before route pop
    [repro] cycle 1: route pop completed
    [repro] cycle 2: immediately before route push
    Lost connection to device.

    Console logs impeller disabled:

    PS C:\Google\flutter-190774-repro> flutter run -d windows --no-enable-impeller
    Launching lib\main.dart on Windows in debug mode...
    Building Windows application...                                    11.0s
    √ Built build\windows\x64\runner\Debug\external_texture_snapshot_crash.exe
    [repro] ALLOW_SNAPSHOTTING=true
    [repro] MARK_FRAMES=true
    [repro] AUTO_EXIT_SECONDS=30
    [repro] ROUTE_DWELL_MS=800
    [repro] requesting native GPU-surface texture
    [repro] registered DXGI shared-handle GPU texture id=2333530843040 size=512x512 format=BGRA8888 mark_frames=true
    [repro] worker produced and marked frame 1
    [repro] texture registered: id=2333530843040
    [repro] texture route presented; starting route loop
    Syncing files to device Windows...                                 152ms
    
    Flutter run key commands.
    r Hot reload. 
    R Hot restart.
    h List all available interactive commands.
    d Detach (terminate "flutter run" but leave application running).
    c Clear the screen
    q Quit (terminate the application on the device).
    
    A Dart VM Service on Windows is available at: http://127.0.0.1:52898/ygEVQPr2W6Y=/
    The Flutter DevTools debugger and profiler on Windows is available at:
    http://127.0.0.1:52898/ygEVQPr2W6Y=/devtools/?uri=ws://127.0.0.1:52898/ygEVQPr2W6Y=/ws
    [repro] cycle 1: immediately before route push
    [repro] cycle 1: immediately before route pop
    [repro] cycle 1: route pop completed
    [repro] cycle 2: immediately before route push
    [repro] cycle 2: immediately before route pop
    [repro] cycle 2: route pop completed
    [repro] cycle 3: immediately before route push
    [repro] cycle 3: immediately before route pop
    [repro] cycle 3: route pop completed
    [repro] cycle 4: immediately before route push
    [repro] worker produced and marked frame 300
    [repro] cycle 4: immediately before route pop
    [repro] cycle 4: route pop completed
    [repro] cycle 5: immediately before route push
    [repro] cycle 5: immediately before route pop
    [repro] cycle 5: route pop completed
    [repro] cycle 6: immediately before route push
    [repro] cycle 6: immediately before route pop
    [repro] cycle 6: route pop completed
    [repro] cycle 7: immediately before route push
    [repro] cycle 7: immediately before route pop
    [repro] cycle 7: route pop completed
    [repro] worker produced and marked frame 600
    [repro] cycle 8: immediately before route push
    [repro] cycle 8: immediately before route pop
    [repro] cycle 8: route pop completed
    [repro] cycle 9: immediately before route push
    [repro] cycle 9: immediately before route pop
    [repro] cycle 9: route pop completed
    [repro] cycle 10: immediately before route push
    [repro] cycle 10: immediately before route pop
    [repro] cycle 10: route pop completed
    [repro] cycle 11: immediately before route push
    [repro] worker produced and marked frame 900
    [repro] cycle 11: immediately before route pop
    [repro] cycle 11: route pop completed
    [repro] cycle 12: immediately before route push
    [repro] cycle 12: immediately before route pop
    [repro] cycle 12: route pop completed
    [repro] cycle 13: immediately before route push
    [repro] cycle 13: immediately before route pop
    [repro] cycle 13: route pop completed
    [repro] cycle 14: immediately before route push
    [repro] cycle 14: immediately before route pop
    [repro] cycle 14: route pop completed
    [repro] cycle 15: immediately before route push
    [repro] worker produced and marked frame 1200
    [repro] cycle 15: immediately before route pop
    [repro] cycle 15: route pop completed
    [repro] cycle 16: immediately before route push
    [repro] cycle 16: immediately before route pop
    [repro] cycle 16: route pop completed
    [repro] cycle 17: immediately before route push
    [repro] cycle 17: immediately before route pop
    [repro] cycle 17: route pop completed
    [repro] cycle 18: immediately before route push
    [repro] cycle 18: immediately before route pop
    [repro] cycle 18: route pop completed
    [repro] worker produced and marked frame 1500
    [repro] cycle 19: immediately before route push
    [repro] cycle 19: immediately before route pop
    [repro] cycle 19: route pop completed
    [repro] cycle 20: immediately before route push
    [repro] cycle 20: immediately before route pop
    [repro] cycle 20: route pop completed
    [repro] cycle 21: immediately before route push
    [repro] cycle 21: immediately before route pop
    [repro] cycle 21: route pop completed
    [repro] cycle 22: immediately before route push
    [repro] worker produced and marked frame 1800
    [repro] cycle 22: immediately before route pop
    [repro] cycle 22: route pop completed
    [repro] cycle 23: immediately before route push
    [repro] clean timeout reached; exiting normally
    Lost connection to device.
    PS C:\Google\flutter-190774-repro> 

    Flutter doctor -v:

    [√] Flutter (Channel master, 3.48.0-1.0.pre-111, on Microsoft Windows [Version 10.0.26200.8875], locale en-IN) [3.1s]
        • Flutter version 3.48.0-1.0.pre-111 on channel master at C:\Developer\flutter
        • Upstream repository https://github.com/flutter/flutter.git
        • Framework revision f20f4b26de (21 hours ago), 2026-08-11 10:01:39 +0000
        • Engine revision f20f4b26de
        • Dart version 3.14.0 (build 3.14.0-114.0.dev)
        • DevTools version 2.61.0-dev.0
        • Feature flags: enable-web, enable-linux-desktop, enable-macos-desktop, enable-windows-desktop, enable-android, enable-ios,
          cli-animations, enable-native-assets, enable-record-use, enable-swift-package-manager, omit-legacy-version-file,
          enable-windowing, enable-lldb-debugging, enable-uiscene-migration, enable-riscv64
    
    [√] Windows Version (Windows 11 or higher, 25H2, 2009) [2.3s]
    
    [√] Android toolchain - develop for Android devices (Android SDK version 37.0.0) [3.7s]
        • Android SDK at C:\Users\Puneet\AppData\Local\Android\sdk
        • Emulator version 36.6.11.0 (build_id 15507667) (CL:N/A)
        • Platform android-37.1, build-tools 37.0.0
        • Java binary at: C:\Program Files\Android\Android Studio1\jbr\bin\java
          This is the JDK bundled with the latest Android Studio installation on this machine.
          To manually set the JDK path, use: `flutter config --jdk-dir="path/to/jdk"`.
        • Java version OpenJDK Runtime Environment (build 21.0.10+-14961533-b1163.108)
        • All Android licenses accepted.
    
    [√] Chrome - develop for the web [111ms]
        • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe
    
    [√] Visual Studio - develop Windows apps (Visual Studio Community 2026 18.3.2) [110ms]
        • Visual Studio at C:\Program Files\Microsoft Visual Studio\18\Community
        • Visual Studio Community 2026 version 18.3.11520.95
        • Windows 10 SDK version 10.0.26100.0
    
    [√] Connected device (3 available) [310ms]
        • Windows (desktop) • windows • windows-x64    • Microsoft Windows [Version 10.0.26200.8875]
        • Chrome (web)      • chrome  • web-javascript • Google Chrome 151.0.7922.77
        • Edge (web)        • edge    • web-javascript • Microsoft Edge 151.0.4129.72
    
    [√] Network resources [1,053ms]
        • All expected network resources are available.
    
    • No issues found!
  6. added
    engineflutter/engine related. See also e: labels.
    e: impellerImpeller rendering backend issues and features requests
    platform-windowsBuilding on or for Windows specifically
    and removed
    in triagePresently being triaged by the triage team
    on Aug 12, 2026
  7. self-assigned this
    on Aug 12, 2026
  8. added
    P1High-priority issues at the top of the work list
    on Aug 17, 2026
  9. github-actions commented on Aug 31, 2026

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  10. locked as resolved and limited conversation to collaborators on Aug 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1High-priority issues at the top of the work liste: impellerImpeller rendering backend issues and features requestsengineflutter/engine related. See also e: labels.platform-windowsBuilding on or for Windows specificallyteam-engineOwned by Engine teamtriaged-engineTriaged by Engine team

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions