Remediation Service: Windows 10’s Dirty Secret

I don’t use Windows often. Much of my time is spent in Arch Linux except on the rare occasion I have an interest in doing something that requires Windows (typically gaming or Reason). Imagine my surprise when I booted in Windows about a week or two ago and started noticing a series of processes consuming a significant amount of disk bandwidth and appearing to scan the entirety of a) installed applications and b) everything in my user profile directory.

It turns out that sometime late last year (November 2018, possibly earlier), Microsoft released a series of patches for “reliability improvements” which include the “remediation service” that performs a few interesting tasks. Notably, this includes a service that “may compress files in your user profile directory to help free up enough disk space to install important updates.” If you’ve seen sedlauncher.exe in Windows Resource Monitor, it belongs to the remediation service and is the tool design to scan your user profile directory, presumably for files that may be candidates for compression.

sedlauncher.exe‘s malware-like behavior stems from the fact that a) it isn’t strictly launched when Windows Update requires additional space and b) it performs a thorough scan of everything in the user profile directories (pidgin chat logs, pictures, media, desktop files–everything). I assume this is because it is collating a list of files it would compress in the event Windows Update runs out of space based on some heuristic, but what perplexes me is that it is impossible to tell precisely how well a file will compress until the file is actually compressed. Yes, there’s a few heuristics you could apply (it is a file type known to compress well) but these don’t always hold true: Imagine a virtual machine image that contains a large number of compressed archives. VM images do compress well, generally, but only because the contents of the image aren’t typically compressed. But this also presents the question: Why scan for compression targets when there’s already plenty of disk space available to Windows Update? What exactly is this tool doing?

Most guides online direct visitors to one of two solutions: Remove the applicable updates or disable the Windows Remediation Service. The former isn’t a sustainable solution, because the updates will eventually be applied or because Windows’ stellar history of absolutely no security flaws (sarcasm) strongly suggests skipping updates isn’t wise. Curiously, the latter option–that is, disabling the culprit service–appears to be a foolhardy solution as well, because sedlauncher.exe returns, diligently, to its previous state of scanning everything it can access. It’s likely Windows Remediation Service scanners are launched via the task scheduler, but I’ve yet to find exactly where or how.

There is one particular solution that might work. Unlike most other core Windows tools, sedlauncher.exe is not contained in the Windows root. Instead, it resides under C:\Program Files\rempl. This rather bizarre choice suggests Microsoft has a keen interest in packaging this tool separately for other operating systems or wishes to disguise it as an installed application to keep it from prying eyes. You decide.

I’ve found renaming sedlauncher.exe to something else appears to work as a temporarily solution (but only temporary) with the appropriate caveats applied (exercise caution as this may break things). I expect it to be reinstalled with a future update, but for now it won’t be scanning my profile directory for files to assault. Whether this works in your case (or not) is left as an exercise to the reader, but be aware this may break other parts of Windows Update. I have no idea how deep the tendrils of this telemetry run into the dark recesses of Windows 10.

No comments.

Windows 7 Maxing Out RAM?

Yeah, I thought it was a bit ridiculous, too.

I was reading this piece on Slashdot a couple of days ago, slightly infuriated, because I’ve actually had very few issues running Windows 7–with some exceptions. I’m glad that Ars Technica has come out to set the record straight.


Turns out that there’s some speculation the individual who brought the memory issues to the forefront is a fraud.

Anyway, look forward to seeing another link of the week in a few days. I’ve been getting caught up with a couple of things, including a personal project in my free time that might be of interest (more on that in another post). Actually, I have several; there’s one in particular that I’ve found rather captivating. Stay tuned! If I get around to it, I’ll post a little tomorrow.

No comments.

NoSleep Released

So, I finally got around to writing a suitable replacement for the little Python script I was using to kill power management on my Thermaltake external USB/eSATA drive. But first, some history.

I didn’t mention it in the assembly guide I wrote for the Thermaltake enclosure, but as it turns out, the SATA chipset Thermaltake opted to use suffers from a rather annoying problem: If you leave it idle for more than about 15-20 minutes, it will turn the disk off. Since I like to have control over when the disk turns off, I had to write a script to periodically write a (blank) file to the disk. The idea being, of course, that if you can force some sort of activity, the drive will never go to sleep. (Edit: This isn’t entirely correct; based on information I received from Mike Fisher, it appears the source of the power down is actually the choice of hard disk–a Seagate ST3500410AS–that enters standby mode. I’ll update this accordingly once I find out if there is a means of stopping this.) As it turns out, this information isn’t completely correct either. If you’ve purchased one of these cases, it appears that the chipset will power the disk off only if it’s plugged in via USB. If you plug the bay in via eSATA, the disk will never shut off unless the OS commands it to.

The thing is, I had forgotten at least once or twice to browse to the root of my external enclosure where I kept the little Python script that did the trick. What’s more, it also required (under Windows anyway) a DOS prompt to exist as long as the application was running. Neither of these seemed to be suitable options.

Enter NoSleep

I decided to write NoSleep as a replacement for the little Python script that could. In fact, the replacement is even better–you don’t know it’s running. That’s the idea, anyway. Here are some highlights:


  • Installs as a service. You don’t know it’s running in the background.
  • Isn’t invasive.
  • Scans for all removable media when you first turn the service on or install.
  • Monitors for new connected media.

This means that no matter what you do, be it unplugging an external disk and plugging it back in, NoSleep will keep an eye out. Whenever it spots something that could potentially go to sleep, it’ll start polling the disk. I use the same technique borrowed from the little Python script, too. Every once in a while, NoSleep will write to the contents of a file fittingly called .nosleep (the leading dot is intentional) and force the chipset on the drive to take note of activity, halting its sleep timer.

Why NoSleep?

Why? That’s a good question. Frankly, there are other applications out there that do the exact same thing. The thing is, all of the ones I found ran in the system tray and you had to add them to the startup folder (or the registry–though, at least one such application added itself automatically). I wanted something that would run without any indication it was running. I didn’t want a tray icon. I didn’t want to have to double-click an application every time I connect my poorly behaved enclosure. I just wanted it to work.

That’s reason enough.

So What’s the Catch?

There is none. NoSleep is free. In fact, I released it under the GPLv3. You can even browse the sources if you like. NoSleep does depend on my WMIDiskUtils library. I have released the latter under the LGPLv3, so you can use it in your own projects even if they’re closed source.

System Requirements

NoSleep does have some system requirements. First, it requires the .NET Framework version 3.5 or higher. While it should work on Windows 2000, I have only tested it in Windows XP SP3 and Windows 7. So long as you have .NET installed, I don’t imagine there would be much of a problem.

Take a look at the NoSleep Trac page if you need to file a bug report.