To update BlockTheSpot after a Spotify update, delete the existing blockthespot.dll and the renamed chrome_elf_required.dll from %APPDATA%\Spotify, rename the current chrome_elf.dll back to chrome_elf_required.dll, then copy in the new chrome_elf.dll, blockthespot.dll and config.ini from the official release. Check the release matches your Spotify build first, since the archived project may lag behind newer versions.
BlockTheSpot is a set of file replacements plus signature-based edits. Spotify's own updater can replace files in the program folder, and a new build can move the code that the edits look for. When that happens, ads can come back, the app can show a blank window, or it can refuse to start. The fix is almost always the same: restore a clean state, then apply the files that match your current build.
Because the official repository is archived, there may not be a new release for a recent Spotify build. An update is therefore a decision, not an automatic step. Read our discontinued explainer and check the status page before you move forward.
Close Spotify from the system tray and confirm in Task Manager that no Spotify process remains. The steps below change files that a running app keeps open.
Open %APPDATA%\Spotify in File Explorer. You should see the Spotify program files, along with any BlockTheSpot files from your previous install.
Delete chrome_elf_required.dll and blockthespot.dll. The official README's update steps list these two files. Do not delete anything else at this stage. If you can see a config.ini, leave it for now, because you will replace it with the current copy in step 6.
Rename the current chrome_elf.dll to chrome_elf_required.dll. This is the same rename as in a fresh install, and it puts the folder into the state the README expects before you add the new files.
From the official releases page, download chrome_elf.dll and blockthespot.dll. Copy both into %APPDATA%\Spotify. Use files from the same release, and check their hashes against the values on our install page if you want to be certain.
Download the current config.ini from the repository and copy it into the Spotify folder, replacing the old one. The README asks for the latest config.ini on each update, and the file holds the signatures and offsets the patch uses. A config.ini written for a different build can leave some features unpatched, so compare the version in its header with your Spotify build.
Open Spotify and listen to a few tracks, including one where an ad break would normally appear. Check the home screen for banner ads. If the app opens and the ads stay blocked, the update is complete. If it does not, go to our troubleshooting hub. If you see a blank window, read the stopped-after-update guide.
chrome_elf.dll somewhere safe.If Spotify will not start after an update, the safest route is to revert. Follow the steps in our uninstall guide to restore the original files, then reinstall or update Spotify to a known-good build. You can then decide whether to re-apply the patch. Keeping Spotify on a build that works is more important than keeping the ad blocker on a build it does not match.
Spotify can update itself without asking. The steps above work whether the update was automatic or manual, but automatic updates are the most common reason people find their patch has stopped working without noticing. Some users prevent updates with methods the community documents, but those methods vary, can cause other problems, and are not covered by the official README. Treat any update-blocking method as something you research and test yourself.
Updating BlockTheSpot means returning the folder to a clean state, adding the matching release files, replacing config.ini, and testing. Check compatibility first, because with the official repository archived, the release you install may not match the Spotify build you have.
Because Spotify updates can break a patch quietly, a short routine helps you notice problems early. Once a month, or after you see a Spotify update notice, check the version, check the official repository, and listen to a track with an ad break. Ten minutes of checking can save an afternoon of confusion later.
If the version has changed and the features look different, follow the update steps above. If nothing changed, you can keep using the current setup, but keep the record in case a later update breaks it.
The config.ini on the official master branch names the Spotify version the project tested, which is 1.2.83.461 in the copy we checked. Find your own Spotify version in the app's settings or About information, and compare the two numbers. A match is the best case we can describe. A mismatch does not automatically mean the patch fails, but it does mean the combination is untested by the project, and you should expect to test more carefully.
The release date is the second check. The latest release, 2026.02.12, was published on 11 February 2026. A Spotify build released after that date is not the one the config.ini names as tested, unless the release notes say otherwise.
Record the new Spotify version, the date, the result of your ad checks, and whether the features you use still work. That short note makes the next update easier to judge, and it gives you a clear reason to stop, revert, or wait if things go wrong.
A Spotify update can replace or change the files the patch depends on. The patch files may be overwritten, or the code they target may move, so the edits no longer match. Re-applying the files for a matching build usually restores the patch.
The official README update steps delete the existing blockthespot.dll and the renamed chrome_elf_required.dll first, then rename the current chrome_elf.dll and place the new files. That clean sequence avoids mixing old and new files.
It is a trade-off. Staying on a build that matches your config.ini keeps the patch in its tested state, while updating can bring new features and fixes but may break the patch. Check the status page and the config header before you update.