I think this is just a stupid bug and not really a technical problem, since the correct icon is shown for UWP apps pinned to the dock, and the correct UWP app is launched too.

So it should be quick to find and fix (fingers crossed).

And fixed. Just a stupid logic error, as I suspected. My head must have been in the clouds when I did that.

YAY!! Knew you would figure it out! New BETA coming soon??

Released a minute ago.

Should solve all the UWP issues. It's already using the external DLL resource for effect animations too, so if you notice any performance issues with the effects (you shouldn't) please let me know.

In other news, I've just read an uninstall survey from a user complaining that the Alarms feature 'crashes frequently'. Has anybody had any issues with it? Who here uses that feature frequently?

The problem is that the user didn't leave an email address so I could contact him and figure out what is going on. I hate it when that happens!

The only time I remember the Alarms feature doing something odd was after I tried to do a System Restore after an update from my anti-virus program knocked out one of my external hard drives which BTW, appears to be permanently incapacitated.

I guess something went wonky on my system at some point and it won't successfully do a System Restore. I had to redo the Alarm settings but this obviously happened because of the attempted System Restore.

Since redoing the settings I haven't had any problems and all of the alarms I set work as they should.

Thanks, Windy.

Everyone else, is UWP app handling working as it should now?

Jorge, Microsoft Edge does not want to play nicely. You seem to have corrected the issues for UWP handling for the other apps, but Edge still wants to be a pain in the butt.

If not pinned to the dock and running, the icon for Edge is sometimes the generic "package" icon.

When pinned to the dock and running, it shows the correct Edge icon but it doesn't show the running indicator.

Except for Edge, the other UWP apps seem to work fine now. They show correct icon and running indicators. You just need to take another look at how Edge is behaving.

See my attached screenshots. I also included Taskbar in the screenshots so that you can see which apps are running.

Thanks for the screenshots, they really help.

I forgot about Edge, and that actually opens another can of worms for UWP apps that change their windows caption.

This has to do with how you know when an application is running or not.

Under Win32, the running applications list is constructed based on top level windows that are currently open. It's actually not as simple as that because many top level windows are not supposed to show up on the taskbar, so a set of rules has to be applied to filter out which ones should not appear.

Likewise, you cannot do this via the process list (running applications) because many running applications do not have a window or they actually 'own' more than one window.

Now, through the window handle of the windows that *do* show up, you can get the name of the process that owns them (i.e.; executable name) via the API.

For instance, if a Notepad window is open, through the handle (identifier) of that window you can ask Windows to tell you which executable it belongs to (e.g.; C:\Windows\System32\notepad.exe)

It is the name of the executable that is then used by the Winstep application (and the Windows taskbar) to group windows together, i.e.; you group together all windows that belong to/are owned by the same executable.

UWP apps are totally alien to this system. It's like foreign DNA mixing with normal human DNA, and what you get is some kind of an hybrid.

UWP apps do not have an executable (well, some do have what appears to be an .exe, but it is definitely not a Win32 executable).

It was not easy to figure all this out, but eventually I discovered how from the handle of a UWP app window I could get what is called an 'Application User Model ID'. It's the closest thing to a Win32 executable you are ever going to find, a unique identifier to that app.

Now here is the problem: to figure out if a Win32 application pinned to the dock is running, you first enumerate all the processes running on the computer at the time (each process is owned by a Win32 executable) and you then compare the name of your pinned application executable to that list of running processes/executables. If you find a match, then that particular Win32 application is currently running.

Since UWP apps do not have a Win32 executable (instead all of them being hosted by the same generic ApplicationFrameHost.exe) there is nothing to compare pinned UWP apps to in a useful way (there is no 'currently running UWP apps list' equivalent to the current process list).

So, to quickly know if a pinned UWP app is running, I actually look for it in the list of currently open windows instead. I look for a window with a ApplicationFrameWindow class and with the same name as the UWP app.

This works fine for UWP apps that never change their names/captions (e.g.; Calculator, Weather, Store, etc...) but Edge is different because its window caption actually reflects the name of the currently open page as well.

Well, guess this means I need to scratch this method and come up with something else... and also figure out why Edge sometimes uses the generic 'package' icon in the list of running applications at the right (I already have a pretty good idea given how messy MS's implementation of UWP apps with Win32 is, lol).

Wow! Sounds very complicated. I'm confident you will figure a new, better approach. Oh...and FYI - the Mail UWP app is another one that changes its caption. The Mail UWP app will show a window caption specific to the user's inbox name (gmail, yahoo, outlook, etc.). So you might want to re-vist the Mail app as well.

Oh, it's ok, I do it for one, I do it for all.

OUCH!!!!

While looking at this UWP stuff I just found and fixed a MAJOR memory leak (and possibly GDI too) that goes all the way back to v16.2!!

This will happen if you have 'combine dock icons with running applications' and an icon at the *left* side of the dock is showing more than one running instance (i.e.; you get a number overlapping the icon representing the number of currently open windows for that application).

Every time the dock gets updated (and this can happen every 5 seconds under Windows 10) you leak memory for each of the icons showing an overlapping number. This is because the original image (the one without the overlapping number) never gets destroyed.

How this wasn't spotted sooner is anybody's guess. I only spotted it because I was experimenting with the pinned UWP apps, in which case you also leak GDI handles (besides memory). You only have a limited number of GDI handles you can use, so the application ends up crashing before you run out of memory (which would take a long time), and it was this crashing that made me spot this HUGE bug.

holy crap! applied the fast boot option, rebooted, and !BAM! there it was. That's really excellent Jorge.
There's something else I noticed: Used to be that when WS first loaded and I clicked on a tab, it would take a bit to get all the icons loaded correctly. Sometimes, everything would get solid black, including the space which is taken up by the expanded shelf in both WS and NS. Might take 10 seconds or so to calm down.
That doesn't happen anymore. At all. I click on a tab and all the icons are right there already loaded, no more lag or anything. Very glad you fixed that one.
Auto backup is working as it should. MS app icons look good.

Win10 with computer account, not MS account, log in.
Thanks Jorge.

Thanks! I believe 'holy crap' were also my exact words when I first saw Fast Boot in action on my Windows 10 machine. I was expecting *some* speed-up, but I really wasn't expecting THAT.



Hmmm, I did some work on how the Shelf caches icons in v16.5 (so thumbnails do not get destroyed when the Shelf needs to rebuild the icon cache, for instance), but I don't think that would have the effect you described.

By everything getting solid black, you mean WS would become unresponsive for a while? I only see something like that possibly happening if one of the items in the Shelf is stored on a network drive. Windows can take a very long time to establish the connection for the first time.

Anyway, here is what should actually happen:

Each icon needs to be retrieved from a file on the disk, so loading all the icons in a Shelf tab can take some time. For the Shelf not to become unresponsive (or take too long to switch to a different tab when you click on a tab header), as *each* icon is rendered the Shelf takes note of how much time has elapsed since it began rendering those same icons. If it's more than a certain time limit, it stops fetching icons from disk and instead renders all the remaining icons as a generic 'blank' icon, which is really, really, fast.

It then uses a timer to fetch the remaining icons from disk, one by one, replacing the generic icons with the correct icon. The Shelf remains fully responsive while it's doing this.

Once that phase is over, it then starts rendering document and image thumbnails (document thumbnails can take even longer to render than icons, which is why you don't get them immediately when you first open a Shelf tab). In the case of document thumbnails you now get that cool fade out/fade in effect as the icon is replaced with the thumbnail image.

For multi-row tabs (for instance, a Shelf tab displaying the contents of a folder with lots and lots of files in it) the Shelf also renders the next invisible row of icons in the background, even though you can't see it until you scroll down. This is so that when you do scroll down, those icons will have already been pre-rendered and will be there waiting for you (at which point the *next* invisible row is also pre-rendered in the background and so on...).

All these already rendered icons are then cached in memory when you switch to a new tab. Because they are cached in memory, they no longer need to be fetched from disk the next time you switch back to that tab, and will now appear nearly instantly.

See? All the tricks one has to use to speed things up?

I was actually going to ask about why 3 icons get loaded instantly in one of my sub-docks and the others show as generic icons for a few seconds. But you answered my question already.

So, would moving my icons from a regular HD to an SSD speed the loading of my dock icons and prevent this? Also, can we change the generic icon to something a little less blurry?

All my apps are installed on my system drive. Data files are stored on an external USB. So loading the icon images shouldn't be a problem as I have no links to the USB drive.
What was happening happened *only* the first time I would click on a tab. I have 5 tabs. So, boot up, everything loads up. WS is docked on the top of the screen.
Click tab 1, which has 11 items. The icons at first are all generic looking, then they start to appear 1 at a time, slower than what I would expect.
While this is happening, Nexus expands from it's hidden location on the left side of my monitor, but then the entire Nexus working area becomes solid black. No icons are visible. The same thing happens with WS. The entire part of the screen which WS takes up when expanded turns solid black, no visible anything. They stay that way for maybe 5-7 seconds. Then all the icons appear normally and WS contracts to the top and Nexus disappears to the left.
When I then click on tab 2, the same thing happens again.
After I have clicked on all the tabs, I can then click on any tab with no problems.
So far with the last two updates, this behavior has disappeared. However...
I use CCleaner and WiseCare 365. Is there a possibility that one or both of these apps are deleting the icon cache? I'll play around a bit.