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.

Change Dev Channel Task Manager Default View

Here’s a nice little addition that’s popped up in the Dev Channel version of Task Manager. If you visit its Settings page, you will see a “Default Start Page” pull-down menu there. This makes it easy to change Dev Channel Task Manager default view. My preference is Details, as shown here:

Change Dev Channel Task Manager Default View.details

Because it’s my go-to view, I set “Details” as the default in Task Manager.

Why Change Dev Channel Task Manager Default View?

For convenience, mostly. It’s not a huge deal in terms of added functionality. But anything that saves a mouse click is helpful, when it comes to getting down to work, eh? In general, MS seems to be moving to a move open, less cluttered layout for Task Manager in the Dev Channel version. It takes a little getting used to, but I like it.

My eyeballs are still better trained to make sense of the old-fashioned Task Manager that’s still visible in Windows 10 and other Windows 11 versions (for me that mostly means production version, Build 22000.778). The contrasting yellow shades for data cells are still more recognizable to me.

But, as with all things Windows, changes spur us on to learn and appreciate new things. That’s how I’m going to play the evolution of Task Manager. We’ll probably have side-by-side versions for Windows 10 and 11 for some time anyway, what with Windows 10 EOL not until October 2025.

But Wait, There’s More…

Turns out you can change the default tab for older Task Manager versions, too. The menu fiddling is a bit different though, as shown in the next screencap:

A different sequence of menu picks changes the default view in old Task Manager iterations.

As you can see in the preceding screenshot, click Options → Set default tab → and then any of the items shown (Processes, Performance, App history, Startup, Users, Details, Services) to make your selection. Good stuff!

[Note] Here’s a shout-out to Mauro Huculak at Windows Central, whose July 8 story clued me into this new wrinkle on an old favorite Windows tool. Thanks, Mauro!

Facebooklinkedin
Facebooklinkedin

More WingetUI Interactions

OK, then. I’m using WingetUI as an element of my Windows PC update toolbox. Along the way, I’m finding some areas where it shines, and others where it doesn’t. But as I gain familiarity with this tool, more WingetUI interactions convince me it’s worth using. That said, it’s no silver bullet for Windows updates, either. Let me explain…

After More WingetUI Interactions, Another Status Report

If you look at the lead-in graphic, I can point to elements where WingetUI shines, and those where it doesn’t. It handles most third-party apps perfectly (e.g. 7-Zip, Kindle, SUMo, Python 2, and Spacedesk). Not so for MS components, except for C++ runtime elements. It failed (or I didn’t try based on prior failures) with Edge WebView2, Teams, and the WADK. This is not a huge problem for me.

SUMo also catches the follow items that did not show up on the WingetUI radar: Chrome, Firefox, CrystalDiskInfo, Intel PROSet utility, MyLANViewer, Nitro Pro, Notepad++ (a false positive, IMHO), Snagit and Winaero Tweaker. Thus I must continue to use a collection of tools to get through my entire update roster. But I knew that already.

All’s Well That Ends Well

I was able to use PatchMyPC to handle the routine updates that WingetUI didn’t see. SUMo led me to fix everything except Intel PROSet, Nitro Pro, and Snagit. I got the first and last myself, and skipped Nitro Pro for the moment (though I did find install syntax for the latest version using winget itself, which I’ll try again later…).

[Note added 1 Day later…] Eventually, I jumped to the Nitro Pro download page (Product Updates) to grab and install the latest version (13.67.0.45). That got me completely caught up. What I now can’t understand is why winget will sometimes update Nitro Pro for me, but why I must do it manually at other times. I’m guessing it depends on package prep and info…

 

Facebooklinkedin
Facebooklinkedin

NetBScanner Blind Spot

I’ve been trying to understand what’s going on with local machine name handling on my LAN this week. Along the way, I’ve found a NetBScanner blind spot in that otherwise excellent NirSoft tool. Here’s the thing: as you can see in the lead-in graphic, NetBScanner does not include the name/address info for the scanning PC in its results. Those appear in the nslookup results in the cmd prompt window below.

What NetBScanner Blind Spot Means

I was quickly able to find another Nirsoft tool that does a complete scan, including the scanning PC — namely FastResolver. But alas, some tinkering with that tool is required to make it show only occupied IP addresses in a target range. That’s shown in the next screencap, which includes the scanning machine in its results:

NetBScanner Blind Spot.FR

Note that the i7Skylake item, IP 192.168.1.63, appears in the list along with all other items that NetBScanner shows above.

One of the most interesting things about using tools properly requires understanding their limitations. I just learned an important limitation for NetBScanner (ditto for FastResolver) in figuring this out.

Other Lessons Learned

I’ve now observed also that it takes the Spectrum router 24 hours to update its LAN entries in its DNS database. That’s entirely consistent with the default timeout of 24 hours for “positive DNS cache” entries. So now I understand that when a machine name won’t resolve to the correct IP address, it’s because DHCP has leased a different IP address to that host sometime in the past day. If I give it time, it will catch up. Good to know!

Facebooklinkedin
Facebooklinkedin

Phone Only App Manages Spectrum Networks

Man! I am NOT a happy camper right now. I just figured out that my DHCP leases have changed, but DNS isn’t tracking same. Thus, my “fixed” correlation between machine name X12Hybrid and 192.168.1.20 is no longer valid. The last digits of the IPv4 have changed. But NSlookup still sees the aforementioned address. And in attempting to troubleshoot the issue, I’ve just learned I can’t login to my router from a PC on my LAN. Because a phone only app manages spectrum networks, I must go through my iPhone.

Why Phone Only App Manages Spectrum Networks Is a Drag

I’m used to getting up close and personal with the Spectrum router through a web-based login. I know that interface, and can use it well. Now I not only have to learn a new interface instead, I must also:

  • run it through a smartphone with a ~3″x6″ display
  • try to figure out how (or perhaps even if) what I already know how to do inside one utility still works in another

It’s frustrating to be FORCED to use a cellphone when I have large screens at my disposal. I’ve shared my sentiments with the Spectrum tech support crew — a nice and genuinely helpful bunch of folks — but it seems to make little difference.

That’s progress, I guess. I can’t say I see this as a step forward. I can approve of using the phone app as an alternative to the old way. I can’t approve of using it as an out-and-out replacement. Sigh.

Facebooklinkedin
Facebooklinkedin

Use NSlookup for Machine Name Checks

Certain recent Dev Channel builds have played intermittent hob with RDP. Thus, for example, I had to switch from using the machine name to its IP address to RDP into one particular PC. In troubleshooting that issue, I quickly realize it makes sense to use NSlookup for machine name checks. Indeed as you can see in the lead-in graphic, when NSlookup resolves that name correctly, RDP will also accept that name to establish a connection.

Why Use NSlookup for Machine Name Checks?

Because it will tell you if RDP can recognize the machine name. Under the hood, both RDP and NSlookup rely on access to local DNS records to resolve the name into an IP address (see lead-in graphic). When the command line works, RDP should also be able to rely on the same underlying service — namely, DNS — to do its thing as well.

Of course, this raises the question as to why my local DNS server — which runs on the boundary device from Spectrum that sits between my LAN and the cable Internet connection — sometimes fails to resolve valid machine names. Feature upgrades can cancel existing IP address leases, and require the DNS cache to be rebuilt. And apparently, recent lightning storms can also mess with that device’s DNS cache when the power fails. So, I’m learning to flush and rebuild that cache as part of local device hygiene.

At least I now know what’s going on and why I must sometimes switch from machine names to IP addresses to access certain devices. Good thing it’s easy to log into and handle the reset over the LAN. It’s always something, right?

Facebooklinkedin
Facebooklinkedin

Tracking Windows Releases Gets Challenging

I have to laugh. I found myself re-reading numerous recent Windows 10 and 11 news stories, trying to figure which OS is which. It doesn’t help, either, that sometimes the news outlets themselves get their wires crossed. I believe that tracking Windows releases gets challenging because we’ve got so many of them to consider. Let me explain…

Why Say: Tracking Windows Releases Gets Challenging?

Windows 10 has two release tracks right now — namely, Release Preview and Production (current release). Windows 11, OTOH, has four: (1) Production; (2) Release Preview; (3) Beta and (4) Dev channels. Each of these releases has its own Build numbers. In those numbers, feature upgrades change the front and major part, and cumulative updates (CUs) change the minor and rear part. Thus, for example 22000.778 describes Windows 11 Production right now. The 22000 part comes from the Windows 11 feature upgrade to 21H1. The 778 part comes in the wake of KB014668 (6/29/2022).

Not too challenging with 1 or 2 such items to keep track of. But with 2 tracks for Windows 10, and 4 tracks for Windows 11, it’s a bit trickier. MS offers web pages to track this kind of stuff, but I don’t always find them terribly informative. It’s probably my fault.

Check Out the Release Info at UUPdump.net

If you look at the intro graphic for this story, you’ll see it’s comprised of the “release buttons” at the head of the UUPdump.net web page. Click any button, and you’ll get a complete release history for the selected release track, in descending chronological order. The info is comprehensive and all-inclusive.

You have to learn how to read release names and numbers to recognize and distinguish cumulative from feature updates in this presentation, though. That’s because UUPdump builds update ISOs to clean-install Windows images that include slipstreamed CUs.

So, if a release name there says “Feature Update” that doesn’t mean it’s really a feature update. Instead, you must recognize that feature updates usually include a minor (right-hand) component labeled “1” or “1000” to the right of the period in the build number. Once you understand those are the only “real” Feature Updates, the update history there makes sense. Works for me, anyway.

So when I want to get straight info, UUPdump.net is where I head. You can do likewise, but also check the MS clearinghouse named Windows release health. It, too, offers good info about production releases and updates. For Insider Previews, the MS web pages named “The Changelog” and “Flight Hub” are equally helpful. Cheers!

Facebooklinkedin
Facebooklinkedin

Why USB Disk Speeds Matter

It’s been a busy and interesting week. I’ve been messing around with numerous backups and restores. Ditto for mounting ISOs and running Windows repair installs. A LOT of disk reads and writes to USB drives have been involved. Because of the huge amounts of data involved, I’m better prepared to explain why USB disk speeds matter. A LOT!

Why USB Disk Speeds Matter So Very Much

In a word, the shortest possible answer is “Time.” If you can get something done faster, you can do more in a single work interval. Compare the USB disk speeds for an NVMe drive in a USB-C enclosure (left) to those for an mSATA drive in a USB-A 3.1 enclosure (right — see lead-in graphic). When backups and restores are concerned the top lines (which involve large file transfers) actually matter. Of course, all the times matter as well.

But those differences are pretty stark for backup and restore. Let me explain… If you look at the top pairs of numbers, these cover large data transfers with a queue depth of 8 (upper) and 1 (lower). In both pairs of numbers, the NVMe drive is over twice as fast as the mSATA drive. Those same results were born out in backups and restores (7 and 14 minutes for backup; 11 and 23 minutes for restore).

The More You Do, the Better You’ll Like It!

Those results show why I’ve long been a believer in using fast USB drives whenever possible. I’m still waiting to see what kind of bump I can get with a Thunderbolt 4 NVMe enclosure, proper cables and enclosure, and Thunderbolt 4 on the host device. From what I read, it should be 25-40% as fast again.

This realization came to me when I started copying a backup from a BitLocker protected NVMe drive to an mSATA unprotected drive. I got a consistent 26-27 MBps transfer rate between the two devices. It took over 20 minutes to copy the file!

If I could’ve gone Thunderbolt 4 all the way, I could have quadrupled the transfer speed or better. That would cut my wait time from 20 minutes to 5. Waiting for necessary data can’t be completely bypassed — but it surely shows the “need for speed” on such occasions.

Facebooklinkedin
Facebooklinkedin

Wrong Backup Means Wrong Outcome

I have to laugh. I’ve been fighting weird behaviors on my X12 Hybrid Tablet all week long. Only yesterday afternoon did I finally snap to an obvious visual cue that told me what was wrong. Among lots of other interesting things, I learned that wrong backup means wrong outcome when restored. It’s a testament to Windows 11 and to Macrium Reflect, because the target PC actually ran — sort of — even with the wrong image running the works. Let me explain…

If Wrong Backup Means Wrong Outcome, How Wrong Is It?

Here’s what I did: I restored a backup from my Lenovo X380 Yoga to my Lenovo X12 Hyrbrid Tablet. Different CPU, different biometrics devices and capabilities, different Thunderbolt support, and so on. Now that I know what I did, I’m amazed the OS ran at all. And actually, except for refusing to recognize (or work with) hardware present on the X12, but absent on the X380, it worked pretty well.

So how did I finally figure out what I’d done to myself (or rather, to the X12)? The answer’s in the lead-in graphic for this story. I use 8Gadgetpack on all of my PCs. I also use its analog clock gadget, and use the machine name from the target host as the clock name. So there it was on my X12 desktop: X380 (as you can see). That’s what told me I’d restored the wrong backup to the target machine. I have a number of roving SSD devices in USB enclosures. Apparently the backup I chose had moved from a USB port on the X380 to the X12’s Thunderbolt dock.

After that Aha! moment, I quickly located a recent backup from the X12. I had to jump through some hoops because it lived on a BitLocker protected drive (hint: the Macrium Reflect Rescue Disk requires additional options to restore backups from a BitLocker protected volume). But once I restored the right image, all my problems went away. I was able to use a UUPdump image I’d already built to quickly update to the latest Dev Channel version, too.

Lessons Learned

1. I’m glad I use my machine name technique on the Gadget Clock because it’s a good way to see where a backup originated.

2. I’ve started adding the machine name into my Reflect backup image names, so I can tell backups apart quickly and easily.

3, I’ve learned how to deal with BitLocker drives as restore sources, and how to re-enable BitLocker on a recovered C: drive

4. I’ve learned to be more careful in choosing which image to restore to a target PC, when a restore is necessary

Now, all I can hope is that I don’t do this again. Sigh, and sigh again.

Facebooklinkedin
Facebooklinkedin

In-Place Repair Install Basics Revisited

OK, then. I’ve been messing about with one of my Dev Channel test PCs lately. And it’s for the usual reason: experimentation leads to self-inflicted damage. Right now, the X12 Hybrid is limping along. It’s having driver problems with Windows Hello and Thunderbolt. The standard response when things get weird gives cause for in-place repair install basics revisited. I’ve been reminded of some important elements worth sharing (and repeating).

Why Are In-Place Repair Install Basics Revisited?

Generally, an in-place repair install involves running the setup.exe from an ISO to replace the OS files in the running image with known, good working equivalents. All this is wonderfully described in Shawn Brink’s terrific ElevenForums tutorial Repair Install Windows 11 with an In-Place Upgrade.

I started my exercise by visiting the Windows Insiders Using ISOs page. But I noticed that ISO version is 21540, whereas I’m running 25145 on my test PC. Alas, that explains why, after mounting the incompatible ISO on said test PC, it offers only the “Keep nothing” option. That’s what’s shown in the lead-in graphic for this story. It was my profound clue that I needed a different ISO.

Of course, the “Nothing” option is exactly what I DON’T want. So I went to UUPdump.net instead, and grabbed the ISO for 21545. And sure enough, once mounted it provides access to the “Keep personal files and apps” option I really want.

The Requirements Tell the Story

If you look at the “Repair install requirements” at the tip-top of the afore-linked tutorial, item 2 therein reads:

  • The Windows 11 installation media (ISO or USB) must be the same edition, same version, and same or higher build as the currently installed Windows 11.

That’s what was holding me back. And that’s why I needed to remind myself of the basics, so I could get the repairs I wanted. Indeed: back to basics turns out to point me where I needed to go.

 

 

Facebooklinkedin
Facebooklinkedin

Overcoming RDP Access Hurdles

Here at Chez Tittel, I’ve got 9 PCs in my office. 2 Desktops and 7 laptops, to be more specific. I like to access most of them from my primary desktop. That’s because it sports a couple of aging but still decent Dell 2717 Ultrasharp monitors. Over the years, I’ve encountered interesting issues in making RDP (remote desktop protocol) connections to my “Other PCs.” For me, overcoming RDP access hurdles usually involves one or more of three workarounds.

Three Workarounds to Overcome RDP Access Hurdles

These workarounds help to address a list of problems that include:

  • Can’t find remote PC
  • Can’t authenticate login credentials
  • Password error despite known, good working account/pwd pair

Workaround #1: Try the device IPv4 address

When the Remote Desktop Connection (or Remote Desktop app) simply can’t find a machine name, it’s always a good idea to try the target PC’s IPv4 address instead. As shown in the lead-in graphic for this story, it worked to get me into a Lenovo X380 Yoga I just put through a bunch of Windows 11 upgrades.

Workaround #2: Try a Different MSA

On occasion, when I try to login to a remote PC using my current Microsoft Account (MSA) it just won’t get past authentication. This is often a symptom of difficulty in getting MS authentication to work properly. When that happens, I will try another one of my known, good working MSAs (I have three, as I write this story). That does occasionally work, especially if I’ve already used that MSA on the target machine already. Go figure!

Workaround #3: Try a Local Account Instead of MSA

Sometimes, RDP will strenuously resist allowing you to establish an RDP connection over the LAN using a Microsoft Account (via its associated email address). In fact, it generates an account name/password error, even though I’m using a known, good working MSA account name and its associated password to try to login.

When that happens I’ve found that setting up a local admin account — one named, LocalU, for example — will get me right into the target PC. That’s also on display in the lead-in graphic where I had to use both workarounds at once to get into that PC. Sigh.

Remember: Where There’s a Will, There’s a Way

If you need to establish an RDP session on a remote PC, you can usually figure out a way to make such a connection work. If the preceding workarounds don’t do the trick, try the other tips in this 2021 WindowsReport story: it offers pretty good tips, tricks and advice.

 

Facebooklinkedin
Facebooklinkedin