When you purchase through links on our site, we may earn an affiliate commission. Here’s how it works. Microsoft engineer shows how bad code can lead to your Windows PC slowing down Sayan Sen Neowin @ssc_combater007 · May 22, 2025 04:28 EDT Windows 10 is running out of support soon and as such Microsoft issued a reminder recently. The tech giant also published a list of Surface PCs that can't upgrade to Windows 11 as they don't meet the system requirements. The company's official stance is simple: get a new device, ideally, a Copilot+ PC. Meanwhile, home users are also starting to debate how they would deal with this upcoming change. For those still on pre-2015 systems that can't officially run Windows 11, many feel that Windows 8/8.1 and not Windows 11 or even Windows 10, is the way to go, as the older OS feels snappier. Neowin readers also opined on the topic by sharing their thoughts. You can join the discussion in this article. Bear in mind though that while it is a fun topic to talk about, Windows 8.1 support ended back in January 2023, so it's not a secure option to head back to. A reason for the slowness and sluggishness of a system is often bad underlying code that is being run. Recently, an editorial titled "Sloppy software is why you think you need new hardware" authored by colleague David Uzondu, and it looks like a Microsoft employee would quite agree with the idea if he were to read it. Matt Hamrick, a Senior Escalation Engineer at Microsoft, has put up a blog post on Microsoft's site regarding this. The topic covers memory leaks and out-of-memory (OOM) issues that Windows can encounter as a consequence of poor optimization. In the post, Hamrick has used the example of an updated .NET 7 app to establish the premise explaining how a miscalculated ConfigurationBuilder entry for the reloadOnChange parameter can do this. By setting its value to "true" instead of "false", an app can run into memory-leaking scenarios, leading to a sluggish system or a program crash, if not a crash for the entire system. For those wondering, the reloadOnChange parameter tells the system to watch a specified file for modified settings. It essentially helps in dynamic reloading as it automatically reloads the updated settings from memory. Thus parts of an app that reference the set configuration can see the new values immediately, without having to restart it. Hence, this is essentially what leads to the available memory pool filling up over time. He explains: The impact of this code will be greater the more often it is run. The problem is not apparent, but this is the trigger: reloadOnChange: true. .... reloadOnChange: true ... is really only meant to be used during app startup if a custom config file is being consumed that ASP.NET itself does not already consume automatically (assuming those defaults haven't been changed). Instead, as mentioned above, some folks have mistakenly used this code in something like a Controller action or middleware component to gain access to some needed config value, not knowing what it's doing under-the-hood (also not knowing that the config they typically sought was already loaded (and monitored) into the app's configuration system). Matt Hamrick was able to pin down the problematic code by observing a memory dump from the GC (garbage collector) .NET memory manager using various tools like WinDbg, a Windows debugging utility, among others. You can find the full blog post here on Microsoft's Tech Community website. Although the example highlighted here is about an app originally coded in .NET 7, Hamrick notes that the problem is not specific to it and can affect apps using newer .NET versions too, which are still supported. Tags Report a problem with article Follow @NeowinFeed