Hi Winstep Support Team,

I am experiencing a couple of issues with the Running Applications dock/taskbar in Winstep Extreme and would appreciate your help.

Missing Thumbnails: Google Chrome and several other running applications do not show a thumbnail preview when I hover over them. They only display a generic icon or a blank placeholder.

Invisible Running Applications: Certain active applications are completely ignored by Winstep. They do not appear in the running applications list/dock at all, even though they are open and running in Windows. A few examples of these are Anycubic Slicer Next and the C-Media Audio Panel.

Could you please advise on how to fix these recognition and preview issues? Let me know if you need any log files or further details about my system setup.

Thank you in advance for your assistance!

Best regards,
ChaserJoni

What several other applications? Please make a list.



Do you mean the *iconic* thumbnail (i.e. the icon displayed in the dock) or the *live thumbnail preview* (the tile(s) displayed when you hover the mouse over the icon)? If the iconic thumbnail, the Winstep application is not able to retrieve an iconic thumbnail from all window types.

If the live thumbnail preview, this might show up blank if the application is currently minimized and wasn't restored at least once. The Windows taskbar will show the same (the actual live preview thumbnail is provided by the Windows DWM in both cases).



"Certain active applications" is very generic. Which other applications besides those two?

There are specific rules that determine whether a window should appear in the taskbar as a running application or not (and, as you have probably noticed by now, not EVERY open window appears in the Windows taskbar either). My guess is that those two applications are not following those rules (i.e. they are not “real” top-level application windows in the Win32 sense), but won't know for sure until I install one or both of them here.

Anycubic Slicer Next is based on OrcaSlicer and uses a modern cross-platform UI stack (Qt + Chromium/WebView-ish elements). It is not a classic Win32 MDI app.

C-Media Audio Panel is essentially a driver control panel utility, often launched by the audio driver stack and behaving more like a settings companion/tray app than a normal desktop application.

Hi Jorge,

Thank you for the detailed response! Here are the clarifications regarding the issues:

1. Regarding the missing thumbnails ("What several other applications?" / "Do you mean iconic or live thumbnail?"):

What I meant by thumbnails: I am referring to the feature where, after an application has been open for a while, the dock icon changes from a static app icon into a scaled-down screenshot (live preview) of the actual window.

The issue: This automatic transition to a screenshot/live preview works perfectly for some apps, but for Google Chrome and several others, it never happens—they just keep showing the generic app icon.

Other affected applications: I don't have an exhaustive list, but it mostly happens with UWP/Windows Store apps, such as the Windows Calculator and the Xbox app.

2. Regarding Invisible Running Applications ("Which other applications besides those two?"):

I don't have a complete list of all affected software, as I only notice it when I'm actively using them. However, the Anycubic Slicer Next and the C-Media Audio Panel are the most prominent examples.

Interestingly, regarding your note about the UI stack: the original OrcaSlicer works perfectly and shows up in the Winstep running applications list without any issues, while the Anycubic fork (Anycubic Slicer Next) remains completely invisible to Winstep.

Hope this information helps narrow down the cause! Let me know if you need any more details.

Best regards,
ChaserJoni

Just as I suspected. What you see at the icon level - unlike the larger preview that appears when you hover over an icon - is not a live preview. It is actually a static screenshot of the application's window.

To generate this image, the application asks the target window to draw (or “print”) itself into an off-screen memory surface instead of the actual screen. In technical terms, the application tells the window to render its contents into a memory device context (DC), creating a bitmap snapshot that can then be displayed on the icon.

This feature was first implemented shortly after Windows Vista was released as a way to mimic Vista’s new live thumbnails under Windows XP, which did not have a desktop compositor. At the time, it worked quite well because most applications used traditional Windows GDI/USER32 rendering, where windows could reliably redraw themselves on request.

That is no longer always the case. Many modern applications render through technologies such as GPU acceleration, Chromium/Electron frameworks, Qt, DirectX, OpenGL, WebView, UWP/XAML, or other compositor-based systems. For various reasons, these windows often cannot (or simply do not) redraw themselves into an off-screen DC when asked. When that happens, the application cannot obtain a usable static snapshot and falls back to displaying the application's icon instead.

In contrast, the large previews you see when hovering over an icon are actual live thumbnails provided directly by Windows Desktop Window Manager (DWM) - the compositor responsible for assembling everything you see on screen.

Instead of asking the application window to redraw itself, DWM already has access to the fully composed, up-to-date visual representation of the window (including GPU-rendered content). The application simply tells DWM:

“Render a live thumbnail of this window into this area.”

DWM then draws the live preview directly into the specified window surface. Because the thumbnail is rendered dynamically by the compositor itself - rather than returned as a bitmap - the application cannot simply grab a static image from DWM the same way it can with the older PrintWindow method.

You cannot use this same DWM live-thumbnail method directly on the icons themselves because performance would become abysmal.

In fact, ObjectDock experimented with rendering live thumbnails directly into the dock icons back in the Vista/Windows 7 era. While visually impressive at first glance, the feature proved heavy on system resources and did not work particularly well in practice, especially as more applications became GPU accelerated. The end result was poor enough that it never became a mainstream approach.



Reason I asked for a list is because the way you phrased it made it sound as if this was a widespread issue, whereas from the examples given so far it appears to be limited to a small number of applications - specifically Anycubic Slicer Next and the C-Media Audio Panel.

That said, if you come across other examples, please post them. The more affected applications we can identify, the easier it becomes to determine whether they share something in common and whether this is something that can be improved.



That is actually useful information, thank you.

Since OrcaSlicer appears correctly while the Anycubic fork does not, this suggests the issue is likely related to something specific in how the Anycubic build exposes its main window to Windows (window ownership, styles, taskbar registration, etc.).

I would have to install one of those two applications to figure out what the issue here, but Anycubic is software for 3D printers and I do not own a 3D printer.

Likewise C-Media Audio Panel is also not a mainstream application, it is typically a vendor-specific audio control panel tied to certain sound chipsets/hardware (USB DACs, motherboard audio, gaming headsets, audio interfaces, etc.), often customized by OEMs.

Not sure if I can - or even if I want to eheh - install any of those two applications here.

This said, there might be something I can still come up with in terms of testing on your system why those two applications do not show in the dock as running applications (you have confirmed that they do show in the Windows taskbar, right?)

And actually I just did a minor (but critical) change to the code that determines if a window should appear in the list of running applications or not, that might fix this issue.

I was using GetParent(hwnd) as one of the tests because child windows should not appear on the tasklist, but GetParent may return an owner window instead under certain conditions (not the same thing at all). I replaced the API call with GetAncestor(hwnd, GA_PARENT) which only returns an actual parent window and if that was the source of the problem, it is fixed now.

Hi Jorge,

Thank you so much for the deep dive and the detailed explanation! The technical background regarding how the static screenshots vs. DWM live previews work makes perfect sense now.

Regarding your code change for GetAncestor(hwnd, GA_PARENT): that sounds like a very promising lead! Will this fix be rolled out in the next official automatic update, or is there a beta build I should look out for to test it?

To clarify a bit on the timeline: the thumbnail fallback issue is something I've noticed for a long time, but the Anycubic Slicer Next issue is brand new. It only started appearing recently after sequential updates to both Winstep and the Anycubic software itself. That's what prompted me to reach out and see if it was something fixable. In fact, I even tried rolling back both Winstep and Anycubic Slicer Next to their previous versions to see if it would resolve the issue, but unfortunately, that didn't help either—which makes me suspect that a recent Windows Update might have actually triggered this change in behavior.

Also, just in case it might be relevant to your debugging (though I haven't noticed any direct interference): I use a few other desktop customization tools on my system, including ExplorerPatcher (running Windows 11 with the Windows 10 taskbar style), HideAndShowTaskbarContents, AutoHideDesktopIcons, and TranslucentTB.

Note: I made sure to completely disable all of these tools and test Winstep by itself before reporting this, and the behavior with Anycubic and C-Media remained exactly the same, so they don't seem to be causing the conflict.

Looking forward to testing the fix whenever it becomes available!

Best regards,
ChaserJoni

I had to test if first, and I'm glad I did, documentation says that GetAncestor(hwnd, GA_PARENT) returns NULL (0) if the window has no parent but that IS NOT WHAT HAPPENS. It actually returns the handle of the desktop window - even though GetWindowParent(hwnd) correctly returns 0. Sigh. You can always count on MS to %#"% things up.

Anyway, since you are running Winstep Xtreme, make sure you are running the latest official version first (v26.4 or later) and then download the latest Winstep Xtreme beta from here:

Winstep Xtreme beta:
https://www.winstep.net/xtreme-beta.zip

Do NOT uninstall anything first, just exit all running Winstep applications and run the beta setup file.

There is no need to backup your settings first, but it does not hurt if you do either.

Let me know if this beta fixes the issue with those two applications, please.

Hi Jorge,

Classic Microsoft documentation...! Thank you for digging into that and finding a workaround despite the API not behaving as advertised.

I installed the beta following your instructions, and here are the results:

C-Media Audio Panel: Success! It is now correctly recognized and appears in the running applications list/dock just like it should.

Anycubic Slicer Next: Unfortunately, this one still remains invisible in Winstep, even with the new beta.

To investigate further, I did another test: I completely downgraded Anycubic Slicer Next to an older version, and with that older version, it became visible in Winstep again! As soon as I updated it back to the latest version, it disappeared. This clearly confirms that the Anycubic developers changed something specific about their window management in the latest release.

Thank you so much for your effort and for putting together this beta so quickly to test the fix! I truly appreciate your dedication to tracking down these edge-case bugs.

Best regards,
ChaserJoni