I have several game servers that use a certain .dll file to run. Sometimes I need to update the game servers but I don't wanna interrupt the games that are already running.

Is there a way to replace the .dll file (it's locked by Windows) so the next instances of the game servers that use that file open the new version, and the old ones keep using the old version of that .dll until they are restarted?

Is it safe to just unlock the file using one of those tools that do that and replace it?

  • Perhaps not your game. However Chrome does update without interrupting your process. Unfortunately, this is application -specific. (Go to %LocalAppData%\Google\Chrome\Application and you should see folders like 26.0.1410.64 which stores DLLs of different versions)
    – Alvin Wong
    Apr 30, 2013 at 3:16
  • Depending on the software in question, it might be possible to install and run two or more distinct instances (in different locations). Inefficient, but perhaps workable. Apr 30, 2013 at 5:08

7 Answers 7


Actually, you can and it usually works without any issue (although not always)

What you do is rename the file without moving it (i.e. without changing the file location in the folder structure) and move the new file to the containing folder.

That will keep the handles to the file valid and working so that pre-existing instances still will be able to access the file properly and new instances (or new handles) wil go to the new file.

Obviously, if a program re-opens the same dll file and expects it to stay exactly the same (for instance, if there is resources to be loaded from the dll and that references to these resources is extracted from code running when the dll is loaded), this will cause issue but this is definitely not the norm.

  • When you say "rename the file without moving it"... mv .\file.dll .\old.dll renaming is technically "moving" a file . Do you mean rename it and leave it in the same directory? Oct 27, 2020 at 22:04
  • hmm, I'm having trouble renaming a pdb file while a program is running. renaming the DLL seems to work fine. Strange! Dec 22, 2021 at 18:59
  • @DanielWilliams This subject is about replacing dll files in use (and, by extension, all files that are loaded into memory using the windows image loader using the default options). It doesn't mean that it's valid for all files: if a file is open in exclusive mode (which is typically the case for database files) then there is nothing you can do about it without closing the process that uses the file or manually invalidating the handle (which will most likely crash the software using the file).
    – Stephane
    Dec 23, 2021 at 10:01

No. Even though a DLL may be entirely mapped into physical memory while the application runs, there is definitely no guarantee of that. Portions of DLLs (and even executables) can be mapped into RAM while other bits of it stay on disk, and may be read in at a later time.

Changing the file on disk while Windows has bits of it mapped in RAM would not end well. Windows locks it for a good reason.

Edit: I need to clarify something since some people seem intent on blaming Windows for what is actually an application design issue, not an OS design issue.

You can update DLLs that applications use in Windows without terminating the process, but the application must have been written in such a way that it can be signaled to unload the assembly, wait for the update to finish, then reload the DLL. This has nothing to do with the OS you're running. It's an application design issue.

Edit: Also see Stephane's answer for a possible solution that might work, depending on how your specific application responds to its DLL changing. I think he deserves an upvote.

  • Is there any way to move that file to a temporary location so it can be deleted later, while putting a new one in its old location (so servers that start after that will use the new dll)? Or is the file handle linked to the file location?
    – user54048
    Apr 30, 2013 at 1:21
  • That entirely depends on how the application is written/how it uses DLLs. Take a look at Greg Askew's answer. If the file handle is open there's not much you can do about it. You can forcibly close the file handle but you'll almost surely crash at least your app, if not the entire OS.
    – Ryan Ries
    Apr 30, 2013 at 1:58
  • So what is this “good reason”? So far your answer doesn’t contain a compelling reason why Microsoft doesn’t offer the ability of hot-swapping. Apr 30, 2013 at 8:41

No, you should not tinker with the existing file handles.

If you can take control of the loading of the assembly, and specify it is opened with FileShare.Delete, then it should be possible to rename it. Existing processes will continue to reference the renamed assembly.


  • 2
    In my experience, in most cases (well, more than half the time, at any rate) you can rename (but not delete) a DLL without any tinkering with the application. Apr 30, 2013 at 5:07
  • @HarryJohnston: Yeah it seems I can rename the .dll even if it's in use. I guess I'll do that from now on.
    – user54048
    Apr 30, 2013 at 15:45

You could look at how the asp.net hosted process works and develop something similar.

It takes the whole web application and moves it to a temporary location from which the application is actually loaded. Then it leaves a process to monitor for changes in the original folder, when detected, it spins up a new instance of the application in a new temporary location and starts redirecting new requests to that app. The old app is then torn down once pending requests are finished.

(Nitpicking, yes, it's a simplified view of things, in most cases IIS queues the requests until the new app is able to take over)


No, unfortunately it is not possible.

Sorry, to be exact unless there is late binding, meaning the app uses that dll when runs some part of code in that dll, but it is still not reliable.


About a decade ago, I was a happy user of http://www.eggcentric.com/ISAPILoader.htm which did live IIS ISAPI dll swapping. Mr Egg is still supporting his FOSS solution.


NSIS Installer has one option as Move To Temp on Machine Restart, OS flags some file to move to different location on next boot, on next machine boot these flagged files automatically move to new location you selected earlier. A little search on this will make you happy in this regards.

  • You could provide a complete answer in your reply instead of telling the OP to search for a solution. He wouldn't be here asking if he had already found a solution. Thanks.
    – John K. N.
    Nov 1, 2016 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy