All posts by Ed Tittel

Full-time freelance writer, researcher and occasional expert witness, I specialize in Windows operating systems, information security, markup languages, and Web development tools and environments. I blog for numerous Websites, still write (or revise) the occasional book, and write lots of articles, white papers, tech briefs, and so forth.

Reboot Cures MIA USB-C Port

Sometimes, I just don’t get it when Windows gets weird. This time, it’s one of my two Lenovo ThinkPad X380 Yoga laptops (i7-8650U, 16 GB RAM, 1 TB NVMe SSD; vintage 2018). I noticed my USB-C attached NVMe enclosure was MIA, Plugging and unplugging did no good, either. The drive worked fine in another, newer laptop (Lenovo ThinkPad P16 Mobile Workstation: 11th gen i7, 128GB RAM, 2×1 TB NVMe SSD). I soon figured out that a reboot cures MIA USB-C port on the X380. Bizarre!

Hold on: A Reboot Cures MIA USB-C Port

Because the drive worked right away in the other laptop, I was pretty sure the issue was with the USB-C port, not the drive. And indeed, when I rebooted the X380 Yoga the USB-C-attached NVMe enclosure once again showed up and worked at expected speeds (it only ran about half that rate when plugged into a USB 3.2 Type A port via conversion cable).

What the hey? I’m speculating, but my best guess is that when the X380 goes to sleep it loses track of — and connection with — the USB-C port. Works fine now, though… The lead-in graphic shows this as the E: drive with a 1TB SSD ensconced therein.

When in Doubt … Reboot

It never fails to amaze and amuse me that the old “three-fingered salute” (anybody else still remember CTRL-ALT-DEL?) still fixes so many Windows weirdnesses. At least, it’s just something momentary. To no surprise, the search string “X380 Yoga USB-C port disappears after sleep” auto-completes when I start typing the word “disappears.” That tells me my experience is not unique: Google knows about it, too. Go figure!

And that’s the way things go here in Windows-World. Hopefully, I’ll remember what to do the next time this happens…

Added 2Hrs Later: Confirmed!

I let the X380 go to sleep and when I woke it back up, once again the USB-C NVMe drive disappeared. After another reboot, it’s baaaack! I’d have to say this confirms my sleep-based hypothesis. OK, then…

 

 

Facebooklinkedin
Facebooklinkedin

Introducing Microsoft PC Manager

Last Friday, I learned about a new Beta Windows utility from Microsoft called “PC Manager.” It’s available for download and use right now on both Windows 10 and 11. There’s just one problem: I couldn’t get it to install from the download for either OS. But since I’m introducing Microsoft PC Manager here and now, you know I’ve figured out a workaround. Yep: there’s a Winget package for this tool, and it installs through that approach just fine.

Still Introducing Microsoft PC Manager, Despite Installer Fail

If you run the download file named MSPCManagerSetup.exe it simply hangs, even when you agree to its terms and conditions. It just sits there, doing nothing, like so:

Introducing Microsoft PC Manager.install-hang

Even after agreeing to the terms, the installer presents no option to actually install the tool. Stuck!

I figured there might be a winget package manifest for this tool, seeing as how it’s a Microsoft thing. I was right. It took a bit of poking around, but I eventually hit paydirt on the string “PCManager.” Here’s a screencap with the right install syntax (and a successful installation).

Winget install Microsoft.PCManager does the trick!

Again: Introducing MS PC Manager

Here’s what the startup window from the application looks like. It provides information into PC health, storage, processes and startup apps, as well as cleanup and security stuff.

Introducing Microsoft PC Manager.program-running

OK then: here’s the home window for the Microsoft PC Manager (Beta) utility.

Health check takes a couple of minutes to run, and found excess files and baggage, as well as numerous startup items to cancel out. Storage Manger offers options for deep cleanup, large file management, app management and storage sense. Deep cleanup found and removed another 3.6 GB of “stuff” on my PC; large files created a single-pane display of all files over 100 MB on my system (you can set thresholds at 10, 50 and 100 MB, and 1 GB: pretty handy). Manage apps simply moves you to Settings → Apps → Apps & features, where you can review and manage what you’ve got. Storage Sense does likewise for Settings → System → Storage → Configure Storage Sense or run it now. All pretty handy, and worth fooling around with. Check it out!

In a future blog post, I’ll dig further into the Security button at the lower right. It has at least one interesting capability that I’ll also be writing about in an updated story for ComputerWorld soon (I hope).

Facebooklinkedin
Facebooklinkedin

Dissecting Winget Logs Shows Root Causes

Hmmmm. I just did something risky, or perhaps dumb on my production PC. You can see the evidence in the lead-in graphic, a PowerShell session that shows an issue (in red, at bottom) with the installer hash for a Google Chrome update. What you can’t see is that I was already updating Chrome inside Chrome itself while this was happening. The installer changes when a new version is installed. Fortunately, dissecting Winget logs shows root causes, so that’s what I did next. It was more illuminating than the error message, for sure…

How Dissecting Winget Logs Shows Root Causes

First, some background on Winget logs. You can find out more about them (and related troubleshooting stuff) in the MS Learn article “Debugging and troubleshooting issues with the winget tool.” It also gives you a huge honkin path where the log files reside — namely:

%LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

But, rather than grab and use this, I simply told Voidtools Everything to show me all instances of the final directory name DiagOutputDir. That got me there a whole lot faster!

Once into the logfile named WinGet-2023-07-21-10-59-05.148.log I jumped to the bottom to see how it mentioned Chrome. Here’s the tail end of that log from 11:00:09 to 11:00:14.


2023-07-21 11:00:09.043 [CLI ] Generated temp download path: C:\Users\etitt\AppData\Local\Temp\WinGet\Google.Chrome.115.0.5790.99\2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26
2023-07-21 11:00:09.043 [CORE] Downloading to path: C:\Users\etitt\AppData\Local\Temp\WinGet\Google.Chrome.115.0.5790.99\2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26
2023-07-21 11:00:09.044 [CORE] DeliveryOptimization downloading from url: https://dl.google.com/dl/chrome/install/googlechromestandaloneenterprise64.msi
2023-07-21 11:00:13.663 [CORE] Download completed.
2023-07-21 11:00:14.593 [CORE] Started applying motw to C:\Users\etitt\AppData\Local\Temp\WinGet\Google.Chrome.115.0.5790.99\2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26 with zone: 3
2023-07-21 11:00:14.602 [CORE] Finished applying motw
2023-07-21 11:00:14.603 [CLI ] Package hash verification failed. SHA256 in manifest [2c925b57d4892c4fbe177b3d7f91098a3bcdb0d95957c37872a1244bf9edae26] does not match download [aae26a4cf7d92a4c9198d8fac9534670e9fb5f8d1e38897d99b0b51e68107d2a]
2023-07-21 11:00:14.604 [CLI ] Terminating context: 0x8a150011 at D:\a\_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\DownloadFlow.cpp:15e
2023-07-21 11:00:14.604 [CLI ] Terminating context: 0x8a15002c at D:\a\_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\InstallFlow.cpp:28a

I bolded the line where things went south. Basically, the hash verification failed because I had already overwritten the old version of the installer with the new version (and the new Chrome version itself, as well). Good thing winget is smart enough to recognize the ground has shifted under its feet. If it finds things it doesn’t expect, it wisely decides to quit what it’s doing. Now I know what I had always suspected. And now, of course, you know too. Cheers!

Facebooklinkedin
Facebooklinkedin

Windows 11 Dev Channel Adventures Begin

OK, I admit it: in the wake of the recent uplift from Dev to Canary Channels for Windows 11, I didn’t dedicate another machine or VM to the former. But with all of the recent news about cool stuff showing up there, I’ve decided it’s time that my Windows 11 Dev Channel adventures begin … again! Right now, in fact, the Lenovo Yoga is working through the post-GUI install phase for Build 23506.

When Windows 11 Dev Channel Adventures Begin, Then What?

There will be lots of exciting new stuff to investigate and learn here, if what I’m reading online is correct. The 23506 announcement is, in fact, chock full of stuff, including:

  • Passwordless experience with Windows Hello for Business
  • Unsafe password copy and paste warnings
  • Local file sharing improvements
  • Outlook for Windows becomes an inbox app
  • New post-Out-of-box (OOBE) experience
  • Expanded auto color management (ACM) capabilities
  • GA for Windows Copilot preview (a big draw for me)
  • Updated backup preferences (really curious about this, too)

And there’s quite a bit more I’m skipping, so do read the announcement for more gory details. And while I’ve been writing this, the new Build has finished installing. You can see the winver output as the lead-in graphic above. I’m there, so now I need to so some exploring and experimenting. Stay tuned: I’ll follow up!

Note: Courtesy of Bing Chat, here’s more info about MOTW:

MOTW stands for “Mark of the Web”. It is a security feature that helps prevent web-based content from accessing resources on your computer and helps prevent malicious content from running on your computer. When you download a file from the internet, it may be marked with MOTW. This mark indicates that the file came from the internet and may be potentially harmful. When you try to run a file that has been marked with MOTW, Windows will display a warning message1.

 

Facebooklinkedin
Facebooklinkedin

Dev Home Goes Drag’n’drop

With the latest version in the Canary Channel, Windows 11 Dev Home goes drag’n’drop with dashboard widgets. I read a tweet about it from Kayla Cinnamon this morning. And sure enough, once I’d downloaded the latest MS Store updates, it worked as advertised.

Details for Dev Home Goes Drag’n’drop

In this utility, the dashboard is where you can pin widgets. Once that little detail is taken care of, it takes version 0.301.198.0 or higher to exercise the drag’n’drop capability. If you look at the initial lineup in the lead-in screencap you’ll see this widget order: CPU-GPU-Network-Memory. Just for grins the screencap below shows Memory in first position, with the original CPU-GPU-Network order still intact (just shifted one position right).

Dev Home Goes Drag'n'drop.after

To institute the new order, I dragged Memory from the rightmost to the leftmost position. [Click image for full-sized view.]

There’s a Blog Post for That

For all the details about version 0.3, see the July 19 Windows Blogs post entitled “Dev Home Preview 0.3 Release.” In addition to this visible and welcome change, it also mentions various bug fixes and a raft of “Miscellaneous improvements.” There’s also a handy link to the Dev Home docs site that’s worth following. Good stuff, all the way ’round!

Facebooklinkedin
Facebooklinkedin

WinGet Upgrade PowerShell Working

At the end of last month, I blogged about an interesting issue: when you used WinGet to upgrade PowerShell (in PowerShell) that operation would complete, but the screen wouldn’t update properly. As I reported, it showed cancelled and required opening a new PS session to see the current, upgraded version number. No more: now, MS has WinGet upgrade PowerShell working as it should be. See the lead-in graphic for visual proof.

If WinGet Upgrade PowerShell Working, Then What?

No more weirdness in the self-upgrade process, I guess. The lead-in graphic shows that PowerShell updated the initial session window to match the current version (7.3.6) with the version number at the top of the that window. Indeed, I’m forced to *SWEAR* it said 7.3.5 when I started, and appeal to the 2nd line of the WinGet upgrade output because I didn’t think to capture “before” and “after” screencaps. LOL, it didn’t occur to me that the developers would rewrite the terminal window to update the version number. But they did!

I contacted Demitrius Nelon, Team Lead for WinGet at MS to report this weirdness, which he confirmed for me. What he didn’t tell me was that they fixed this in the 7.3.6 release. But its behavior, as shown in the lead-in graphic, speaks for itself. Good stuff and thanks, people: good job.

Got It on Another PC!

I went to upgrade another PC and *DID* capture the initial screen showing 7.3.5 at the top. No more swearing: here’s the screen before the 7.3.6 upgrade completes so you can see the old version number in its top line.

WinGet Upgrade PowerShell Working.X390

See!? There’s the old version number before the 7.3.6 update completes. It’s like magic!

Note added 7/19: looks like this capability (no cancelled and updating version number) may only be in Windows 11. When I updated my sole remaining Windows 10 physical PC this morning, the cancelled message recurred as in my earlier blog post on this subject. Go figure!

Facebooklinkedin
Facebooklinkedin

Failing Backup Signals Regime Change

OK, I think that’ll do it for my current production PC. I noticed this morning what when my scheduled backup started,  it failed almost immediately thereafter. Further investigation into the Macrium Reflect logs shows me it has failed since last Friday. That’s because on the weekends I’m not usually at my desk at 9AM when the scheduled job runs. Upon further investigation, the N: drive where I target my backups had gone missing (it came back after a  restart, though). Nevertheless, this tells me it’s time to start acquiring parts to build a replacement PC. That’s why I aver that a failing backup signals regime change. My 2016 vintage i7 Skylake needs to go.

Why Failing Backup Signals Regime Change

It’s just not right that a drive attached to one of the SATA ports on my Asrock Z170 motherboard should drop off the map over the weekend. And now, dear readers, you know why I schedule my backups to occur while I’m working at the PC: it’s the best way to get timely notification that “something aint’ right.” That’s what happened this morning, and that’s what tells me:

  • I’ll need to keep a close eye on this daily until I transition to a new PC, to make sure scheduled backups run to completion
  • It really, really is time for me to transition over to a new primary production PC

For sure, 7 years isn’t a bad lifetime for a heavily used, major storage PC. Indeed, I’ve got a nominal 17.1 GiB, or approximately 15GB of storage on this beast. Of that total, about 40% (6GB) is occupied, so I’ll throw a couple of new 8 GB SATA drives into my new BOM for the build, along with 2 2TB NVMe PCI-e x4 or x5 SSDs.

It’s Now Official: I’m Transitioning

I’ll wait until August 1 or thereabouts to start pulling parts together for the new build. I’ve already got an Nvidia 3070 Ti GPU and a Seasonic Focus PX-750 PSU I can use. I’ll need a new case, a CPU, 64 GB RAM, the aforementioned SSDs and HDDs, and a motherboard. That will give me something to think about — and report on here in my blog — as the month winds down.

I think I’ll call my old buddy Tom Soderstrom, who still reviews motherboards and CPUs for Tom’s Hardware, to ask for his recommendation on a new build. I need to decide on AMD vs. Intel, after which the rest will follow pretty naturally. Stay tuned: I’ll keep you posted.

Facebooklinkedin
Facebooklinkedin

Windows Terminology: Enablement Package KB (eKB)

In Microsoft’s Windows Client roadmap Update: July 2023 (published yesterday, July 13) I came across a new (to me, anyway) buzzword with associated acronym. As I add to my Windows terminology, enablement package KB (eKB) is now on the list.

Here’s the quote that got me looking around to learn more (I bolded those key words):

The upcoming Windows 11, version 23H2 shares the same servicing branch and code base as Windows 11, version 22H2. What does it mean for you? If you’re running Windows 11, version 22H2, it will be a simple update to version 23H2 via a small enablement package (eKB). Do you remember updating from Windows 10, version 1903 to 1909? Or how you’ve managed recent updates beginning with Windows 10, version 20H2 through 22H2? It will be that simple. Moreover, since both versions share the same source code, you don’t need to worry about application or device compatibility between the versions.

There’s also a Note of some interest as well. It reads:

Note: The eKB is not available on Volume Licensing Service Center. Media packages contain the complete Windows 11 operating system.

In fact, that last item is what really caught my attention and got me looking around, because eKB is an abbreviation/acronym I’d not seen before. My take: if MS thinks eKB is a thing, I’d like to know what kind of thing it is. Here goes…

Chasing Down Windows Terminology: Enablement Package KB (eKB)

A search on the acronym took me back to March 2022, to an answers.microsoft.com post. Entitled “What is Enablement Package KB (EKB)…?” it took me to an early instance of that terminology. It also references the KB5003791 announcement, which talks about enablement packages in general (though it doesn’t use the eKB term itself).

In the simplest of terms, it means that we’ll transition from 22H2 versions of Windows 11 to 23H2 versions through a small and simple Cumulative Update (CU), rather than a lengthy Windows install-based upgrade. A long story, for a short conclusion.

And if you look at the big quote above, the part that starts “Do you remember updating…?” provides some recent, notable examples of an eKB even if it doesn’t tie it directly to that term.

Now I know what an eKB is. And, if you’ve read this through, so do you. Cheers!

Facebooklinkedin
Facebooklinkedin

Canary Build 25905 Gains Upgrade Repair Install

I guess it’s been a long time coming, because MS has waltzed around this topic for two years or more. The latest top-level Insider Preview now includes the option shown in the lead-in graphic. That’s right: Canary Build 25905 gains upgrade repair install capability via WU, built-in. This may make it unnecessary to visit UUPDump to generate ISOs which may then be mounted for such use.

What Canary Build 25905 Gains Upgrade Repair Install Means

Visit Start → Settings → System → Recovery, then look for the item labeled “Fix problems using Windows Update” (as shown in the lead-in graphic). This takes you through a number of screens en route, as shown here:

Canary Build 25905 Gains Upgrade Repair Install.01
First you must grant permission for the repair to start

After you click OK (irrespective of whether or not you allow a timed reboot), you’ll move into Windows Update where you’ll see a display like this one:

Windows downloads and installs a repair version of your OS, before moving into the post-GUI phase.

This can take a while: on my 2018 vintage Lenovo ThinkPad X380 Yoga, it took an astonishingly long 45 minutes to download and install to the first reboot. I was able to keep working until then, but after that, the installer took the desktop away for about another 10 minutes. When it’s time to reboot to continue the repair install you’ll see something like this:

Canary Build 25905 Gains Upgrade Repair Install.restart warning

Once the GUI installer gets done, you will restart to complete repairs.

After the restart warning, it takes another 3 minutes to get to the actual reboot. Then the real post-GUI work begins. All in all it took 55 minutes to get to a desktop as the repair install completed: 45 minutes for download and initial install; 10 more minutes for reboot and post-GUI install.

Trade-offs, Trade-offs

Here’s the deal: it takes about 12 minutes on the same PC to use a mounted ISO to get through the same process. But that means building a current ISO from UUPDump which takes about 25 minutes to complete. Thus it’s a matter of more personal effort to do it manually via UUPDump (37 minutes) for a little less time versus the ease and convenience of letting WU handle it for (but taking 55 minutes to complete). Interesting!

Facebooklinkedin
Facebooklinkedin

Ongoing Build 22631.1972 Oddities

Hmmmm. Yesterday was “Update Tuesday.” As I made the update rounds on my small PC fleet, I noticed something odd as I was downloading updates for my Beta Channel test PC (a Lenovo X380 Yoga). It’s depicted in the lead-in graphic, and led to further, ongoing Build 22531.1972 oddities when all was said and done. Please, let me explain…

Working Through Ongoing Build 22631.1972 Oddities

First, take a look at the lead-in graphic. Hint: consternation hits at the bottom of the update list. Note the same update occurs twice, each with “Completed” status — namely KB5007651 (a Defender antimalware platform update). Weird!

Immediately after, it gets weirder. First, I rebooted once the updates completed (twice, just to be on the safe side). Then I ran DISM … /StartComponentCleanup. I observed the following outcome:

Ongoing Build 22631.1972 Oddities.dism-clean

Error 6824 “another …pending transaction” pops up. A first!
[Click image for full-sized view: this one’s hard to read.]

As usual, I went haring off to Google to see what was recommended. Heck, I even tried it out on Bing’s ChatGPT sidebar. Here’s what came back:

Alas, a second (and even a third) reboot didn’t clear the error, either. The same condition held upon repeated retries of the afore-cited DISM command — namely:

dism /online /cleanup-image /startcomponentcleanup

I’m thinking it’s time to try an in-place upgrade to repair this Windows installation. It should rebuild the component store which is likely to fix this issue and the strange ongoing presence of 13 spurious items therein in need of (impossible cleanup). I think I’ll visit UUPDump and build an image for 22631.1972. Hopefully, that will do the trick. Stay tuned!

Facebooklinkedin
Facebooklinkedin