Category Archives: PowerShell

Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog

Dissecting Winget Logs Shows Root Causes

July 21, 2023 Ed Tittel Leave a comment

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!

Cool Tools, PowerShell, Recent Activity, WED Blog, Windows 10, Windows 11

WinGet Upgrade PowerShell Working

July 18, 2023 Ed Tittel Leave a comment

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.

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!

Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 10, Windows 11

PowerToys Team Closes WinGet Gap

July 7, 2023 Ed Tittel Leave a comment

Now THAT’s what I like to see. Yesterday morning, I noticed a new version of PowerToys (v0.71.0) was out. So quite naturally, I ran WinGet to upgrade same. No dice. At 11:45 AM (Central) I tweeted about this. I observed it was “kind of surprising to see a new PowerToys release…without a matching WinGet upgrade manifest.” 8 minutes later, the team leader responded “we’re working on it.” And by that afternoon, the PowerToys team closes WinGet gap. There’s a working manifest for version 71 in place. Neat-o, and thanks, people!

PowerToys Team Closes WinGet Gap Quickly

It’s a real testment to the energy and drive of the teams involved that things were already in progress as I reported in. (In fact, I heard from the WinGet team lead, too.) This morning I installed PowerToys on the Lenovo ThinkPad X1 Extreme (8th-gen i9, 32 GB RAM, 1.5 TB SSD) and got the latest version. That sequence appears as the lead-in graphic above.

If you look at that graphic, you’ll see that WinGet found only a Zoom upgrade. Oops! That’s because PowerToys wasn’t installed on this PC — yet. But when I did install the .exe version (Microsoft. Powertoys) 0.71.0 (shown as v0.71.0 in the thumbnail at lower right) appears. That’s exactly what should have happened,. It also shows the WinGet manifest for that version of PowerToys is present and working properly.

Always Nice When Things Work Out…

I must say that both the WinGet and PowerToys teams have always been great to work with. They respond to input, questions, and feedback quickly. And when they have to act, they tend to do so sooner than later. Thus, my thanks to Demetrius Nelon (WinGet team lead) and his merry munchkins, as well as Clint Rutkas (PowerToys team lead) and his peppy people, too. Please: keep up the good work.

Cool Tools, Insider stuff, PowerShell, WED Blog, Windows 10, Windows 11

Sussing Out WinTerm Color Schemes

July 6, 2023 Ed Tittel Leave a comment

In my writing and research work for TekkiGurus, I’m pursuing a GitHub project that works within the Windows Terminal environment. It’s called ColorTool. Simply put, ColorTool shows the colors used in the console window; it also lets you tweak them. Its color charts are kind of interesting and I’ve trying to figure them out. MS has a tendency to show them inside an Ubuntu command session inside Windows Terminal. I show them as they pop up in PowerShell in the lead-in graphic. As I’m learning how this all works, I’m sussing out WinTerm color schemes, too.

Bing Chatbot Helps When Sussing Out WinTerm Color Schemes

I’ve been reading a lot, and asking around to try to learn how to decode the values that show up in the display form of a Windows Terminal color scheme. So far, it’s proved rather more challenging than I had expected. So far, I’ve been attacking output strings to tease out their meanings. This is what I’ve learned so far, mostly thanks to the Bing Chatbot in Windows 11 Canary (Build 25393):

The string “gYw” that appears in the columns of rows 2-10) stands for gray, yellow and white. It uses prevailing foreground color, whatever that may be.
The values 30m through 37m that appear as row heads (first column left) are ANSI escape codes for foreground colors
The values 40m through 47m that appear as column heads (second column through 9th column left) are ANSI escape codes for background colors.
Looking at the color chart, the text strings “gYw” show the foreground color, while the solid bar for each column shows the background color.

In profound contrast, Ubuntu puts foreground colors as columns, and background colors as rows. I also shows escape sequences instead of color names. Initially, this bamboozled me. But now I see what’s going on…

Notice that background appears as double rows with escape codes at left in column 1, and foreground colors appear as the text for escape codes in rows 2-9).

Wow, it’s all starting to make a certain amount of sense. And I mostly have the Bing Chatbot to thank for explaining such extremely low-level details. Apparently, those who work with terminal/console color charts know all this stuff already.

Now, I finally understand that a color scheme assigns a range of color values to the 8 ANSI escape codes for the foreground colors 30m through 37m (which may also be expressed as ESC[30m …). It does the same for the 8 ANSI escape codes for the background colors, too (40m through 47m, likewise ESC[30m).

OK, Now I Know What’s What

Suddenly, I feel armed with the information I need to make sense of the Windows Terminal color schemes and their related color charts. This should make my jobs of explaining them, and their customization, a WHOLE LOT easier. I’m jazzed…

Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Testing Bing Chat AI Text Generation

July 3, 2023 Ed Tittel 1 Comment

Hmmm. This has been interesting… I’ve been using the Bing Chat tool in the Canary Channel version of Windows 11 lately. I just asked it to shed some light on a Windows Console (aka Windows Terminal) tool that I’ve been working with lately. Let me provide the query I used while testing Bing Chat AI text generation:

“Give me 400 words about the Winodws Console colortool”

I’ll provide the results as a blockquote under the next heading. Then I’ll explain what’s good about it and where — IMO at least — it falls a little short.

Results from Testing Bing Chat AI Text Generation

Notice that the chatbot correctly interprets my mistyping of Windows as “Winodws” in the input, and gives me the answer I wanted. Good stuff! Here’s what it told me:

The Windows Console Colortool is a utility that helps set the color palette of the Windows Console. It can be used to apply the new default color scheme and several alternate pre-defined color schemes or even schemes of your own ¹. The tool is open source and hosted on GitHub ².

To use the Colortool, open up Command prompt and run: colortool [scheme name in schemes/ e.g: campbell]. Right-click on the window title to access the ‘Properties’ dialogue box. Once the properties dialogue box opens press OK (which saves the color change)¹.

Notice it provides highlighted, hyperlinked text to additional references (which show up in the lead-in graphic as footnotes 1 and 2). It’s essentially a rewrite of descriptive information from the colortool’s github page. Curiously, that does not show up as the primary reference here (it’s number 2, though). Concerns about the accuracy of the material I’ve seen voiced in other analyses are apparently NOT an issue when you ask the chatbot to keep the text short. Everything it says it 100% accurate and verifiable.

OK Then, What’s Missing?

The text does not explain that the ZIP file for the colortool must be downloaded and unpacked into a folder that’s either included in the $PATH environment variable, or made the focus of the Command Prompt (or PowerShell) session in which the tool gets invoked. It just assumes all those details have been handled and jumps straight into the syntax and behavior of the tool itself.

That’s all well and good, but makes a telling demonstration of why AI chatbots can help, but not necessarily take over, for knowledgeable human actors with a more nuanced understanding of the context in which they’re operating. At least not yet, anyway…

It’s extremely interesting stuff, and is definitely going to help me with my job of explaining things to readers in the future. If you’re running the Canary Build (25393) for Windows 11, click the Bing symbol at the upper right of the default Edge window to dig in and try it for yourself. Great fun!

Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog

WinGet Chrome Update Follies Continue

June 27, 2023 Ed Tittel Leave a comment

There are many occasions when I run WinGet and it tells me Chrome needs an update. Sometimes, WinGet handles that update; other times it does not. I just pushed my luck, and got more information about why that happens. It’s shown in the lead-in graphic, and indicates a change in the “install technology” is involved. In such a start-stop fashion, my WinGet Chrome update follies continue…

Yes/No: WinGet Chrome Update Follies Continue

WinGet is inherently conservative by design. If the developers change something about the installer WinGet calls to handle updates, it won’t force that update. As you can see in the lead-in graphic, when I explicitly tell WinGet to update Chrome (e.g. winget upgrade google.chrome references the package name) it gives me an informative error message instead:

A newer version was found, but the install technology is different from the current version installed. Please uninstall the package and install the newer version.

OTOH, if I fire up Chrome, then click on Help → About, it’s happy to update itself at my behest. See?

The internal update facility in Chrome doesn’t care about “install technology.” It just runs.

The advice in the WinGet message thus really targets using WinGet to perform the upgrade. Indeed if you run this sequence of commands:

WinGet uninstall Google.Chrome

WinGet install Google.Chrome

then Winget will achieve the desired result of updating Chrome. In the past, I’ve speculated that if Chrome is running, the update might not happen. Now that I see this error message, this looks like a much more likely explanation.

But wait…!

I tried this on another test PC just now, and on that machine the Chrome update proceeded without any issue. Go figure!

Maybe it is a case of whether or not a Chrome process is running. On the other test PC it had just been rebooted, so no such potential complications were present. It’s always something, right?

Insider stuff, PowerShell, Recent Activity, Security, WED Blog

MS Defender Update Targets Deployment Images

June 7, 2023 Ed Tittel Leave a comment

If you can trust the header data in this MS Support note (I do) it was updated on June 5, 2023. The item is entitled “Windows Defender update for Windows Operating system installation. It describes how to imbue offline Windows images with the latest and greatest Defender capabilities. In fact, that article includes a warning not to apply them to live images. Thus, it’s clear that this MS Defender update targets deployment images.

I got my date information about the article from its HTML meta-data:

<meta name="lastPublishedDate" content="2023-06-05">
<meta name="firstPublishedDate" content="2020-12-04">

How MS Defender Update Targets Deployment Images

Pre-requisites to run the updates — for WIM and VHD files — include:

Works on OS install images for 64-bit Windows 10 and 11, and Windows Server 2016 and 2019
OS environment must include PowerShell version 5.1 or newer (current production version is 7.3.4 as I write this)
Microsoft.Powershell.Security and DISM modules installed
The PowerShell session for the script <code>DefenderUpdateWinImage.ps1</code> runs with admin privileges. (“Run as administrator” or equivalent.)

The script provides switches to apply, remove or roll back, and list details for the installed update. Useful for those who maintain Windows images and want their security levels up to current snuff.

Find all the details in the MS Support article previously named. Do this before your next scheduled update window, for sure. Of course, this means you’re using Windows Defender as part of your security infrastructure.

MS Is BIG in Security

I just worked on a promotional piece for a joint Rubrik and MIcrosoft security webinar (YouTube video). Amazingly, MS describes itself as “the biggest cyber security company in the world” and did over US$20B in such business in 2022. I guess they do have some legs to stand on in this arena. And indeed, they’re doing all kinds of fascinating stuff with AI and ML to improve their security posture and incident response capabilities. Great stuff!

Cool Tools, PowerShell, Recent Activity, WED Blog

Deciphering PowerShell History Commands

May 22, 2023 Ed Tittel Leave a comment

Whoa! I just spent an enjoyable half-hour learning about the various PowerShell command line history viewing and editing tools. This comes courtesy of OhMyPosh creator Jan De Dobbeleer (@jandedobbeleer) on Twitter. Deciphering PowerShell history commands, in my case, involved a fair amount of interesting play and learning in a Terminal session. As you can see from the lead-in graphic, I had fun manipulating my command history (and then, updated OhMyPosh to catch up my test system).

When Deciphering PowerShell History Commands, Do This…

The operative way to understand PS history management is as a series of prefixes to “-history” at the command line — namely:

get: shows current PS command line history as stored for display
clear: clears current PS command line history
add: allows you to import a predefined command history from a file

There’s a lot more to managing history than you might think, as described in this MS Learn reference on the Clear-History command. Indeed you can tailor the history based on commands by number (from top or bottom of the history list, using -Count and other options) or by content (using the -CommandLine option and string-matching facilities).

Wait! There’s an Add-History, Too

You can save a representative command history by piping get-history into a CSV file. Later on, Add-History lets you import that file’s contents to imbue the current command history into your current PowerShell context. See this reference for more info.

Working with PowerShell history commands is great fun, actually. I’d suggest visiting the afore-linked references to take things for a spin. I find it useful to clear the history after such learning adventures (or after making mistakes at the command line that I’d just as soon forget…).

Cool Tools, Insider stuff, PowerShell, WED Blog, Windows 10, Windows 11

Another Interesting PowerShell Clean-up

April 28, 2023 Ed Tittel Leave a comment

Wow! What a ride… I was working on my Lenovo P16 Mobile Workstation this morning. Winget kept finding two versions of PowerShell — namely 7.3.8.0 and 7.3.4.0 — when I ran an open-ended upgrade command. That said, I couldn’t find the older version anywhere. Ultimately, this would lead me to another interesting PowerShell cleanup. Let me walk you through what I had to do to come clean, as ’twere…

Starting Another Interesting PowerShell Clean-up

I’ll begin by explaining where I started from. I was running the Preview version of PowerShell. The complete name string (FQDN equivalent): Microsoft.Powershell.Preview. The list command for that string was showing two versions in winget output, as described above. Upgrade attempts had no effect on the older version, despite reporting success. Sigh…

Also, when I searched all the folders where the software should be lurking (from the PowerShell environment variable), I found it nowhere. Likewise, my usual fallback trick — searching for filename pwsh.exe (the PowerShell executable) — showed only one instance.

Frustrating!

Ending the Clean-up Conclusively

When all else fails, remove/replace still does the trick. I ran the following commands to fix things so that only one version shows as in the lead-in graphic for this story:

1. winget uninstall -q Microsoft.PowerShell.Preview -v 7.3.8.0
2. winget uninstall -q Microsoft.PowerShell.Preview -v 7.4.0.3
2. winget install –id Microsoft.Powershell –source winget

That replaced the Preview with the Production version, and did away with the elusive (unfindable, even) older Preview version. Problem solved. Sheesh!

Note: Here’s a handy article from MS Learn “Installing PowerShell on Windows” that supplied me with number 3 above. Works well, but I did have to close my open PowerShell window for the install process to complete. Can’t have the old stepping on the new again, can we? Sigh again…

PowerShell, Recent Activity, Troubleshooting, Uncategorized, WED Blog, Windows 10, Windows 11

Windows 10 Dual Progress Bars Mystery

April 20, 2023 Ed Tittel Leave a comment

Back in November 2017, I posted the item shown in the lead-in graphic to Windows TenForums.com. I get two progress bars when running DISM ... /StartComponentCleanup on my Windows 10 PCs. The thread is interesting to read, and offers a good explanation in item#4 for what’s happening: a spurious line feed somewhere in the DISM routines that handle this task. Just this morning, I noticed that this Windows 10 dual progress bars mystery persists to this day. But I’ve figured out more…

More Data for Windows 10 Dual Progress Bars Mystery

This doesn’t happen every time I run DISM ... /StartComponentCleanup on my Windows 10 PCs. It happens only if I’ve just applied a Cumulative Update to that machine, and I haven’t rebooted the machine a second time after the post-update reboot. And, in fact, I just replicated this very same issue on one of my Windows 11 22H2 PCs as well in those same circumstances.

I’m still wondering about why this happens. I take it as ongoing proof that problems do make themselves visible in Windows (10 and 11) occasionally. Ditto for the observation that some glitches are more important than others.

This particular glitch, while interesting, is benign. It’s just a hiccup in the DISM output. Everything works as it’s supposed to, except for the dual progress bars (or appearance thereof if my TenForums informant is correct about the “spurious linefeed” theory). But here is the error in Windows 11 as well. Note: the build number shown, 22621, identifies this OS as Windows 11 22H2 even though the “Major” OS version reads “10.”

I love a good mystery. I hope someday to see this fixed, though…