Sometimes when working on a projects where files get copied around like in web projects or when you have a solution with multiple assemblies, you may find that the code that’s running appears to be “old” – it may not working as you expect after you modified it.
Usually this is a problem with the wrong file being picked up, or a server using a stale cache for code, or something of the sort. The trick to troubleshooting these cases is to figure out what’s really happening.
Enter the Modules window. When you’re in a debugging session (whether started with F5 or attached to a running process), this window will show you all the loaded modules (.exe and .dll files). There is a lot of useful information, but probably the more interesting pieces are the file on disk, version and the loaded symbol information.
- With the file path information, you can do some basic checks like making sure the timestamp on the file is what you’d expect. This typically points you in the right direction as to whether the right file is being used.
- With the symbol information, you can get started troubleshooting cases where you can’t set breakpoints on code files. Visual Studio needs the symbols from a .pdb file to cross-reference the loaded module with source code files on disk, so if you can’t set a breakpoint somewhere, checking that symbols are loaded correctly is usually the first step. Just right-click on the module and you’ll get the commands to get information on what’s up with symbols and options to load them.