Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A co-worker of mine is having the following issue (so some relevant details may require further vetting):

The server is Windows 2008 Server. There is a Windows Service that is running (exe (.net), that also utilizes a .NET assembly). There is some bug with the dll and/or exe. Some debug messages were added to and removed from the dll. This new version of the dll and its recompiled exe were ftp'd over to this server, the service was stopped, the existing dll and exe were renamed, and replaced with the new, and the service started.

We still see debug messages that were removed from the dll. They don't exist in the new code.

The server was restarted.

Is the old dll getting cached somewhere? somehow? Thank you.


The following just happened:

  1. the recently renamed assembly.old was physically removed (this was the one and only copy)
  2. old debug messages still in there!
  3. service uninstalled/reinstalled (though we think we could have gotten away with a restart)
  4. works.

So, knowing what happened before this (which included a restart of the OS), and what happened now, somehow/someway Windows is tracking the dll's(?) and when the one copy was renamed, windows defies the update and associates (in it's mind) that assembly.old will be assembly.dll. Not the new assembly.dll that was put in its place?

Because assembly.dll and assembly.old in same directory, after OS restart - old dll continually looked at. assembly.dll and no assembly.old - works.

The thing that baffles me is how do you control this? Or where is the documentation on this?

Other info: 64-bit version of the server. A VM.

share|improve this question

This may be due to how .NET locates assemblies, documented here:

How the .NET Runtime Locates Assemblies

Note the following:

"The compiler records static references in the assembly manifest's metadata at build time. Dynamic references are constructed on the fly as a result of calling various methods, such as System.Reflection.Assembly.Load."

If your reference is static, you may examine the executing assembly's metadata for the manifest. The manifest may be examined using ILDASM or some other tool such as ILSpy. If it is dynamic, the location process is complex and sophisticated.

My experience has been that if multiple CLR versions exist (e.g., both 2.0 and 4.0), the result may be unexpected. There are several additional factors, such as:

  • machine configuration and application configuration;
  • if the application is all managed code, or has some unmanaged code (COM/Interop);
  • if the executing/calling assembly and called assemblies are platform independent ("any cpu"), or platform-specific (x86 or x64).

It is also possible to run both 2.0 and 4.0 CLR code in a process at the same time (side-by-side execution).

I would think that this should be reproducible in a development environment, and it is unrealistic to expect the consumer to know or deal with all possible scenarios.

.NET In-Process Side-by-Side Execution

Assemblies: locating, binding and deploying

When you run Microsoft SysInternals' Process Explorer, select the service process, and the .NET Assemblies tab, it should show you all of the various loaded assemblies so you can validate that the correct file is loaded:

enter image description here

share|improve this answer
up-vote for helping thanks. – JustLooking Jan 4 '12 at 20:09

Well you answered your own question there. You dropped a new DLL onto your disk, yet when you run some code it still seems to be using the old DLL. Therefore, there must be a copy of the old DLL still lingering around in your memory somewhere.

Try this -- create a shortcut, and use this as the command to run:

%windir%\system32\rundll32.exe advapi32.dll,ProcessIdleTasks

Name it whatever you want... something like "Memory Cache Flusher". Run it in between test runs of your program.

share|improve this answer
Well, the one copy of the dll was renamed to .old. And we did restart. I suggested that he just remove it altogether. Regardless of whether that fixes it or not, I'm baffled as to how Windows now 'picks up' on the fact that blah.old is blah.dll? And why it ignores the real (new) blah.dll! And is that something that can be controlled somehow? It seems like some weird Windows thing that can cause plenty of hiccups, and I'm not finding a lot of info out there in Google-land. I'll throw your comment his way. Thanks a lot, I appreciate it. – JustLooking Jan 4 '12 at 19:26
up-vote for helping. thanks. – JustLooking Jan 4 '12 at 20:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.