[BUG] UI fails to render after sleeping/waking up laptop

Component

Lite

Performance Monitor Version

2.11.0

SQL Server Version

SQL Server 2022

Windows Version

Windows 11 Enterprise 25H2

Describe the Bug

When running Performance Monitor Lite and closing the laptop lid, upon reopening the laptop and logging back in, the UI has disappeared; however, notification messages continue to pop up with metrics and alerts that change over time, indicating that the application is still running. When I try to rerun the UI, I get an empty window:

Steps to Reproduce

Start Performance Monitor Lite
Verify expected monitoring behavior
Lock the screen or close the laptop lid
Open the laptop lid and unlock the computer
Verify that the running application is now missing from your Windows desktop and that the running application's icon is missing from the Windows task bar
Verify that you still receive alert notifications
Reopen Performance Monitor Lite and verify no UI elements appear in the application window.
Close the Performance Monitor Lite window.
Reopen Performance Monitor Lite and verify expected behavior.

Expected Behavior

When unlocking the lock screen, the application should appear on the Windows desktop and should be represented in the Task Bar. The application should display the information from the tab that was open before the computer was locked.

Actual Behavior

After unlocking the lock screen, the UI was completely missing but the application was still running.

Error Messages / Log Output

No WARNING or ERROR messages were added to the log files; instead, there are Collector INFO messages throughout the problem time window.

Screenshots

No response

Additional Context

No response

Merge pull request #1053 from erikdarlingdata/feature/1050-sleep-wake…

Thanks for the detailed report — the steps and the "notifications still fire but the window is gone" detail were exactly what pinned this down.

There were actually two problems stacked together:

Blank window after wake. WPF renders its UI on the GPU, and a sleep/wake (or RDP reconnect) can tear down that GPU surface in a way WPF doesn't recover from — leaving the window alive (so notifications keep firing) but unable to repaint. Fixed by switching both apps to software rendering, which removes the GPU dependency. Your charts are unaffected because they're drawn on the CPU via SkiaSharp, not the GPU path.
Window disappears from the taskbar. Windows turns the lid-close into a "minimize," and the minimize-to-tray feature then hides the window — with no automatic way back on wake. A new resume handler now brings the window back from the tray when you wake/unlock, if it was on-screen before sleeping (a window you deliberately sent to the tray is left alone).

This is merged to dev (#1053) and will ship in the next release (2.12.0). If you're able to run a dev build once it's available, I'd appreciate confirmation that the sleep/wake cycle behaves for you — but the change is well-grounded in Microsoft's own guidance for this WPF render-thread failure class.

Happy to test a dev build when ready.

@bbishop-neovest

@bbishop-neovest it will be in tonight's nighlty build if you want to test early.

Approximately what time (Eastern)?

Also, the customer service in this place is stellar!

The nightly kicks off at 06:00 UTC, so right around 2:00 AM Eastern. The release artifacts usually show up a few minutes after that once the build and packaging finish — so grab it any time after ~2:15 AM ET and the #1050 fix will be in it.

And thank you — much appreciated! 🙏

@erikdarlingdata

@erikdarlingdata I uninstalled the release build, downloaded the zipped nightly build of PerformanceMonitorLite-2-11-0-nightly.20260604, and ran the PerformanceMonitorLite executable directly from the unzipped folder. The bug still exists, so I am unable to verify the fix. Additionally, simply minimizing the application to the tray removes the application from the tray altogether (per your bug write-up) and causes the same UI rendering problems.

I also note that the build number is 2.11.0 in the "About" window. I expected to see the full nightly build number but perhaps the build process only pulls the major/minor/release identifiers from the full build number?

Fix erikdarlingdata#1050: UI blank/missing after sleep-wake (Lite + D…

@bbishop-neovest

Thanks @bbishop-neovest, and sorry it's still biting you.

First, to clear up your version question: the nightly did include the fix. Nightly builds come off the dev branch, and the 2.11.0 you saw in About is expected — the version only bumps to 2.12.0 at release time, so every nightly until then reads 2.11.0. So the fix was in the build you tested; it just didn't resolve it on your hardware. That makes this environment-specific (I can't reproduce it on my machines), so a few details would help me either reproduce it or build you a targeted diagnostic version.

1. Your sleep type. Open Command Prompt and run powercfg /a, then paste the output. For reference, here's one of my machines — where I cannot reproduce this:

The following sleep states are available on this system:
    Standby (S0 Low Power Idle) Network Connected
    Hibernate
    Fast Startup

The following sleep states are not available on this system:
    Standby (S1)
    Standby (S2)
    Standby (S3)
    Hybrid Sleep

Mine is Modern Standby (S0), so if yours matches, the sleep mode isn't the difference and I'll focus elsewhere — if it differs, that's a strong lead.

2. Graphics + machine (prime suspect right now). Laptop make/model, and what graphics it has — Device Manager → Display adapters (e.g. "Intel UHD + NVIDIA"). Driver version if you can grab it.

3. Monitors. When this happens, are you docked / on external monitors, or just the laptop's built-in screen? And does it still happen undocked, on the built-in display only?

4. The minimize case — the most useful one. You mentioned simply minimizing to the tray reproduces it, but I can't reproduce that locally, so I'd like to pin it down:

On a fresh start with no prior sleep — launch Lite, minimize to tray, restore — does it go blank every time, or only intermittently / only after a sleep earlier in the session?
When it comes back blank, does resizing/dragging the window, or clicking a different tab, make the content reappear?
When it's blank, is the tray icon still present? And when you said minimizing "removes it from the tray altogether" — did you mean the notification-area icon disappeared, or the taskbar button?

5. Logs. Please zip and attach everything in %LOCALAPPDATA%\PerformanceMonitorLite\logs (paste that into File Explorer's address bar), ideally covering a session where it broke.

No rush at all — this just saves us a few round-trips of trial-and-error builds. Appreciate you sticking with it.

I grabbed last night's build.

Power/Sleep Types

The following sleep states are available on this system:
    Standby (S0 Low Power Idle) Network Connected
    Hibernate
    Fast Startup

The following sleep states are not available on this system:
    Standby (S1)
        The system firmware does not support this standby state.
        This standby state is disabled when S0 low power idle is supported.

    Standby (S2)
        The system firmware does not support this standby state.
        This standby state is disabled when S0 low power idle is supported.

    Standby (S3)
        The system firmware does not support this standby state.
        This standby state is disabled when S0 low power idle is supported.

    Hybrid Sleep
        Standby (S3) is not available.
        The hypervisor does not support this standby state.

Display Adapters: Intel Iris Xe Graphics (32.0.101.7084) + NVIDIA RTX A500 Laptop GPU (Driver version 32.0.15.9608).
Monitors: I'm docked and on external monitors when this occurs. I'll test undocked later.
Minimize Case:

Minimizing on fresh start: Window and system tray icon disappear completely but notifications continue to be generated. Reopening the app once gives me a blank window that correctly minimizes to the system tray but won't restore to the desktop with anything but the blank window. Reopening the app twice restores the full UI functionality but restarts the reproducible bug steps.
When the window comes back blank, there are no tabs to click. No amount of resizing/maximizing/moving has any impact to the window's UI state.
Good question about the tray icon! The taskbar button disappears but the notification tray icon remains, and double-clicking the tray icon correctly restores the window under all tested scenarios. For example: When the window is present but there is no UI visible, double-clicking the tray icon renders the full UI in the given window. When the window is completely absent, double-clicking the tray icon restores the window, with its UI, in its last known position.

Logs (attached)

PerfMonLiteLogs_bbishop.zip

Merge pull request #1099 from erikdarlingdata/feature/1050-single-ins…

@bbishop-neovest

@bbishop-neovest — your diagnostics cracked it. Thank you. Two details you reported were the key: it reproduces with no sleep at all (just minimize-to-tray, then relaunch the exe), and double-clicking the tray icon always restores the full UI while the relaunch/taskbar path comes back blank. That told me it wasn't a graphics/sleep problem at all — it's a window-restore bug, which is also why the earlier software-rendering change didn't help you.

Root cause: When the app minimizes to the tray it calls WPF's Window.Hide(), which puts the window into WPF's Visibility = Hidden state. The single-instance "relaunch brings the window back" logic was surfacing the existing window by poking its native handle with a raw Win32 ShowWindow(RESTORE) call. That un-minimizes the native window but never tells WPF it's visible again — so WPF never re-lays-out or re-renders, and you get a visible-but-blank window that ignores resizing/dragging. The tray double-click worked because it goes through WPF's own Show(), which is the only path that reconciles that state. (Your hybrid Intel+NVIDIA / docked setup made it easier to hit, but the bug isn't GPU-specific.)

Fix (merged to dev, PR #1099): relaunching now signals the running instance to restore itself through WPF's Show() path instead of poking the handle. Every way of bringing the window back — tray double-click, "Show Window", resume-from-sleep, and relaunching the exe — now goes through that same correct path. It also fixes a related latent bug where relaunch did nothing at all if the title bar happened to be showing the "update available" banner.

This will be in tonight's nightly (off dev, so available a bit after ~2:00 AM ET). When you grab it, the quickest check is the no-sleep repro you found: launch → minimize to tray → relaunch the exe → it should come back fully rendered. Please also retry your docked + external-monitor sleep/wake flow. Really appreciate you sticking with this and doing the legwork.

Using the new nightly build, the original issue appears resolved; however, there is a new issue introduced:

At startup, a button appears as a running app in the taskbar (icon was missing from button on first test today; seems to be a caching issue because subsequent tests showed the button). Notification tray icon is present.
Minimizing the window removes the window and the blank button from the taskbar (is this the expected behavior?). Notification tray icon still present.
Relaunching the app correctly renders the window.
Clicking the "close" button on the window results in an exception (also see attached logs):

PerfMonLiteLogs_bbishop_20260611.zip

Clicking through the exception modal and clicking the "close" button again succeeds.
Relaunching the app and then immediately clicking the "close" button succeeds without the same exception.

@bbishop-neovest

@bbishop-neovest — this is a great report, thank you. Your #5 and #6 notes are what let me pin the new bug in one pass. Running down all six:

#3 — relaunch renders the window correctly. 🎉 That was the heart of #1050, so the original "blank window" bug is behind us.

#1 — taskbar button at startup, icon missing the first time. Not a bug. An app having a taskbar button at startup is normal, and your instinct is right: the briefly-missing icon is just Windows' icon cache catching up. Nothing to chase.

#2 — minimizing removes the window and its taskbar button. Expected — that's the minimize-to-tray behavior (the notification-area icon staying put while the taskbar button disappears is the tell). If you'd rather minimize behave normally, there's a "Minimize to tray" checkbox in Settings you can uncheck.

#4 — exception when clicking Close. This is the real one, and #5/#6 cracked it.

The Close button runs a graceful-shutdown routine (stop the collectors, flush, etc.) and then asks the window to close a second time once that finishes. The bug: when that shutdown work happens to finish instantly — most likely when the background collector has already gone idle — the second close fires while Windows still considers the window "mid-close," and WPF refuses it with that exception instead of letting it through.

That's exactly why it was intermittent, and your two observations confirmed it:

Lite overview: show Online/Offline status #6 (relaunch, then close immediately) worked because the collector was mid-cycle, so the shutdown had something real to wait on — the second close happened a beat later, after the closing state had cleared.
Lite: collector health status bar shows global errors instead of per-server #5 (dismiss the dialog, close again) worked because the cleanup had already completed on the first attempt, so the second click closed cleanly.

The fix makes that second close always happen on the next UI cycle — after the "closing in progress" state has cleared — so it can't re-enter and throw, regardless of how fast the shutdown finishes. Worth noting this was a latent issue in the close path, not something the #1050 relaunch fix introduced; you're just the first to reach a normally-rendered window and exercise a clean close.

It's going into dev now and will roll into a nightly (the usual ~2 AM ET build off dev) — I'll confirm here once it's in a build you can grab. When you test it, the quickest checks are: open → Close, and minimize-to-tray → restore → Close. Really appreciate you sticking with this.

Merge pull request #1109 from erikdarlingdata/feature/1050-close-reen…

Confirmed good behavior now. I followed the "quickest checks" tests as well as other window manipulations. Thanks for fixing the problems!

Woohoo! Glad it's finally fixed!

Fix erikdarlingdata#1050: restore window via WPF Show() on relaunch, …

Fix erikdarlingdata#1050: defer re-close off the Closing event to sto…

Wire the viewer tray + headless alert-toast poll, making MinimizeToTr…

Navigation Menu

Repository navigation

[BUG] UI fails to render after sleeping/waking up laptop #1050

Component

Performance Monitor Version

SQL Server Version

Windows Version

Describe the Bug

Steps to Reproduce

Expected Behavior

Actual Behavior

Error Messages / Log Output

Screenshots

Additional Context

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[BUG] UI fails to render after sleeping/waking up laptop #1050

Description

Component

Performance Monitor Version

SQL Server Version

Windows Version

Describe the Bug

Steps to Reproduce

Expected Behavior

Actual Behavior

Error Messages / Log Output

Screenshots

Additional Context

Activity

erikdarlingdata commented on Jun 3, 2026

bbishop-neovest commented on Jun 3, 2026

erikdarlingdata commented on Jun 3, 2026

bbishop-neovest commented on Jun 3, 2026

erikdarlingdata commented on Jun 3, 2026

bbishop-neovest commented on Jun 4, 2026

erikdarlingdata commented on Jun 9, 2026

bbishop-neovest commented on Jun 10, 2026

erikdarlingdata commented on Jun 11, 2026

bbishop-neovest commented on Jun 11, 2026

erikdarlingdata commented on Jun 11, 2026

bbishop-neovest commented on Jun 12, 2026

erikdarlingdata commented on Jun 12, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions