VisualStudio 2013 persisting to mystery db during project run - asp.net-mvc

Question

Environment:
Windows 8.1
Visual Studio 2013
Project type: ASP.NET MVC
Debugging in IIS Express.
DotNet: 4.5
Database: SQLExpress 2012
EntityFramework 5
When I run my solution (F5), in Debug or Release configuration, I can manipulate data through EF with no issues; data changes persist between views. If I query the database in Management Studio however, none of the updates are reflected in it. If I update a record in Management Studio, the changes aren't reflected in my running solution either.
If I then stop and restart, or even just stop and do a build (CTRL, SHIFT, B) in VS, my data in the web application all reverts back to the state matching that of my database through Management Studio.
If I add a trace to the database, I can see reads, but no writes coming through to the db. Additionally, if I stop the SQLExpress service, my pages throw "SQL Server service has been paused/stopped" exceptions. So bizarrely enough, it looks like it's reading from the correct database, but may be writing to a development cache somewhere?
This leads me to think that on every build, a copy of the db is being used for that debug/run session's state.
So the question then becomes, where is this being set, and where is the temp db living? I have scoured my web.config, web.debug.config, web.release.config, but there is no reference to an alternate database.
I have looked in the /App_Data and /bin folders, but there's no extra database there either. I even resorted to watch the filesystem using procmon for any file operations performed by VS with a build, but I couldn't find anything of note (there is tons of data, so may have missed something).
I have a couple of debug statements spitting out the connectionstring being used by EF, and can confirm that it's pointing the the correct SQLExpress instance.
System.Diagnostics.Debug.WriteLine("Conn String: " + ctx.Database.Connection.ConnectionString);
The only other possibility is that EF is suddenly holding a large cache. I doubt this though as I trace the DB frequently and updates generally happen immediately.
This behaviour is relatively new, but don't know exactly when it started. The only significant change was the VS upgrade from 2012 to 2013, but can't be sure it correlates with the upgrade.
Anyway, I'm now at an end of my tether, and would love any suggestions that I could follow.

Answer 1

OK, I figured it out. So for anyone else having similar issues, it relates to synchronising EF contexts.
I was declaring my classes with a static context reference to save having to declare it in every method thus:
public class MyClass : Controller
{
private static MyContext db = new MyContext();
...
}
Being static, as you would expect, it's evaluated at start-up, and held in memory.
Adding that to the fact that I was changing properties on my objects retrieved from the static context, but updating to a different context (helper function confusion), all resulted in the confused state I was seeing.
So the moral of the story:
Don't use static context references. Declare them as you need them.
Double check that you're retrieving and updating to the same context.

Answer 2

Visual studio installs sqlexpress, normally this is what code first uses. You can use management studio to to connect to the express instance. It's also possible that it's using localdb by default for vs 2013 still optional in 2012.