标签：#Windows

A Windows 11 VM in Proxmox VE was showing nearly 100% memory usage in monitoring. Inside Windows Task Manager, however, actual memory usage was only around 30–50% . At first glance, that looks like a monitoring problem. It wasn't. The issue was in the VM configuration: the PVE Ballooning Device had been disabled , which meant Proxmox VE was not receiving the guest memory statistics needed to reflect the actual Windows memory state. I encountered this while monitoring a Proxmox VE environment with OpsHome NOC. This post documents how I traced the discrepancy and fixed it. The symptom On the same Proxmox VE host, the memory usage of Ubuntu VMs looked normal. One Windows 11 VM was different. The VM had 24 GB of RAM configured, but the monitoring result remained close to: Memory: 100% Used: about 24.2 GB Total: 24 GB Inside Windows 11 Task Manager, however, the VM was clearly not using all of its memory. The difference looked roughly like this: Monitoring: 90%–100% Windows 11: 30%–50% That is too large a difference to treat as a normal sampling variation. If you encounter something similar, especially when Linux VMs on the same Proxmox host look normal, do not immediately assume: Windows has a memory leak The monitoring threshold is wrong The monitoring application is calculating memory incorrectly The more important question is: Is Proxmox VE actually receiving the correct memory statistics from the Windows guest? Checking BalloonService inside Windows 11 For Proxmox VE to obtain useful guest memory statistics from a Windows VM, the VirtIO Balloon driver and its related Windows service need to be available. Inside Windows 11, I opened PowerShell and checked BalloonService: Get-Service * balloon * The result showed: Running BalloonService So the Windows-side BalloonService was already installed and running. At this point, the guest-side service did not appear to be the problem. The next step was to check the VM configuration on the Proxmox side. Checking the Proxmox VE

A frozen desktop window is a state, not a diagnosis. Windows adds Not Responding when the UI thread stops processing messages for long enough. That can happen because the application is doing legitimate work, waiting for disk or network I/O, blocked by another process, stuck behind a modal dialog, or caught in a real deadlock. Reinstalling may replace files, but it does not tell you what the process was waiting for. Preserve a few minutes of evidence first. Define the symptom precisely Keep these cases separate: Slow: the window still repaints and eventually accepts input. Not responding: the frame is visible, but Windows reports that the app is not processing messages. Blank: the frame appears while the content surface fails to render. Invisible: the process runs without a visible main window. Crash: the process exits and may create an application error event. This distinction matters. A blank WebView surface and a blocked UI thread can look similar to a user, but they leave different evidence. Use one repeatable action Restart the application once and perform the smallest action that reproduces the freeze. Record: the exact click or file that triggers it; the time the action starts; how long the window remains responsive; whether CPU, disk, or network activity changes; whether the process recovers without being terminated. Avoid opening several test files or clicking repeatedly. Extra input can queue more work and hide the original transition. Watch the process before ending it Open Task Manager and identify the correct process ID. Expand child processes if the application uses helpers or a web-rendering runtime. Useful observations include: High sustained CPU: a loop, intensive parsing, OCR, compression, or rendering work is plausible. Near-zero CPU with disk activity: the process may be waiting for storage. Near-zero CPU with network activity: an online request, proxy, DNS, or TLS operation may be blocking progress. Near-zero activity everywhere: look for a hidd

This is the latest zero-day released by security researcher Nightmare Eclipse, despite Microsoft publicly threatening to take legal action against them.

The deadline nobody missed Every expiry story we've written here has the same shape. A certificate lapses, nobody was watching, something breaks, and everyone is surprised. A Splunk license at a federal agency. Microsoft's own network connectivity tool. Same plot, different logo. This one is the opposite, and that's what makes it worth reading. On October 19, 2026, roughly ten weeks from this writing, the Microsoft Windows Production PCA 2011 certificate expires. It sits under the trust chain for the Windows boot process on essentially every PC shipped in the last fifteen years. Nobody forgot it. The expiry date has been printed inside the certificate since 2011. Microsoft has been publishing guidance for over two years, shipping replacement certificates through Windows Update since 2024, running OEM briefings, and pushing an automatic rollout that requires most users to do nothing at all. It is August. It still isn't done. What's actually expiring Three certificates, four replacements, three dates, all in 2026: Certificate Expires Replaced by Microsoft Corporation KEK CA 2011 June 24, 2026 Microsoft Corporation KEK 2K CA 2023 Microsoft Corporation UEFI CA 2011 June 27, 2026 Microsoft UEFI CA 2023 Microsoft Corporation UEFI CA 2011 June 27, 2026 Microsoft Option ROM UEFI CA 2023 Microsoft Windows Production PCA 2011 October 19, 2026 Windows UEFI CA 2023 Both June dates have already passed. October is the one that matters most, because that's the certificate used to sign the Windows Boot Manager itself. Devices that don't pick up the 2023 certificates keep booting and keep taking normal Windows updates. What they lose is the ability to receive new protections for the early boot path: updates to Boot Manager, Secure Boot database changes, revocation lists, and mitigations for bootkit vulnerabilities discovered from here on. In other words, the machine doesn't fail. It just quietly stops being patchable in the one layer that sits below your antivirus, your EDR agent, a

I tried the obvious nerd experiment on a fresh Windows machine: let an AI agent handle setup. It looked clever for about two minutes. Then I watched OpenClaw get stuck on installer checkboxes, pause on modal windows, and generally do the digital equivalent of forgetting why it walked into the room. While it was still fighting one installer, I switched tactics: Ninite for the common app bundle WinGet for package installs I wanted to keep and rerun PowerShell for the boring system-level stuff GPT-5 or Claude for planning, not clicking That combo finished 18 app installs before the agent recovered. And after reading through this r/openclaw thread , I think the real lesson is bigger than Windows setup: GUI-driving agents are the wrong abstraction for deterministic work. If the task is "figure out what this machine needs," use a model. If the task is "install these 18 things and stop being interesting," use scripts. The mistake: asking an agent to be a mouse I’m not anti-agent. I’m anti-fragile-automation. OpenClaw, GPT-5, and Claude are useful when the problem is ambiguous: "Set this machine up for Python, Docker, VS Code, Node, and a local Ollama stack" "Compare package managers and suggest the cleanest install path" "Draft a setup script and explain what might fail" They are much less useful when the problem is fully deterministic: Click Next Decline the bundled toolbar Choose default install path Wait Repeat 17 times That second category is where WinGet, Ninite, and PowerShell win by being boring. Boring is good. This is the same pattern you see in real automations in n8n, Make, Zapier, or custom agent workflows: let GPT-5 or Claude interpret messy input let deterministic steps execute the plan keep the model out of the loop unless judgment is required That architecture is faster, easier to debug, and usually cheaper. What actually worked on a fresh Windows setup Here’s the split I’d use again. Job Best tool Install common desktop apps fast Ninite Create a repeatable

Introduction Setting up a SIEM sounds simple until you have to prove that it is actually seeing what you think it is seeing. For this project, I added Wazuh and Sysmon monitoring to an Atomic Red Team workstation, then used safe attack simulations to trace activity from the Windows endpoint into the SIEM. Two of my experiments produced clear, matching evidence in Sysmon and Wazuh. A third showed something equally useful: Sysmon recorded the activity locally, but I could not find a matching Wazuh alert. That gap taught me that installing a logging tool is only the beginning. Detection coverage has to be tested, not assumed. My name is Christopher Bontempi, and I am transitioning into cybersecurity because I enjoy problem-solving, continuous learning, and figuring out how systems fit together. This is my first contribution to the cybersecurity community. I hope it helps another beginner see how a collection of logs can become a useful story about what happened on a system. Setup Adding ART Workstation to Wazuh I chose ART Workstation for this project because it already had Atomic Red Team installed. That gave me a safe Windows endpoint where I could generate controlled activity without changing the Active Directory server. From the Wazuh dashboard on Blue-Team Workstation, I generated a Windows agent deployment for the Wazuh manager at 10.170.0.99 . I named the agent ARTWorkstation and assigned it to the default and Windows_Servers groups. On ART Workstation, I ran Wazuh’s generated installer command from an elevated PowerShell window, then started the service: NET START WazuhSvc Wazuh showed ARTWorkstation as active with agent ID 008 and IP address 10.160.0.100 . At that point, I knew the endpoint could communicate with the SIEM, but I still needed useful Windows telemetry to validate the rest of the project. Installing Sysmon and forwarding its logs Next, I downloaded Sysmon and Neo23x0’s sysmonconfig-export.xml baseline configuration. I installed Sysmon64 from an e

Perplexity has expanded its agentic Personal Computer tool to Windows, allowing computers running the world's most popular OS to be used as a locally run AI system. Like the Mac version that Perplexity launched in April, Personal Computer for Windows operates like a "general-purpose digital worker" that can access local files and apps to perform […]

Every five minutes or so, my entire Windows machine would drop off the network for a few seconds — not just WSL, the whole host. Browser tabs would stall, calls would drop, and it only happened while WSL2 was running. This is the story of finding that, plus the WSL memory-tuning landmines I hit right alongside it. The flapping The symptom was a host-wide network blip on a short, regular interval, correlated tightly with WSL2 being up. The cause: WSL2's default networking mode creates a virtual NAT switch on the Windows side, and on this machine that virtual switch was intermittently conflicting with the real network adapter — enough to cause the whole host to briefly renegotiate its connection. The fix was switching WSL2's networking mode entirely, via .wslconfig (on Windows, not inside the Linux filesystem): [wsl2] networkingMode = mirrored dnsTunneling = true autoProxy = true Mirrored networking makes the WSL2 interface share the host's actual network identity instead of sitting behind a separate virtual NAT switch. You can confirm it actually took effect (rather than just trusting the config file) by checking, from inside WSL after a full restart, that its network interface holds the same IP as the Windows host, that the default route points at the real LAN gateway rather than a private NAT range, and that loopback carries mirrored mode's marker address rather than a 172.x NAT address. If any of those don't match, the setting isn't actually active yet. Worth noting: this requires a reasonably recent WSL version and Windows build. If you're on an older one, mirrored mode may not be available at all. The memory landmines, found the hard way Separately — and this had actually caused full VM crashes, not just hangs, at one point — I'd been carrying a few .wslconfig settings that looked reasonable and were each, individually, a documented source of instability: An explicit kernelCommandLine override. Resizing swap past a few GB, which forces WSL to rebuild its virtual

Microsoft has intervened to stop Windows 11 users with LG monitors from being bombarded with annoying McAfee trial pop-ups. In response to complaints about the LG bloatware, Microsoft's Windows chief, Pavan Davuluri, said that LG has agreed to immediately disable the McAfee pop-up from its LG Monitor App Installer, and pledged that Microsoft will "keep […]

HiveLegacy is a "powerful primitive" that's likely capable of other nefarious actions.

On 9 July 2026 the head of Windows published a post about AI-powered vulnerability discovery. One line in it was a warning to customers: "As AI helps defenders discover more issues, customers will see a higher volume of security updates included in each security release." It does not say how much higher. The post runs about 1400 words and contains no numbers at all. Five days later Microsoft shipped the July package: 1150 CVEs. The number Microsoft would not put in the blog post is sitting in Microsoft's own API. The Security Update Guide publishes every monthly package as machine-readable CVRF, acknowledgments included, no key required. So I pulled twelve months of it and did the arithmetic. What the data says I sampled eight months before the ramp and four after it. Month CVEs Month CVEs 2024-07 454 2026-04 737 2025-01 343 2026-05 991 2025-04 374 2026-06 1281 2025-07 527 2026-07 1150 2025-10 427 2026-01 310 2026-02 169 2026-03 460 The eight pre-ramp months average 383 CVEs. July 2026 is 1150, so the package is 3,0 times the old normal. The baseline broke in April and peaked in June at 1281. April to July inclusive is 4159 CVEs. At the old rate that is 10,9 months of output, delivered in four. The number I am not going to use February 2026 had 169 CVEs. It is the lowest month in two years, less than half the baseline. Divide July by February and you get 6,8 times, which is a much better number for a headline. I am not using it, because choosing your denominator is how honest people produce dishonest numbers. February is an outlier, and the only reason to anchor to it is that it flatters the story. The real multiplier is 3,0. It does not need help. It is not noise The obvious objection is that volume without quality is just a bigger pile. If AI were generating low-value findings that got patched anyway, the severity distribution would sag. It did the opposite. Measure 2025-07 2026-07 CVEs 527 1150 CVSS median 6,5 7,5 CVSS mean 6,47 7,26 CVSS 7,0 and above 48,0 % 71,

Microsoft just released a long list of improvements for Windows 11 as part of its bigger patch Tuesdays, and that includes the ability to pause updates indefinitely, as reported earlier by Windows Central. This option rolled out to Windows Insiders earlier this year, allowing you to hold off on updates for up to 35 days […]

Microsoft is testing a cleaner version of the Windows 11 search menu that strips it of recommended content and ads. In a blog post on Monday, Microsoft announced that it's rolling out the decluttered Search Box to Windows Insiders in the Experimental channel as the company looks to regain trust with users and fix Windows. […]

Over the past week, two narratives have been colliding everywhere I look. On one side, there's panic. AI is expected to replace marketers, engineers, and entire categories of knowledge work almost overnight. On the other, there are quieter but far more consequential signals: enterprise teams discovering their AI infrastructure is burning through API budgets far faster than expected. This isn't because the underlying models are weak, but because the systems built around them are fundamentally inefficient by design. These aren't separate stories. They're the same failure showing up in different places. A conversation with another developer made that gap visible in real time. He argued that auditing a 150,000-line codebase requires feeding the entire repository into a model in one single, massive pass. It's still a common assumption in mainstream tech: that an LLM works like a giant biological brain that you must fully load with raw text before it can begin to think. But that assumption is already outdated. Modern AI systems don't scale through brute-force context. They scale through structure. And that shift changes everything. Key takeaways Bigger context windows did not solve AI. Treating a frontier model as a monolithic processor that re-reads an entire system on every query is wasteful, dilutes attention, and hides bugs under raw volume. ARC-AGI-3 makes the gap stark: frontier models scored under 1% on interactive reasoning tasks that untrained humans solve at nearly 100%. The gap is architecture, not memory. The teams pulling ahead treat the model as one narrow component inside a larger system: intelligent routing, task decomposition, retrieval, and only the minimum necessary context. The next advantage is not the biggest model or the longest prompt. It is the system designed around the model. Prompting was the first generation; systems architecture is the next. The Myth of the Infinite Context Window When context windows expanded into the hundreds of thousands o

The feud between NightmareEclipse and Microsoft shows no signs of resolving soon.

Microsoft is addressing a Windows 11 bug that caused a folder to take up several gigabytes of storage space. As spotted earlier by Windows Latest, Microsoft included the patch in its optional June 2026 update (KB5095093), which "improves disk space usage for the CapabilityAccessManager.db-wal file." The CapabilityAccessManager.db-wal file is installed on Windows 11 PCs by […]

About a quarter of PCs are still running Microsoft's previous operating system.

In a new Windows Developer Blog post titled "Windows platform security for AI agents", Microsoft positions Windows as the trustworthy operating system for autonomous agents and introduces the Microsoft Execution Containers (MXC) SDK as the core of that strategy. The post argues that containment, identity and manageability must be built into the operating system. By Matt Saunders

How to Call Windows Native APIs in Electron Calling Windows native APIs in an Electron app feels like wanting to see the ocean but only having a map. After some trial and error, I've found a few paths—writing this article serves as a record and a guide for others who might follow. Background When building Electron desktop applications, you inevitably need to interact with the operating system. On Windows, these requirements are quite common: Calling Windows Store APIs for in-app purchases Handling file system virtualization specific to Windows Store apps Obtaining system-level permissions and resources Interacting with Windows Runtime (WinRT) components Electron is fundamentally a Node.js environment, and Node.js doesn't natively provide direct access to Windows native APIs. A bridge is needed between the two. It's like trying to communicate with a friend who doesn't speak Chinese—you need a translator. Electron is written in JavaScript, Windows APIs in C/C++. The language barrier requires building a bridge. That's the harsh reality of the code world. About HagiCode The solutions shared in this article come from our practical experience with the HagiCode project. HagiCode Desktop needs to call Microsoft Store APIs to handle subscription purchases and license management, which is why we developed a set of technical solutions. After all, necessity drives innovation—that's a truth. Technical Solution Comparison When calling Windows native APIs in Electron, there are several mainstream approaches to choose from. Each has its applicable scenarios—like different tools in a toolbox, they work best when used in the right place, otherwise just add trouble. Solution Applicable Scenarios Pros Cons dynwinrt WinRT APIs (e.g., Store API) Type-safe, auto-generated bindings, modern JavaScript support Only supports WinRT APIs, requires Windows SDK Native Node.js Extensions High performance, any Windows API Complete control, optimal performance Requires C++ development skills, comple

Vercel Labs recently open-sourced zero-native, a cross-platform framework for native desktop applications. Zero-native bypasses Electron runtime in favor or native OS WebViews and claims to achieve smaller, more efficient native apps with minimal overhead. Zero-native is written in Zig, thus directly interoperates with native C libraries, and features fast incremental compilation times. By Bruno Couriol