That object on the left edge of your screen is almost certainly a persistent widget panel, notification flyout, or pinned overlay left behind by the application you closed. Closing a window and closing a process are different operations. When the process does not fully terminate, its interface layer can survive as a separate surface. In current Windows builds, that surface is usually a widgets board, a taskbar flyout, or a leftover WebView2 window tied to a background helper process.
The label you called "Microsoft Wave thingy" is probably not a product name. Microsoft has shipped several things that sound like it: the old Windows Live Wave series (Wave 3 and Wave 4, current around 2008 to 2011), Microsoft Teams' Together Mode, or the Widgets board that arrived with Windows 11 in 2021. Each one leaves different residue. The fix depends on which process actually owns the panel, so the first job is identification, not clicking.
How a closed app leaves a surface behind
A modern Windows desktop is a compositor. The desktop window manager (DWM) draws every visible surface, and each surface belongs to a window handle owned by some process. When you click the X on an app, you send a close request. The app's message loop decides what to do with it. Well-behaved apps destroy their windows, shut down their threads, and exit. Apps that host web content often do not.
The Microsoft Edge WebView2 runtime is the main reason. It runs browser engines inside ordinary apps, and it spawns child processes for rendering, GPU work, and networking. Those children are managed by a broker process, not by the host window. If the host closes abruptly, the broker may keep the renderer alive briefly, and an undestroyed child window can stay on screen as an orphaned surface. Microsoft documents this architecture in its WebView2 process model guidance.
There is a second mechanism. Windows keeps certain UI in a separate process called ShellExperienceHost, which hosts flyouts for the Start menu, calendar, and widgets. On Windows 11, ShellExperienceHost typically runs twice: once for the desktop shell and once for the lock screen. If a flyout is triggered and the triggering app dies before the flyout dismisses, the flyout belongs to the shell, not the app, and it can persist until explicitly dismissed.
A third path is the widget host itself. The Windows 11 Widgets board is a pinned web surface that feeds from MSN. It is designed to be dismissible by clicking elsewhere, but if focus is stolen by a crashed app during dismissal, the board can remain visible over the desktop with no obvious close control.
Plain language: the thing on your screen is a window whose owner forgot to clean up, and Windows lets orphan windows linger because it cannot know whether they are still wanted.
What the object most likely is, by appearance
Identification beats guessing. Match what you see against the table below before touching anything.
| Appearance | Most likely owner | Typical process name | Safe first action |
|---|---|---|---|
| Vertical strip of news cards or weather tiles on the left edge | Windows 11 Widgets board | Widgets.exe or WidgetService | Press Windows key, then Escape |
| Narrow translucent bar with app icons or a search box | Taskbar flyout or Search host | SearchHost.exe | Click the desktop, then press Escape |
| Blank white or gray rectangle with no controls | Orphaned WebView2 child window | msedgewebview2.exe | End the specific child process in Task Manager |
| Panel showing a feed, ads, or "sign in" prompt | MSN or Edge content surface | msedge.exe or Widgets.exe | Close via Task Manager, not the X |
| Tiny bar with a microphone or audio meter | Background helper from a calling or voice app | Depends on the app | Check startup apps and disable the entry |
The single most useful diagnostic is Task Manager's Details tab, sorted by name. Every visible window has a process behind it. If you find a process whose description matches the panel, you have your answer. Do not end processes at random; ending the wrong one can log you out or drop unsaved work in another app.
Quantified context: how common and how long-lived
Orphaned windows are not rare, and they are not permanent. The WebView2 runtime ships with Windows 11 by default and is present on a large share of Windows 10 machines through Edge. Because so many apps embed it, leftover renderer processes are a routine sight in support forums. Microsoft's own guidance treats the broker-child relationship as expected behavior, which tells you the architecture tolerates short-lived orphans by design.
Duration matters more than frequency. A well-managed child process exits within seconds of its host closing. An orphaned surface with no parent message loop can persist for the life of the session, meaning hours, until you sign out or restart. The Windows shell generally reclaims surfaces on sign-out, so a restart is a guaranteed reset. Explorer.exe restarts are a middle option: they rebuild the taskbar and shell surfaces without a full reboot.
Memory tells a similar story. Idle WebView2 renderers commonly hold tens to a few hundred megabytes each, depending on content. A single leftover panel is usually a cosmetic annoyance, not a resource crisis. A cluster of five or more survivors from repeated launches is worth investigating, because it suggests the host app is crashing on exit rather than closing cleanly.
One counterintuitive detail: the X button is often the worst way to close a misbehaving app. The close message can be ignored or mishandled. Ending the process tree from Task Manager is more decisive because it bypasses the app's message loop entirely. Professionals reach for the process tree first when a window refuses to die.
Edge cases that change the diagnosis
Multi-monitor setups complicate everything. A panel that appears "on the left of my screen" may actually be positioned on a virtual desktop edge or a secondary display whose coordinates shifted after a resolution change. Windows stores window positions in the registry, and a disconnected monitor can push a saved window to an unexpected coordinate. Dragging the panel is diagnostic: if it moves, it is a real window with a handle. If it does not, it may be a static overlay or a wallpaper-layer element.
Remote desktop sessions and virtual machines add another layer. When a session disconnects, some host-side UI can freeze in place. On reconnect, the stale surface may still be composited. Signing out of the session, not just disconnecting, clears it.
Accessibility and third-party shell replacements are a third edge case. Tools that draw their own docks or sidebars can leave artifacts when their background service crashes. If the panel appeared after installing a new utility, check its startup entries before blaming Windows.
A fourth case is malware masquerading as a system panel. This is uncommon, but a persistent overlay with no matching signed process deserves scrutiny. Red flags to watch for:
The panel reappears immediately after every restart with no matching app installed. Its process name imitates a system file but runs from a user folder such as AppData. It requests credentials, payment, or a "security scan." It blocks normal interaction with the desktop or cannot be ended from Task Manager. Its publisher signature is missing or invalid in the process properties.
If any of those apply, run a full scan with your installed security software and do not enter information into the panel.
Misconceptions worth correcting
The most common misconception is that closing a window closes the program. It does not. Closing a window sends a request; the process exits only when its code decides to. This distinction explains nearly every leftover panel.
A second misconception is that Task Manager's Apps list is complete. It is not. It groups by top-level window, and orphaned child processes can be invisible there. The Details tab is the authoritative view.
A third is that a restart is overkill. For a single cosmetic artifact, it usually is. Restarting Explorer.exe is faster and often sufficient. But if the panel returns after every session, the restart is not the fix; the startup configuration is.
A fourth misconception concerns the name. People search for the product they remember, and memory is unreliable across a decade. Windows Live Wave 3 and Wave 4 were suites of chat, mail, photo, and toolbar software, and they were retired years ago. Nothing from that era is still running on a current machine unless it was installed manually and survives as legacy software. If you find such an installation, uninstalling it through Settings is the cleanest path.
Plain language: the panel is a symptom of process management, not of a mysterious new Microsoft product.
Practical steps, in order
Work from least disruptive to most, and stop as soon as the panel disappears.
Click an empty area of the desktop, then press Escape. This dismisses most shell-owned flyouts, including the Widgets board, because the shell treats focus loss as a dismissal signal. Press Windows key to open Start, then Escape. This forces the shell to reclaim focus and often clears a stuck flyout. Open Task Manager with Ctrl+Shift+Esc, switch to Details, and look for Widgets.exe, WidgetService.exe, SearchHost.exe, or msedgewebview2.exe with a recent start time. End the specific process, not the whole tree, and confirm the panel disappears. If the panel survives, restart Windows Explorer from the right-click menu on Explorer in Task Manager's Processes tab. This rebuilds the taskbar and shell surfaces in a few seconds. Disable the Widgets board if it keeps returning: right-click the taskbar, open Taskbar settings, and turn off Widgets. This removes the entry point, not just the surface. Sign out and back in, or restart, if steps 1 through 5 fail. This is a guaranteed reset of orphaned surfaces.
For startup problems, open Settings, go to Apps, then Startup, and disable entries you do not recognize. Re-enable one at a time if something breaks. For suspected malware, use your installed security suite's full scan rather than a downloaded tool, and do not pay for a "removal" from a pop-up.
Threshold guidance: one leftover panel per session is normal noise. The same panel returning on three consecutive boots is a configuration problem worth fixing. A panel that cannot be ended from Task Manager, or that reappears within seconds of being ended, crosses into a security concern.
Limits of this explanation, and when to get help
This article describes stable Windows mechanisms: process ownership, the compositor, WebView2 architecture, and shell flyout behavior. It deliberately omits version-specific menu names and any current statistics, because those change between builds and are not needed to solve the problem. Microsoft's documentation on the WebView2 process model and on Windows 11 widgets is the authoritative source for the architecture; consult it if you need build-level detail.
If the panel persists after a clean restart with all third-party startup apps disabled, the cause is outside ordinary Windows behavior. At that point, a repair install of Windows is a reasonable next step, and a qualified local technician can confirm whether the surface is a legitimate shell component or something else. Do not install random "fixer" utilities from search ads.
This is general educational information about how Windows manages windows and processes, not a diagnosis of your specific machine or a security verdict. It does not promise that any step will resolve your issue, and it is not a substitute for inspection by a qualified local professional if the behavior suggests malware or a corrupted system.