WinGLContext.MakeCurrent fails with error code 2004

[wldevries]

I'm having rather frequent errors when starting MonoGame (Windows OpenGL) projects. The stacktrace is listed below and the target machine is running Windows 8.1 pro 64bit.

The error code 2004 corresponds to ERROR_TRANSFORM_NOT_SUPPORTED (The requested transformation operation is not supported.) Another error that is thrown with the same stack trace and the same GraphicsContextException is error code 6 (ERROR_INVALID_HANDLE).

OpenTK.Graphics.GraphicsContextException: Failed to make context 65537 current. Error: 2004
   at OpenTK.Platform.Windows.WinGLContext.MakeCurrent(IWindowInfo window)
   at Microsoft.Xna.Framework.Threading.BlockOnUIThread(Action action)
   at Microsoft.Xna.Framework.Content.Texture2DReader.Read(ContentReader reader, Texture2D existingInstance)
   at Microsoft.Xna.Framework.Content.ContentTypeReader`1.Read(ContentReader input, Object existingInstance)
   at Microsoft.Xna.Framework.Content.ContentReader.ReadObject[T]()
   at Microsoft.Xna.Framework.Content.ContentReader.ReadAsset[T]()
   at Microsoft.Xna.Framework.Content.ContentManager.ReadAsset[T](String assetName, Action`1 recordDisposableObject)
   at Microsoft.Xna.Framework.Content.ContentManager.Load[T](String assetName)
   at SilverFit.Boom.ThreadSafeContentManager.Load[T](String path)
   at SilverFit.CognitionGames.BaseContent.TextureRegion(String contentpath)
   at SilverFit.CognitionGames.CategoryContent.LoadGameSpecificContent()
   at SilverFit.CognitionGames.BaseContent.LoadAllContent()
   at SilverFit.CognitionGames.CognitionGame.LoadGameContent()
   at SilverFit.Common.Components.SilverXnaApplicationBase.LoadContent()

[wldevries]

The issue seems to be that BlockonUIThread tries to make the OpenGL graphics context current while the draw thread is using the context to draw. I fixed it by adding a locking around my load context and around my entire draw call.

Locking is only added to asset getting and setting, not to anything that happens on the main thread. It seems to me that a lock should be added inside GraphicsDevice.DrawUserIndexedPrimitives and in all other places where GL calls are made in the main thread.

[riperiperi]

I'm getting this issue as well - though sometimes the error code appears as 0. My project is also Windows OpenGL. It happens incredibly frequently (in less than one minute most times)

[KrytenCoder]

I am also seeing this error, although for me it is triggered by my terrain paging system disposing of either vertex or index buffers. Vs indicates the last active thread to be GC Finalizer.

Failed to make context 131072 current. Error: 2004 at OpenTK.Platform.Windows.WinGLContext.MakeCurrent(IWindowInfo window) at OpenTK.Graphics.GraphicsContext.MakeCurrent(IWindowInfo window) at Microsoft.Xna.Framework.Threading.BlockOnUIThread(Action action) at Microsoft.Xna.Framework.Graphics.VertexBuffer.Dispose(Boolean disposing) at Microsoft.Xna.Framework.Graphics.GraphicsResource.Finalize()

Tested with latest release and also current dev code compiled 7th feb.

[tomspilman]

@cra0zy @dellis1972 @KonajuGames

Any thoughts on this?

lock should be added inside GraphicsDevice.DrawUserIndexedPrimitives
and in all other places where GL calls are made in the main thread.

Note that the DirectX path does lock the device context for drawing, state setting, content set/get data, and presentation operations. It doesn't lock on resource creation as at least that is assured to be thread safe in DirectX.

[tomspilman]

Bump... @cra0zy @dellis1972 @KonajuGames

[KonajuGames]

Graphics resources must be explicitly disposed. If it is left to the garbage collector to dispose the resources, it will likely fail with cross thread issues. The finalizer is called from the GC thread and we can never release the GPU resources correctly in this manner. Thank OpenGL for not being thread-friendly. If you see a call to the Finalizer in your callstack, it means the object was not explicitly disposed.

[KonajuGames]

For the locking around the draw, we may end up doing what we do on Android and make the OpenGL context single threaded. GL calls on other threads are then invoked on the main thread. This should also improve rendering performance as enabling multithreaded support in an OpenGL context incurs a performance hit.

[mrhelmut]

Context is now single threaded in DesktopGL. I believe this issue is not relevant anymore.
(elennick/switch-mono which referenced this issue 2 days ago uses MonoGame 3.5)

@KonajuGames @tomspilman

[harry-cpp]

@tomspilman This can be closed.