I can reproduce it on my home machine (driver 365.10).
Investigating, it looks like I may be correct, seems it may be a race condition:
at OpenTK.Graphics.OpenGL.GL.Viewport(Int32 x, Int32 y, Int32 width, Int32 height)
at SFML.NET_2015.Program.Main(String[] args) in g:\Code\CS_SFMLAndOpenGLTest\CS_SFMLAndOpenGLTest\Program.cs:line 83
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
NVIDIA's driver may potentially be doing some extra threading that interferes with both SFML and OpenTK using the context, that Intel's driver does not do.
Unfortunately, this is getting out of the realm of my knowledge, so I'm not really sure where to go from here.