Microsoft has released security updates for CVE-2026-62698, Microsoft Digest Authentication Elevation of Privilege Vulnerability, an Important-rated flaw affecting a broad range of supported Windows client and server releases.
The issue is a numeric truncation error in Microsoft Digest Authentication. Microsoft states: “Microsoft Digest Authentication Elevation of Privilege Vulnerability: Numeric truncation error in Microsoft Digest Authentication allows an authorized attacker to elevate privileges locally.”
An attacker who successfully exploits the vulnerability could gain SYSTEM privileges, according to Microsoft’s advisory. That makes this a meaningful patching priority: SYSTEM is Windows’ highest local privilege level, the keys-to-the-kingdom account rather than merely another seat in the castle.

Vulnerability details​

• CVE: CVE-2026-62698
• Title: Microsoft Digest Authentication Elevation of Privilege Vulnerability
• Severity: Important
• CVSS base score: 7.8
• CVSS temporal score: 6.8
• CVSS vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
• CWE: CWE-197
• Description: Numeric truncation error in Microsoft Digest Authentication allows an authorized attacker to elevate privileges locally.

Publicly disclosed: No
Exploited: No
Customer action required: Yes
Microsoft’s exploitation assessment is Exploitation More Likely.
The CVSS vector describes a locally exploitable issue with low attack complexity, where the attacker must already hold low-level privileges. No user interaction is required. A successful attack can affect confidentiality, integrity, and availability at a high level. In practical terms, this is not a remote unauthenticated break-in, but it can turn an existing foothold on a machine into complete local control.

Why this patch matters​

Elevation-of-privilege vulnerabilities are often most dangerous as part of a chain. An attacker may first obtain a limited account or limited code execution through another route, then use a local privilege escalation bug to reach SYSTEM. At that point, ordinary Windows permission boundaries provide very little resistance.
Microsoft’s advisory explicitly addresses the potential outcome:

“What privileges could be gained by an attacker who successfully exploited this vulnerability? An attacker who successfully exploited this vulnerability could gain SYSTEM privileges.”

Click to expand...

That risk applies to both workstation and server estates, including Server Core installations. Server administrators should not mistake a minimal GUI footprint for immunity; if an affected component is present and unpatched, the operating system version still requires the relevant update.

Affected Windows versions and fixed builds​

The following Microsoft updates remediate CVE-2026-62698. Administrators should deploy the applicable cumulative update for each operating system and architecture in their environment, then confirm the corresponding build number.

Windows 10​

• Windows 10 Version 1607 for 32-bit Systems (x86): For Windows 10 Version 1607 for 32-bit Systems (x86), install KB5120418 to reach fixed build 10.0.14393.9418.
• Windows 10 Version 1607 for x64-based Systems: For Windows 10 Version 1607 for x64-based Systems, install KB5120418 to reach fixed build 10.0.14393.9418.
• Windows 10 Version 1809 for 32-bit Systems (x86): For Windows 10 Version 1809 for 32-bit Systems (x86), install KB5120238 to reach fixed build 10.0.17763.9121.
• Windows 10 Version 1809 for x64-based Systems: For Windows 10 Version 1809 for x64-based Systems, install KB5120238 to reach fixed build 10.0.17763.9121.
• Windows 10 Version 21H2 for 32-bit Systems (x86): For Windows 10 Version 21H2 for 32-bit Systems (x86), install KB5120249 to reach fixed build 10.0.19044.7663.
• Windows 10 Version 21H2 for ARM64-based Systems: For Windows 10 Version 21H2 for ARM64-based Systems, install KB5120249 to reach fixed build 10.0.19044.7663.
• Windows 10 Version 21H2 for x64-based Systems: For Windows 10 Version 21H2 for x64-based Systems, install KB5120249 to reach fixed build 10.0.19044.7663.
• Windows 10 Version 22H2 for 32-bit Systems (x86): For Windows 10 Version 22H2 for 32-bit Systems (x86), install KB5120249 to reach fixed build 10.0.19045.7663.
• Windows 10 Version 22H2 for ARM64-based Systems: For Windows 10 Version 22H2 for ARM64-based Systems, install KB5120249 to reach fixed build 10.0.19045.7663.
• Windows 10 Version 22H2 for x64-based Systems: For Windows 10 Version 22H2 for x64-based Systems, install KB5120249 to reach fixed build 10.0.19045.7663.

Windows 11​

• Windows 11 Version 23H2 for ARM64-based Systems: For Windows 11 Version 23H2 for ARM64-based Systems, install KB5120240 to reach fixed build 10.0.22631.7517.
• Windows 11 Version 23H2 for x64-based Systems: For Windows 11 Version 23H2 for x64-based Systems, install KB5120240 to reach fixed build 10.0.22631.7517.
• Windows 11 Version 24H2 for ARM64-based Systems: For Windows 11 Version 24H2 for ARM64-based Systems, install KB5120994 to reach fixed build 10.0.26100.9106; install KB5121003 to reach fixed build 10.0.26100.9168.
• Windows 11 Version 24H2 for x64-based Systems: For Windows 11 Version 24H2 for x64-based Systems, install KB5120994 to reach fixed build 10.0.26100.9106; install KB5121003 to reach fixed build 10.0.26100.9168.
• Windows 11 Version 25H2 for ARM64-based Systems: For Windows 11 Version 25H2 for ARM64-based Systems, install KB5120994 to reach fixed build 10.0.26200.9106; install KB5121003 to reach fixed build 10.0.26200.9168.
• Windows 11 Version 25H2 for x64-based Systems: For Windows 11 Version 25H2 for x64-based Systems, install KB5120994 to reach fixed build 10.0.26200.9106; install KB5121003 to reach fixed build 10.0.26200.9168.
• Windows 11 Version 26H1 for ARM64-based Systems: For Windows 11 Version 26H1 for ARM64-based Systems, install KB5121000 to reach fixed build 10.0.28000.2704.
• Windows 11 version 26H1 for x64-based Systems: For Windows 11 version 26H1 for x64-based Systems, install KB5121000 to reach fixed build 10.0.28000.2704.

Windows Server​

• Windows Server 2012 (Server Core installation) (x64): For Windows Server 2012 (Server Core installation) (x64), install KB5120386 to reach fixed build 6.2.9200.26280.
• Windows Server 2012 (x64): For Windows Server 2012 (x64), install KB5120386 to reach fixed build 6.2.9200.26280.
• Windows Server 2012 R2 (Server Core installation) (x64): For Windows Server 2012 R2 (Server Core installation) (x64), install KB5120385 to reach fixed build 6.3.9600.23338.
• Windows Server 2012 R2 (x64): For Windows Server 2012 R2 (x64), install KB5120385 to reach fixed build 6.3.9600.23338.
• Windows Server 2016 (Server Core installation) (x64): For Windows Server 2016 (Server Core installation) (x64), install KB5120418 to reach fixed build 10.0.14393.9418.
• Windows Server 2016 (x64): For Windows Server 2016 (x64), install KB5120418 to reach fixed build 10.0.14393.9418.
• Windows Server 2019 (Server Core installation) (x64): For Windows Server 2019 (Server Core installation) (x64), install KB5120238 to reach fixed build 10.0.17763.9121.
• Windows Server 2019 (x64): For Windows Server 2019 (x64), install KB5120238 to reach fixed build 10.0.17763.9121.
• Windows Server 2022 (Server Core installation) (x64): For Windows Server 2022 (Server Core installation) (x64), install KB5120229 to reach fixed build 10.0.20348.5440; install KB5120242 to reach fixed build 10.0.20348.5499.
• Windows Server 2022 (x64): For Windows Server 2022 (x64), install KB5120229 to reach fixed build 10.0.20348.5440; install KB5120242 to reach fixed build 10.0.20348.5499.
• Windows Server 2025 (Server Core installation) (x64): For Windows Server 2025 (Server Core installation) (x64), install KB5120228 to reach fixed build 10.0.26100.33222; install KB5120233 to reach fixed build 10.0.26100.33296.
• Windows Server 2025 (x64): For Windows Server 2025 (x64), install KB5120228 to reach fixed build 10.0.26100.33222; install KB5120233 to reach fixed build 10.0.26100.33296.

Administrator checklist​

1. Inventory Windows versions and architectures. Separate x86, x64, and ARM64 endpoints; the target build is architecture- and release-specific.
2. Deploy the applicable cumulative update. Use the KB listed for the installed Windows release.
3. Restart where required. Cumulative Windows security updates commonly require a restart before the revised system components are active.
4. Validate the installed build. Check winver on client systems or use enterprise inventory tooling to compare the device’s build against the fixed build listed above.
5. Include server and Server Core systems. Windows Server 2012 through Windows Server 2025 are covered by this advisory, including the specified Server Core installations.
6. Prioritize systems where local access is realistic. Since the attack is local and requires authorization, systems shared by multiple users or exposed to post-compromise activity warrant particular attention.

The central lesson from CVE-2026-62698 is refreshingly unglamorous but important: a local account should not be able to become SYSTEM through a flaw in authentication handling. Apply the relevant Windows security update, verify the resulting build, and close off an escalation route before it becomes the second act in someone else’s intrusion story.

Valve has added a framerate distribution chart to the Steamworks partner dashboard. It shows developers how their games perform on Steam Deck, but only if the game is Steam Deck Verified.
Valve's Steamworks announcement is dated October 1 and says the partner dashboard now carries more information on how games perform on Steam Deck. The data is currently limited to Steam Deck Verified titles. Developers reach it from the partner landing page under Technical Tools > Steam Hardware Compatibility Review. The tool is aimed at developers, not at Deck owners. It matters to anyone who builds or buys PC games that run on Linux-based handheld hardware through the Proton compatibility layer.

What the new chart shows​

The earlier tools reported a single number. The April beta showed a trailing 30-day daily average, based on opted-in users who had logged playtime in the game. The new view is a distribution. It shows how much sampled gameplay falls into different FPS ranges. Valve says this gives a clearer picture than an average alone, especially when problems affect only part of a game or only some players.
Here is an example. A game averaging 45 FPS could be steady at 45. It could also be a mix of 60 FPS sessions and long stretches in the 20s. The average hides that difference, and the distribution shows it.
Valve says the chart should be read alongside the average framerate and customer feedback charts. It believes the three together give a clearer overall picture of what customers experience on Deck.

Where the data comes from​

Valve says the data comes from Steam Deck players who opted in to anonymized framerate data. It also says a majority of Deck players have opted in, across a wide range of games and play styles.
Valve gives no percentage, device count or session count. MIXED Reality News also reports that Valve does not say whether the opt-in is on by default. HotHardware says players opt in within SteamOS. Treat "a majority" as Valve's own unquantified claim. Developers also can't tell how well a given title's sample represents its audience.

Valve's four caveats​

Valve lists several reasons a low bar in the chart may not mean poor performance:

• Hardware ceilings. The Deck LCD tops out at 60 FPS and the OLED at 90 FPS.
• Player frame caps. Customers can change their frame limit. A game that holds 90 FPS on an OLED will still log lower-FPS sessions if some players cap it to save battery.
• Docked displays. Some players may be docked to an external display with a higher refresh rate than the Deck's own screen.
• Loading screens. MIXED reports that Valve also says the data includes all sampled time, including loading screens where framerate may drop sharply.

The practical reading is that a chart showing a big slice of time under 30 FPS is a prompt to investigate, not a verdict. Valve's own suggestion points the same way. If a significant amount of data lands in segments below 30 and players also report performance and stability problems, that could be a good signal to look into optimization or changing the default graphics configuration on Deck. The chart is most useful when low framerates coincide with complaints.

The Verified-only boundary​

The gate is where this story gets awkward. Valve's compatibility checklist makes performance part of Verified status. The default configuration must reach 30fps at 800p on Deck and 30fps at 1080p on Steam Machine. Valve's compatibility documentation adds that most failures in the checklist leave a game with the Playable badge.
The consequence is that some games are shut out of the chart. A title whose default settings miss the 30 FPS bar is more likely to lose Verified status. It then loses access to the tool that would show how far it falls short. Two points temper that reading:

• Verified is broader than framerate. The checklist also covers controller support and glyphs, text entry, launchers, device warnings, Proton support, resolution and text legibility. A Playable game may have failed on any of those. Playable does not automatically mean slow.
• The blind spot isn't proven to be total. Nothing in Valve's announcement says the games that most need optimization are all excluded. The gap is real, but its size is unknown.

Valve's own wording is "currently", so the restriction isn't described as permanent. It has also said before that it wants to broaden the data. In April it said it planned to add variance data and to bring the same view to Steam Deck Playable titles in a future update. That is Valve's earlier stated plan, not a commitment made in this announcement.

Why start with Steam Deck​

Valve defends the narrow scope in the announcement itself. As MIXED quotes it, Valve says it is starting with Steam Deck because every device has the same hardware configuration, which makes the data easier to understand. A fixed hardware target removes a large source of noise. A PC-wide version would have to untangle thousands of GPU, CPU and driver combinations.
HotHardware says the data could later extend to Steam Machine and Steam Frame. That is HotHardware's reading. MIXED reports that Valve promises no date and no equivalent for Steam Machine or general PC hardware. Treat expansion as possible, not scheduled.

What this means​

For developers of Verified games:

• Check the distribution, not just the average.
• Set the chart against player feedback before changing defaults.
• Allow for the 60/90 FPS ceilings and user-set caps.

For developers of Playable games:

• You still can't see this chart.
• Your own telemetry and QA remain the main option. Fixing the issues that cost Verified status could also unlock the data.

For players:

• Nothing changes on screen. MIXED reports the chart is developer-facing only, so players can't see what their own sessions contribute.
• Valve says compatibility ratings affect how a game is presented. They don't affect whether you can buy or launch it on a Deck.

The feedback loop is a good one: players share anonymous data and developers get a more honest view of performance. It is still a loop that only runs for games that already cleared the performance bar.

RPCS3, the open-source PlayStation 3 emulator that runs on Windows, macOS, Linux and FreeBSD, has hit a stability milestone. The project's official account announced on October 4 that all six PS3 Ratchet & Clank games can now be played on PC without crashes. The announcement lists Tools of Destruction (2007), Quest for Booty (2008), A Crack in Time (2009), All 4 One (2011), QForce (2012) and Into the Nexus (2013). It credits lead developer elad335 with improving "RSX FIFO GET accuracy."
"Crash-free" is not "playable," and the gap between the two matters for anyone planning a weekend of PS3 emulation on a Windows box.

What actually changed​

The fix is in RPCS3's emulation of the RSX, the PS3's graphics processor. FIFO means first-in, first-out. The RSX consumes a queue of graphics commands, and the "GET" pointer tracks how far the processor has read into that queue. If the emulator's GET value is wrong at the wrong moment, the command stream can desynchronize. That is general background, not a detail from the announcement.
RPCS3's history with this subsystem helps explain why such a fix is plausible. An older elad335 pull request on GitHub added a log prefix showing the current FIFO GET register. It also fixed FIFO stack recovery, and it targeted games that hit "RSX: FIFO error: possible desync event" errors. A separate 2022 change made RPCS3 suggest raising the RSX FIFO Accuracy setting after a crash. FIFO behavior has been a recurring source of stability problems in the project.
Two limits on the evidence:

• The announcement gives no commit, build number or benchmark data.
• One outlet, GameGPU, described a related stability update in broader terms and said a new build is on the project's site. That is secondary reporting, and I could not tie it to a specific build.

TweakTown says the emulator "can now read game instructions in the correct order." That is a simplification, not a technical explanation confirmed by RPCS3.

Crash-free is not the same as playable​

TweakTown notes that most of the six entries are still labeled "In-Game" on RPCS3's compatibility list. The project describes that tier as games that can't be finished, have serious glitches, or have insufficient performance.
Overclock3D adds a useful detail. The RPCS3 team says a game reaches "Playable" only when its performance matches PS3 levels on RPCS3's recommended specifications. Overclock3D reads this to mean that, with a sufficiently powerful PC, users can already get playable performance, while games stay at "Ingame" until the recommended hardware gets there. Notebookcheck likewise reports that the games aren't classed as "Playable" because of insufficient performance.
So the "In-Game" label here may reflect speed on reference hardware more than a pile of visible bugs. Nobody has published a per-game breakdown, so I won't guess which problem affects which title.

One more detail​

According to a post on X from the AGTP account, RPCS3 said the Ratchet & Clank HD collection never had this crash problem. That account also says only the games built on Insomniac's own PS3 engines did. This is a social-media relay of the team's replies, so treat it as lead-level information. It would explain why the list covers the later standalone releases.

How to check your own copy​

RPCS3's wiki explains that compatibility is tracked per Game ID, batched by media, and not per game title. The disc and digital versions of the same game have separate entries on the list. Regional IDs also need separate reports.

1. Find the Game ID of the edition you own: disc, PSN download, or regional release.
2. Search the RPCS3 compatibility list for that ID and read its status.
3. Open the linked forum thread for recent user reports on hardware and settings.
4. Update to a current RPCS3 build before testing. I couldn't verify which build first contained this fix.

If you still get crashes, RPCS3 has previously suggested raising the RSX FIFO Accuracy setting. I couldn't confirm that doing so is needed or helpful for these six titles after the new fix.

Hardware expectations​

Neither source gives a recommended CPU or GPU, game-specific settings or benchmarks for these games. TweakTown's advice that you'll need a "beefy" PC is broad and unquantified. Treat performance as unknown until you test your own setup. Older forum reports for Tools of Destruction exist, but they come from earlier builds and different hardware. They shouldn't be taken as current performance data.

The bigger picture​

The milestone fits a strong year for the project. According to Overclock3D, the "Playable" count has risen from 2,558 in January 2026 to 2,809, and RPCS3 rates more than 99% of PS3 games as "Ingame" or "Playable." RPCS3's wiki table shows the September 2026 figures: 2,809 Playable, 721 Ingame, 31 Intro and 2 Loadable, out of 3,563 entries.
The takeaway: a project-wide stability fix is real progress, and it gives these six games a better shot at a full "Playable" rating. Until the compatibility entry for your Game ID changes, expect to tune settings and possibly accept uneven frame rates.

Microsoft’s October security release addresses CVE-2026-73009, a Critical Windows Secure Socket Tunneling Protocol (SSTP) remote code execution flaw that administrators should treat as a priority patching item wherever affected Windows clients or servers are deployed.
The vulnerability’s exact title is Windows Secure Socket Tunneling Protocol (SSTP) Remote Code Execution Vulnerability. Microsoft describes it as: “Use after free in Windows Secure Socket Tunneling Protocol (SSTP) allows an unauthorized attacker to execute code over a network.”

Why CVE-2026-73009 matters​

The issue is classified as CWE-416, a use-after-free weakness. This class of memory-safety flaw occurs when software continues to use memory after it has been released. In the worst case, carefully constructed network input can turn that programming mistake into code execution.
Microsoft’s advisory states that an unauthenticated attacker could send a specially crafted packet to an affected service over the network. If exploitation succeeds, the attacker could execute code on the target system. No authentication or user interaction is required.
The security rating reflects that potentially serious outcome:

• Severity: Critical
• CVSS base score: 9.8
• CVSS temporal score: 8.5
• CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C
• CWE: CWE-416
• Exploitation assessment: Exploitation Less Likely
• Publicly disclosed: No
• Exploited: No
• Customer action required: Yes

That CVSS vector is the attention-getter: network access, low attack complexity, no privileges, and no user interaction. In short, this is not a vulnerability that waits patiently for someone to click a suspicious attachment.

Patch the Windows systems in scope​

Microsoft has supplied updates across a notably broad range of Windows client and server releases. The practical goal is straightforward: deploy the applicable KB and verify that systems reach the corresponding fixed build.

Windows 10​

Windows 11​

Windows Server​

Administrator checklist​

1. Identify systems running one of the affected Windows products listed above.
2. Match each device’s Windows release and architecture to its required KB.
3. Deploy the update through the organization’s normal Windows update-management process.
4. Confirm successful installation and validate the fixed build number, rather than treating update approval as proof of remediation.
5. Give particular operational attention to systems that expose or rely on SSTP services, since Microsoft’s stated attack path involves a specially crafted network packet.

CVE-2026-73009 is an example of why monthly Windows security maintenance is not merely housekeeping. The remediation is clearly mapped to KB packages and target builds; the job now is making sure the fleet actually arrives there.

When an app vanishes from Open with, the usual culprit is not a missing Windows feature. It is a broken, incomplete, or overly narrow file-association registration. Windows may still show the program in Start, and the app may launch perfectly well on its own, yet it no longer advertises itself as an option for the file you clicked.
The good news: this is normally repairable without registry surgery, “association fixer” utilities, or the sort of command-line archaeology that turns a five-minute annoyance into a Saturday project.

First, identify the exact file type​

Before changing anything, confirm the file’s extension. A photo might be .jpg, .jpeg, .png, .heic, or a camera manufacturer’s raw format; a video might be .mp4, .mkv, or .mov. Two files that look similar in File Explorer can require entirely different apps.
If extensions are hidden:

1. Open File Explorer.
2. Select View.
3. Choose Show > File name extensions.
4. Note the extension after the final period in the file name.

This matters because Open With is built around the file type, not the broad category. An app may correctly appear for .mp4 but not for .mkv, for example. That is not necessarily a Windows fault; the app may simply not claim support for that particular format.

Use “Choose another app” before resetting anything​

Right-click one affected file, then select:
Open with > Choose another app
Windows should display recommended programs. If your preferred app is missing, select Choose an app on your PC and browse to the application’s executable file, usually in one of these locations:

• C:\Program Files
• C:\Program Files (x86)
• Your user profile’s AppData\Local\Programs folder for some per-user installs

Choose the app’s main .exe file—not an updater, launcher, uninstall utility, or helper process. If Windows offers the checkbox to always use that app for this file type, enable it only if that is genuinely what you want.

What success looks like​

After choosing the app, right-click another file with the same extension. The app should now appear in the Open with list, and the file icon may update after a short delay or a File Explorer restart.
Microsoft’s current Windows guidance confirms that Open with can be used both for a one-time launch and for assigning an app as the default handler for a file type. It is the safest first-line fix because it preserves the user’s control over the association.

Check the default association in Settings​

If the app can be selected manually but does not remain available—or Windows keeps opening files in the wrong program—check the association directly.

Windows 11​

1. Open Settings.
2. Select Apps > Default apps.
3. In the search box, enter the extension, including the period—for example, .pdf, .txt, or .png.
4. Select the matching file type.
5. Choose the app you want Windows to use.

You can also search for the application by name in Default apps. This shows the file and link types that Windows currently allows that app to handle.

Windows 10​

1. Open Settings.
2. Go to Apps > Default apps.
3. Select Choose default apps by file type.
4. Find the extension and assign the preferred program.

If the application is absent from both the Open With dialog and the Default apps page, do not assume Windows is merely hiding it. That typically points to the application’s own registration being damaged or incomplete.

Repair the missing application​

Windows cannot reliably offer an app that has not registered itself as capable of opening the file type. Reinstalling or repairing the affected app often restores those registrations.

For Microsoft Store apps and supported Windows apps​

1. Go to Settings > Apps > Installed apps.
2. Find the affected app.
3. Select the three-dot menu next to it.
4. Choose Advanced options.
5. Select Repair.

Try Open With again after the repair completes.
If Repair is unavailable or does not solve the problem, use Reset only with care. Reset can remove the app’s local data, saved settings, and sign-in state, depending on the app. Think of Repair as a tune-up; Reset is closer to emptying the glove compartment onto the driveway.

For traditional desktop programs​

Open Control Panel > Programs > Programs and Features, select the program, then choose Repair or Change if either option is available.
If no repair option exists, download the current installer from the software publisher and run it again. During setup, look for options such as:

• Repair
• Modify
• Register file associations
• Associate supported file types
• Install for all users

Select only the file types the app truly supports. A media player that claims every extension in sight may sound convenient until a spreadsheet double-click suddenly launches a concert video player. Computing has enough surprises already.
Microsoft’s developer documentation explains why this works: programs must register the file types they support before Windows can offer them as candidates in the Default apps and Open With experiences.

Rebuild the available-app list safely​

There is no supported “rebuild Open With cache” button, and that is by design. Modern Windows protects default associations so that malware and overly enthusiastic installers cannot silently seize control of your files.
Use this safe sequence instead:

1. Close the affected app.
2. Repair or reinstall it using its official installer or Windows’ Repair feature.
3. Restart Windows or at least sign out and back in.
4. Return to Settings > Apps > Default apps.
5. Assign the app to the specific extension.
6. Test with a second file of the same type.

This refreshes the app’s legitimate Windows registrations without editing protected association data manually.
Avoid registry “fixes” that promise to reset every Open With choice. Microsoft documents that default-app settings are protected and that registry-based attempts to force them are unsupported. Such tweaks can also wipe personal preferences, cause Windows to reset an association later, or create a mess that looks suspiciously like progress until the next update.

If the app still does not appear​

Work through these checks:

• Confirm the app supports the extension. An app may open one format but not another closely related format.
• Update the app. Older versions may not properly register themselves on newer Windows releases.
• Try another file of the same extension. A damaged or unusual file can produce misleading results.
• Check whether the file is actually a shortcut or renamed file. Changing .txt to .pdf changes the label, not the file format.
• Use “Choose an app on your PC.” The app may not be recommended but can still be selected manually.
• Ask your IT administrator on a work-managed PC. Group Policy or mobile-device-management rules can apply default associations at sign-in and override local choices.

For an unknown extension, Windows also offers the option to search the Microsoft Store. That can be useful, but do not install the first app with a cheerful icon and a suspiciously broad promise to open “all files.” Verify the publisher and the supported format first.

The practical takeaway​

Missing Open With entries are usually an app-registration problem, not a reason to rebuild Windows. Start with Choose another app, verify the extension, set the association in Default apps, then repair or reinstall the missing program if Windows still does not list it.
That approach is safer than registry edits, survives normal Windows updates more gracefully, and leaves your file associations under your control—exactly where they belong.

GitHub has declared stacked pull requests generally available. The feature began rolling out in public preview to all repositories on July 30, 2026. The GA release matters for any team that uses GitHub for Windows, .NET, Azure or other development. It adds changes to approvals, signing, merge queues and automation.

What a stack is​

GitHub's documentation describes a stack as two or more pull requests in the same repository. The bottom pull request targets the trunk, usually main. Each later pull request targets the branch of the one below it. Foundational changes, such as shared types and database schema, go in lower branches. Code that depends on them, such as API routes and UI components, goes in higher branches.
Reviewers get a smaller diff for each layer. Developers can keep building on top of work that hasn't merged yet.
The usual reason given for this is AI-assisted coding. InfoQ framed the feature as a way to balance faster code generation, especially AI-assisted code generation, against limited human review capacity.

What GA adds​

GitHub's changelog lists these changes:

• Approvals survive rebases. When the base branch such as main moves ahead and the stack is otherwise unchanged, Rebase stack keeps approvals. This holds even in repositories that dismiss stale approvals.
• Signed replacement commits. Rebase stack creates signed replacement commits and preserves the original authorship. Automatic rebases after a partial merge also sign the replacements. That happens when branch rules require signatures or when any original commit was signed.
• Bypass permissions. Users who are allowed to bypass repository rules can use that permission to merge the lowest unmerged pull request in a stack.
• Merge queue behavior. A stack enters and lands through the merge queue as a single merge group. With the merge-commit method, GitHub now creates one merge commit per pull request. Before, it created one for the whole group.
• Deleted base branches. GitHub retargets the stack automatically instead of closing the bottom pull request. This supports workflows where one stack branches off another.
• Auto-merge. Stacks can be set to merge once the repository's requirements are met. GitHub says this is rolling out over the next few weeks, so don't assume it is on for your account today.
• Navigation and visibility. Stack details now sit in the pull request page's persistent header and in the pull requests list view. Shift+J and Shift+K move between pull requests in a stack.
• Lifecycle events and webhooks. The timeline shows when a pull request is added to or removed from a stack. The pull_request webhook gains a stacked action when a pull request joins a stack.
• CLI and agents. The gh stack extension for GitHub CLI now supports Git worktrees. GitHub also cites faster initialization, checkout and navigation.

How merging works​

These details come from GitHub's merge documentation.

• Bottom-up only. You can merge any contiguous group that starts at the lowest unmerged pull request. A mid-stack pull request can't merge on its own, because everything below it merges with it.
• Requirements. All lower pull requests must be approved and have passing checks. The stack must have a linear history, and the pull request must meet the branch protections for the stack base.
• Non-linear stacks. If a lower branch changed or the trunk moved ahead, a Rebase stack button appears in the merge box.
• After a partial merge. The next unmerged pull request is automatically rebased to target the base directly.
• Merge queues. Pull requests enter the queue in order. If one is ejected, everything above it is removed too. The queue may exceed its configured maximum group size by up to 50% to keep a stack together. A stack too big for that buffer goes into the next merge group as a single unit.

The merge documentation retrieved during research still says auto-merge is not supported for stacks. That conflicts with the GA changelog. The likely explanation is that the docs haven't caught up with the staged rollout. Treat the changelog as the newer statement, and check your own repository before relying on it.

Automation and API notes​

GitHub's async merge API, which went GA on October 1, is now the recommended way to merge pull requests programmatically. It is also the only merge API that supports stacked pull requests. Scripts that call the legacy synchronous merge endpoints or GraphQL mutations can't merge a stack.
GitHub's API documentation adds several details:

• The merge runs in the background, and callers poll for the result.
• Branch protection and repository rules are evaluated when the merge actually runs. A rule failure shows up as a failed result while polling.
• A stack merge request is atomic. The whole group merges or is queued, or none of it is.
• The REST API can read and manage stacks. GraphQL is read-only for them.

The CLI docs add a few more points:

• gh stack merge is all-or-nothing.
• Branch protection is evaluated at merge time, and any failure is reported back.
• If the base branch uses a merge queue, the queue chooses the merge method.
• The CLI reference notes that merge requirements can't be bypassed through the CLI. The changelog says bypass permissions now apply to stacks, so check the CLI's behavior yourself before relying on bypass there.

Limits to check first​

• Same repository only. Cross-fork stacks aren't supported. The roll-out guide also says stacks can't include forks or branching structures. Teams that depend on fork-based contributions should keep that work outside stacks.
• No GitHub Desktop. Support is listed for the website, GitHub CLI, GitHub Mobile, webhooks, REST, GraphQL and an agent skill.
• Merge-method caveat. One third-party summary of the preview, from AlphaSignal, advises repositories that default to squash or rebase merging to consider merge commits. It says stack identity tracking can break otherwise. GitHub's docs say stacks support all three merge methods, so test this on a non-critical repository.
• Enterprise Server. GA applies to github.com plans. GitHub says only that the feature will be in an upcoming GitHub Enterprise Server release, with no version or date.
• Docs still say preview. Some GitHub guides retrieved during research still carry public-preview notices. The dated changelog is the authority for the GA claim.

Reading GitHub's numbers​

GitHub says that since the preview began, repositories using stacks saw a 9% increase in merged code compared with peers. It also says over two-thirds of the top 1% of repositories now use stacks and saw a 5% improvement in time-to-merge.
These are GitHub's own figures. The announcement gives no measurement period, sample size or definition of "peers". Heavy users of any new workflow tend to be the busiest teams anyway, so cause and effect is unproven. Merged code volume is also not the same as quality.

Practical impact​

The most useful changes for enterprise admins are the ones that stop stacks from fighting repository rules. Approvals that survive a rebase, signed replacement commits and per-pull-request merge commits all keep the audit trail intact. Teams with strict compliance rules were the likeliest to be blocked by earlier behavior.
Developers who use third-party stacking tools should compare them against the native version. Their mechanics now overlap with GitHub's. A DEV Community write-up argues the native feature covers the core mechanics. It says third-party tools still differ on polish, cross-repo workflows and team features. That is one commentator's view.
A cautious way to start:

1. Try a small stack on a low-risk repository with your real branch protections.
2. Confirm that CODEOWNERS and required checks behave as you expect on mid-stack pull requests.
3. If you use a merge queue, check how a stack sits in it.
4. Update any merge scripts to use the async merge API.
5. Wait for auto-merge to reach your account before building a workflow around it.

VMPal is a new virtual machine app for Apple silicon Macs. It can run Windows 11 next to macOS and Linux, and it has a built-in way to hand a VM to an AI coding agent. It comes from the team behind TablePlus. Its first release, version 1, shipped on 6 October 2026. Most of what follows is the developer's own description. I haven't benchmarked the app, so treat the performance and isolation claims as vendor statements.

What you need to run it​

VMPal requires an Apple silicon Mac running macOS 26 or later. That excludes Intel Macs. The app is free to download, and a license is a one-time purchase.
The guest list is macOS, Windows 11, Ubuntu and Fedora. You can have VMPal download a system for you, or you can point it at an IPSW or ISO you already have. The installer runs inside the VM's own window and sets up your account and VMPal Tools. One condition applies to macOS guests: macOS 27 guests need macOS 27 on the host Mac.

The Windows 11 side​

VMPal handles the guests differently. macOS and Linux run on Apple's Virtualization framework, while Windows runs on VMPal's own engine. Each draws on the Mac's GPU.
For Windows 11, the vendor lists:

• Retina resolution up to 5K
• A TPM 2.0
• USB device support
• Direct3D 11 and OpenGL 4.1 on the Mac's GPU

The TPM is a practical detail. Windows 11 expects one, and a virtual TPM is what lets it install in a VM at all.

The Arm caveat​

The VMPal pages I reviewed don't say which Windows architecture the guest uses. That matters for software compatibility. Microsoft's Windows Arm FAQ describes the Mac VM route as running Arm versions of Windows 11 (it names Parallels Desktop and Macs with M1, M2 and M3 chips). It also warns that Windows 11 Arm has a built-in emulator for Win32 and x64 apps, a point echoed in coverage of VMware Fusion's Apple silicon support.
Microsoft's FAQ adds that some Windows features, including certain security features, may not be available or fully functional in a Mac VM. It says this about Parallels, not VMPal. Even so, expect the usual Windows-on-Arm limits:

• Drivers must be built for Arm.
• Some anti-cheat games won't run.
• Some third-party security software won't install.

Test your own line-of-business apps before you commit.

Everyday VM features​

VMPal lists these features:

• Disk use: A VM's disk is only as big as what's in it. It moves to another Mac as one file, and clones take space only as they change.
• Snapshots: You can save a VM whether it is running or not, and roll back in seconds.
• Sharing: The clipboard works in both directions, and so does drag and drop. Mac folders show up in Finder, Explorer and Files.
• Port forwarding: You can reach a web server or SSH in a guest through a port on the Mac.
• Live settings: Name, disk, shared folders and network can change while the VM runs.
• Audio: Sound and microphone access are set per VM, and a green light shows when the mic is in use.
• Process separation: Each VM runs as its own app with its own Dock icon, so a crash should stop only that VM.
• Migration: You can import Parallels VMs.

Ubuntu and Fedora guests also get Rosetta for Intel programs and nested virtualization.

The AI agent angle​

This is VMPal's main selling point. On a Mac, an agent often stalls on prompts for Accessibility, Screen Recording and passwords. VMPal's answer is a built-in MCP server. The agent gets screen, keyboard, mouse and administrator access inside the VM, so it avoids those host permission prompts. TablePlus describes it as MCP for an AI agent on your Mac or inside the VM. The supported agents are Claude Code, Codex, Grok CLI and Gemini CLI.
On the safety design, Laravel News reports that agent control is off by default and enabled one VM at a time, and turning it off stops the agent right away. It also says the agent only reaches the network and folders you give that VM. The practical advice is to take a snapshot before a big task, then roll back if the agent breaks something.

What to watch​

A VM boundary is useful, but it isn't a guarantee. I found no independent security audit or detailed threat model. An agent with administrator rights inside a guest can still misuse anything you connect to it, such as shared folders, a forwarded network or saved credentials. A cautious setup shares nothing it doesn't need.
Apple's own plans add context. iThinkDifferent reports that Apple intends to add new controls around Full Disk Access because of AI agents, but hasn't said which macOS release will carry them or when. That is background, not a VMPal feature.

Versions and pricing​

The release notes show three builds on launch day. Build 37 fixed a Windows sound issue and added a cancel button for new-VM installs plus a location option for new VMs. Build 38 fixed crash issues and a VM losing its menu bar. A launch-day run of three builds suggests the app is still settling, so I'd treat it as early software.
Pricing, all in USD with VAT possibly extra:
Each license includes all features plus one year of updates and support. After that year the app keeps working without limits, and renewal only buys more updates. The vendor's pricing page offers a 7-day money-back guarantee. It says the early-bird discount ends soon but gives no date. It also says the free trial currently has no limits, but some functions will be restricted in future releases.

How it compares​

iThinkDifferent notes that VMPal enters a market that already has Parallels Desktop 27 and UTM 5.0.5. VMPal advertises OpenGL 4.1 for Windows, while Parallels Desktop 27 claims Metal-based OpenGL 4.3 for Windows VMs. No controlled tests compare VMPal with either, so I won't call it faster or more capable. What sets VMPal apart on paper is the agent tooling and the one-time price. Parallels' edge on paper is its enterprise tiers and its longer track record.

Bottom line​

VMPal is worth watching if you want Windows 11 on an Apple silicon Mac and are curious about sandboxing AI agents. Check four things first:

1. Your Mac is Apple silicon and runs macOS 26 or later.
2. Your Windows apps, drivers and peripherals work on Arm.
3. You're comfortable that the vendor's isolation claims are unaudited.
4. You've tested the app during the 7-day refund window.

A 24/7 Wall St. piece pits Jensen Huang's AI claims against Satya Nadella's. Its framing is simple: NVIDIA sells the AI hardware, Microsoft is one of its largest buyers, so each CEO's numbers help test the other's. The piece itself is investing commentary with sponsor copy and stock-performance talk. Underneath it sits a set of earnings-call claims that matter to anyone planning Azure capacity, Copilot rollouts or AI infrastructure budgets.
Several figures in the original don't match the primary sources. This article corrects them and then asks which claims are easiest to verify.

First, a few corrections​

• Different quarters. NVIDIA's numbers cover its fiscal Q2 2027, which ended July 26, 2026. Microsoft's cover the quarter ended June 30. They are not contemporaneous results, so a side-by-side "just reported" comparison is looser than it looks.
• The 138% figure is not networking. The original attributes 138% growth to networking. On NVIDIA's call, that number belongs to the ACIE category (NeoCloud, industrial and enterprise customers, up 25% sequentially and 138% year over year to $40 billion). Networking is a separate line, and it grew 18% sequentially, with Spectrum-X Ethernet up 2.6 times year over year.
• The chip is Maia 200, not "Maya." Microsoft's January 26, 2026 announcement describes it as an inference accelerator with 30% better performance per dollar than the latest generation hardware in its fleet. That is Microsoft's own comparison against its own fleet, not an independent benchmark.
• The "supply covers about 70% of demand" line. I could not substantiate it. What NVIDIA's CFO said is that the roughly 70% fiscal 2028 growth outlook is "a supply-constrained outlook". The 70% in that sentence is growth, not a share of demand met.

Huang's side: real growth, financed demand​

The hard numbers are strong. NVIDIA reported revenue of $96.2 billion, up 106% year over year and 18% sequentially. Data Center revenue was $89 billion. Hyperscale customers contributed $49 billion, up 13% from the prior quarter, and ACIE supplied the other $40 billion.
The soft spot is how some of that demand gets financed. NVIDIA's CFO said the company has invested nearly $50 billion in frontier AI laboratories. NVIDIA has also introduced a structure for neocloud facilities. As described on the call, NVIDIA provides a take-or-pay commitment on part of a facility's capacity, a minimum revenue guarantee that gives lenders confidence, and shares in neocloud revenue earned above that floor.
The precise wording matters here:

• This is a revenue guarantee plus revenue-sharing, not a straightforward loan. Management emphasised that independent capital underwrites each deal.
• It does tie some of NVIDIA's future sales to arrangements NVIDIA itself backs. The CFO's own expectation was that lab demand supported by its balance sheet could be roughly a quarter of next year's business.
• Nothing in the evidence shows the arrangements are improper, or that all demand is circular. They do make the demand less independent than raw revenue growth suggests.

NVIDIA's days sales outstanding rose to 60. The company attributed that to longer payment terms extended to large investment-grade customers. The original claims it was 45 before, but I could not verify the prior-period comparison. Treat it as a metric to watch, not as proof of trouble.
Forward guidance is concrete and testable:

• Q3 revenue: $108 billion, plus or minus 2%, with no China Data Center compute revenue assumed.
• Q3 gross margin: about 74%.
• Q4 gross margin: possibly bottoming at 71%–72% as memory prices rise faster than expected.
• Vera Rubin: about 20% of Q3 Data Center revenue.

Nadella's side: smaller claims, easier checks​

Microsoft's claims are more granular. For the June quarter, Microsoft Cloud revenue was $59.3 billion, up 27%. Azure and other cloud services grew 43%, and Microsoft said demand continued to exceed available capacity. Microsoft guided to roughly 45% Azure growth in constant currency next quarter. It also warned that growth rates can swing with capacity timing and contract mix.
Other checkable figures from Microsoft's call:

• Copilot seats. Microsoft 365 Copilot passed 30 million paid seats, with net paid-seat adds more than doubling sequentially. Paid seats are not usage and not customer return on investment, so this is a sales metric, not an outcome metric.
• Backlog quality. Commercial remaining performance obligation (contracted future revenue) grew 84% to $678 billion. All sequential growth came from customers outside frontier-model companies, and RPO excluding OpenAI rose 25%. That 25% is the figure the original lists as a "weak spot." It is slower, but it is also the cleaner measure of backlog that does not depend on one customer.
• Customer mix. For the full year, cloud revenue topped $214 billion, nearly 90% of it from customers outside frontier model companies.
• Capex. Microsoft's calendar-2026 capex expectation is approximately $175 billion. That figure reflects a change in how some datacenter leases are classified, from finance leases to operating leases, which came with extending estimated datacenter and building useful lives from 15 to 25 years. Microsoft says underlying investment plans are unchanged. It is not a single quarter's spend.
• Earnings quality. The quarter included a $3.2 billion gain on Microsoft's Anthropic investment. It is an accounting benefit, separate from operating growth.

What this means for IT teams​

For admins and architects, the comparison turns into practical questions:

1. Capacity risk is shared. Microsoft says Azure demand exceeds capacity and NVIDIA says its outlook is supply-constrained. Plan GPU-dependent workloads with lead time and fallback regions or SKUs.
2. Inference economics may shift. Maia 200 is meant to serve models including OpenAI's GPT-5.2 family in Foundry and Microsoft 365 Copilot. Microsoft says the performance-per-dollar gain will reach customers through those services. Whether it shows up in your pricing is something to ask your account team.
3. Copilot ROI needs its own evidence. Seat counts show sales traction. Measure adoption and outcomes in your own tenant before extrapolating.
4. Memory costs are a hardware wildcard. NVIDIA's margin warning is tied to memory pricing. That is the same pressure that can raise server and PC component costs generally. This is analysis from general industry reasoning, not a figure from either company's call.

Whose promises are easier to verify?​

The original's author trusts Nadella's math slightly more. The primary sources support a narrower conclusion: the two CEOs make different types of claims.

• Huang's realized results are exceptional, but a meaningful share of forward demand relies on arrangements NVIDIA helps finance.
• Nadella's metrics are smaller and more checkable, but they carry their own caveats: paid seats are not usage, RPO is future contracted revenue, and free cash flow is under pressure from heavy build-out spending.

The next data points are the same ones the original names. Watch whether NVIDIA reaches $108 billion with Vera Rubin near 20% of Data Center revenue, and whether margins hold near guidance. Watch whether Azure approaches 45% growth and RPO excluding OpenAI keeps climbing. Those are management forecasts, not outcomes. I have not independently verified the stock-return and P/E comparisons in the original, so I have left them out.

WinDirStat 2.9.2 is out, and the main addition is deleted-file recovery for FAT12, FAT16 and FAT32 volumes. That reaches USB sticks, SD cards and older removable drives, the places where an accidental delete tends to happen. The release also improves Recycle Bin recovery, makes the duplicate-file view faster with large groups, fixes a long list of layout and settings bugs, and moves the app to a new license.
The GitHub release page shows the maintainer, NoMoreFood, released this 06 Oct 13:20. It's marked as an Immutable release. Only release title and notes can be modified. That second point matters for an open-source tool that gets copied a lot: the published binaries can't be swapped out quietly after release.

What's new in WinDirStat 2.9.2​

Enhancements​

The release notes list six enhancements:

• Deleted-file recovery for FAT12, FAT16 and FAT32 volumes. This is the headline feature.
• Original filename and path detection for Recycle Bin recovery. Recovered items can now show where they came from.
• Faster duplicate view for large duplicate groups. This helps anyone hashing a large media library or a messy file share.
• Better progress reporting and cancellation when creating sparse files, credited to contributor harryytm.
• A revised General settings page layout, also from harryytm.
• Improved Storage Analytics translations across the supported languages.

Bug fixes​

There are 15 fixes. Most deal with how the window and columns behave:

• Column widths and order now come back after a restart.
• Window and column settings are saved before the app restarts with administrator rights.
• Column resizing no longer ignores disabled autosizing or reveals hidden columns.
• Sorting and navigation work correctly with hidden or reordered columns.
• Tooltips and dialog column widths render correctly after font changes.
• Filtering tooltips no longer show outdated examples after you switch regex mode.
• Pane visibility and resizing work across window layouts.
• Menus, checkboxes and radio buttons scale with the font size setting.
• Very small squarified treemap regions no longer trigger an assertion.
• Refreshing items no longer crashes, and matching search results are kept after a refresh.
• Directory regular expressions keep their escape sequences.
• Malformed settings files or CSV/JSON reports no longer crash the app.
• Treemap height slider labels and settings now persist.
• NTFS scans no longer skip valid files after hitting damaged records.
• MSI upgrades work across installation languages.

Two of these matter more than the rest. The NTFS fix addresses a case where a damaged on-disk record could hide valid files from the scan, and that's the kind of drive you're most likely to be investigating. The MSI language fix matters to admins who deploy the installer across machines set up in different languages.

The license change​

The app's license is now GPL v3 or later. Wikipedia's infobox still listed the license as GNU GPLv2 when checked, so expect some third-party listings to lag. The project README says parts of the source code are also available under more permissive terms. For home users nothing changes in practice. Organizations that redistribute or modify WinDirStat should pass the change to whoever handles license compliance.
Section summary: 2.9.2 adds one significant feature (FAT recovery), several improvements and a pile of layout fixes. The license change only matters if you redistribute or modify the app.

How the recovery tool works​

The project's "Recovering Files" guide says Tools > Recover Deleted Files searches local NTFS, exFAT and FAT12/16/32 drives for deleted files whose file-system metadata survives. Before 2.9.2, the FAT family wasn't covered. Some boundaries:

• It requires administrator access.
• It runs separately from the normal disk-usage scan.
• Network shares and MTP devices (phones and cameras connected over Media Transfer Protocol) can't be used as recovery sources, even though WinDirStat can scan them for disk usage.

Steps, based on the project's guide​

1. Stop writing to the affected drive. Anything new saved to that volume can overwrite the deleted data.
2. Check the Recycle Bin first. If the file is still there, restore it the normal way.
3. In WinDirStat, choose File > Run Elevated, then Tools > Recover Deleted Files.
4. Select the source drive and press Resume (the play button) to start. Suspend pauses the scan. Stop ends it but keeps the files it has already validated.
5. When the scan finishes, narrow the list with Path filter. You can type part of a path, use a wildcard such as *.jpg, or turn on Use Regular Expressions. Matching isn't case-sensitive.
6. Select the files you want and set Save To to an existing folder on a different drive or a network share.
7. Click Recover Selected, check each row's Result column, and open the recovered files to make sure their contents are intact.

What a successful result looks like​

A row marked "Recovered – Verify File Data" only means a file was copied. It doesn't mean the contents are correct. The guide uses these assessment labels:

Known limitations​

• FAT: Recovery assumes the file sat in consecutive free clusters, so fragmented files may come back with the wrong contents. FAT short names can start with _ when the original first character is lost.
• exFAT: Only files recorded as contiguous are supported.
• FAT and exFAT: Files inside deleted directories may not appear at all.
• NTFS: Only the main file contents are copied. Compressed or encrypted files, reparse points and files that need extra metadata records are skipped. Alternate data streams and original permissions aren't restored.
• Output: Recovered files go straight into the destination folder without the original folder structure. Existing files are never overwritten, so use separate destination folders if names collide. Saving to the source volume asks for confirmation because it can overwrite other deleted data.
• SSDs: TRIM, overwriting or missing metadata can make recovery useless.

FAT32 is still the default format on many cameras and small flash drives, so this is a real use case. Treat it as a first attempt, though, not the equivalent of a specialist recovery suite or a forensics lab. The project says recovery doesn't replace backups.
Section summary: Run elevated, recover to a different drive, and check every file. Fragmented FAT files and TRIM'd SSDs are where it's most likely to fail.

Supported systems and which download to pick​

The project says WinDirStat 2.x is tested on Windows 7, 8, 8.1, 10 and 11, and on Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019, 2022 and 2025. It may run on other versions, but those aren't supported. The 2.9.2 release offers the same range of packages as earlier releases: Windows x64 installer, x86 and ARM64 MSIs, portable ZIP and 7z archives, a checksums file, and Windows MSIX bundle (x86, x64, and ARM64) plus separate MSIX packages for each architecture.

• Most Intel/AMD PCs: use the x64 MSI. The project names it as the default if you're unsure.
• Snapdragon/Windows on ARM devices: use the ARM64 MSI.
• Older 32-bit Windows installs: use the x86 MSI.
• USB-stick or no-install use: use the ZIP or 7z portable archive and run the executable that matches your CPU.

The project's preferred installation methods are the Microsoft Store, winget (winget install -e --id WinDirStat.WinDirStat, then winget upgrade later), Chocolatey (choco install windirstat) and Scoop (scoop install extras/windirstat). Package repositories can lag behind GitHub. When checked, the Chocolatey listing still showed WinDirStat 2.9.0 as its newest approved package, dated September 26, 2026. If you need 2.9.2 today, check your package manager's version before assuming you have it.
The project also warns about unofficial sites that copy WinDirStat's name and branding and may host outdated or modified files. Its advice is to install only from the Microsoft Store, the listed package managers, the official GitHub releases, or links on the official website. Compare your download against the published hash file.

Release cadence​

This update comes quickly after the last one. GitHub shows a Beta build 2.9.1.2238 published on October 4, and Chocolatey approved 2.9.0 on 27 Sep 2026. Going from 2.9.0 to a stable 2.9.2 in about ten days fits the frequent releases of the 2.x line. Chocolatey's history shows 2.6.0 through 2.9.0 landing between May and September 2026.
That's quite a change for a tool that went almost a decade without updates after version 1.1.2. The question for longtime users is whether a treemap viewer should also handle recovery, permissions, file watching and maintenance shortcuts. The fix list suggests the maintainers are cleaning up the interface as they add features. If you just want to find out what's eating your C: drive, the 2.9.2 fixes for restoring columns and scaling with font size will help in daily use more than recovery will.

Bottom line​

• Upgrade if: you rely on WinDirStat's column layouts, regex filters or CSV/JSON report loading, or you scan NTFS volumes that might be damaged.
• Try the recovery tool if: you've just deleted something from a FAT-formatted USB stick or SD card and haven't written to it since. Recover to a different drive and check every file.
• Admins: check the GPL v3-or-later license against your redistribution policies, and confirm the MSI upgrade across your language variants on a pilot machine before rolling it out.

Stack Overflow's 2026 Developer Survey puts AWS well ahead of the other clouds. It also shows Microsoft Azure, Cloudflare and Google Cloud bunched within about a percentage point of each other. In the cloud development question, AWS was selected by 4,549 of 10,889 respondents, or 41.8%. Azure had 2,737 (25.1%), Cloudflare 2,680 (24.6%) and Google Cloud 2,663 (24.5%). Virtualization Review reported the results on October 6, the day Stack Overflow published them.
That is a useful snapshot of what developers say they build on. It is not a market-share report, and the difference matters for how you read it.

What the numbers measure​

Respondents were asked which cloud platforms, container and orchestration tools, package managers, build tools and infrastructure-as-code products they had done extensive development work in over the past year. They were also asked which they want to use in the next year. The question was optional and allowed multiple selections.
So the figures show self-reported hands-on development. They do not show spending, deployed capacity, revenue or organizational standardization. A developer who ships on AWS for work and tinkers with Azure on the side can be counted in both.
The list is also a mixed bag. It combines cloud platforms with tools such as Docker, npm, pip, Terraform and Homebrew. Docker/Docker Compose topped the whole list at 59.1%, followed by npm at 54.6% and pip at 42.1%. AWS beat everything else in the cloud-provider group but placed fourth overall.

The Azure, Google and Cloudflare cluster​

Azure's lead over Google Cloud is 0.6 percentage points, or 74 respondents. Cloudflare sits between them. With a sample of this size and a self-selected audience, calling that a tie is the honest reading. AWS leads Azure by 16.7 percentage points, which is not a tie.
For Microsoft-focused readers, a few details stand out:

• Azure is level with Google Cloud and Cloudflare in developer usage. It is not clearly ahead of either.
• On the "desired" measure, Google Cloud (13.9%) edges Azure (13.7%), reversing the usage order. Cloudflare's desired score is higher than both, at 16.7%.
• The "admired" scores, which cover people who used a tool and want to keep using it, were AWS 45.8%, Azure 43.2% and Google Cloud 42.6%. Hetzner Cloud scored 63.6% among its much smaller user base.
• Microsoft-adjacent tooling appears further down the list: NuGet at 18.6%, Winget at 11.9%, MSBuild at 11.8% and Chocolatey at 9.7%.

How this compares with earlier years​

Year-over-year comparisons are imperfect because the survey changed, so treat the following as directional only. A DEV Community write-up of the 2025 survey listed AWS at 43.3%, Azure at 26.3%, Google Cloud at 24.6% and Cloudflare at 20.1%. That makes Azure's 2026 figure slightly lower and AWS's slightly lower as well.
Stack Overflow's own analysis for 2026 notes that Cloudflare is up from 20% to 25%. It speculates that bot activity may be a factor, which is a guess and not a finding. Earlier, InfoWorld cited the 2024 survey, where AWS was at 48%, Azure at 27.8% and Google Cloud at 25.1%.
The 2025 survey was much larger, with roughly 49,000 respondents according to one summary. This year's survey has 30,903 responses, and the cloud question drew 10,889. Different sample sizes and a different recruitment window mean small shifts are within what you'd expect from noise.

Containers and infrastructure as code​

Kubernetes was selected by 26.0% (2,836 respondents). That puts it just above Azure, Cloudflare and Google Cloud. Other container and infrastructure tools:

• Podman: 13.0%
• Helm: 12.4%
• Rancher: 4.4%
• OpenShift: 3.2%
• Terraform: 18.3%
• Ansible: 12.0%
• OpenTofu: 3.6%
• Pulumi: 2.0%

OpenTofu's admired score (61.1%) is well above Terraform's (45.7%), even though Terraform has about five times as many selections. Podman's admired score (54.9%) is also close to Kubernetes (53.5%). Because admired scores only count each tool's own users, smaller communities of enthusiasts can easily score higher than a widely used default.
For admins, the practical takeaway is that the infrastructure-as-code and container tooling conversation is broader than one vendor's stack. If your shop runs Azure, the people you hire or work alongside are likely to arrive with Docker, Kubernetes and Terraform experience as much as Azure-specific skills. That is general industry reasoning, not something the survey states.

AI in production operations lags​

The survey's AI workflow question had 12,547 respondents, a different group from the cloud question. For deploying, operating or troubleshooting production systems, 19.9% (2,264 respondents) said they currently use AI or AI agents.
Other answers for that activity:

• 23.3% expect to use AI more for it.
• 7.4% expect to use it less.
• 36.0% neither use it nor plan to.
• 22.0% said it isn't part of their workflow.

Other operational tasks showed higher use. Analyzing data, logs, metrics or query results was at 41.9%. Creating or configuring development and test environments was at 28.1%.
Stack Overflow's announcement from Ryan Donovan sums up the gap: AI gets to muck about with familiar code, but once that code reaches prod server, it gets shown the door. The numeric results are the stronger evidence. The wording covers production systems generally, not cloud workloads specifically. It also doesn't separate AI assistance from autonomous operation.
For IT teams evaluating Copilot-style tooling in Azure or Microsoft 365 operations, the signal is cautious. Developers are comfortable letting AI read logs and metrics, and much less comfortable letting it act on production. A sizable minority says it will not use it there at all.

How much weight to give the survey​

Several cautions apply before you quote these numbers in a planning meeting:

1. Self-selected sample. Stack Overflow promoted the survey through its own website, blog and community channels, according to Virtualization Review. The results do not represent all developers or all cloud administrators.
2. Developers, not buyers. The question tracks hands-on development work. It says nothing about who signs the cloud contract.
3. Mixed categories. The combined list blends clouds, package managers and build tools, so cross-category rankings are not meaningful.
4. Different cohorts. The cloud and AI questions have different respondent bases, so don't read them as one group.
5. Small gaps. Differences of under a point, such as Azure versus Google Cloud, are not decisive.

The bottom line​

AWS remains the cloud developers most often report building on, by a wide margin. Azure, Google Cloud and Cloudflare are effectively indistinguishable in this sample. Docker is the most commonly used tool in the category. AI use drops off sharply as work moves from analysis and development toward production operations. As a read on developer habits it is useful. As a measure of the cloud market it isn't one.