Background: Our biomechanics and Advanced Surgical Technologies Lab wrote a surgery navigation system desktop application in C# around ten years ago. One of its major functions uses XNA Game Studio 4.0 to aid in the interactive interface for rendering in 2D and 3D cloud data originating from CT (medical scan data in DICOM format), and then segmenting that data and reconstructing it to generate surface models (stl format).

Summary of problem: The whole application worked fine and still does on the old hardware, but, while compilation succeeds, execution fails in one aspect related to XNA processes destined for the GPU processor rather than the main PC CPU.

The import of data from DICOM and various filtering and scaling all works, and basic rendering also works on previously compiled source code and executable code on Windows 7 machine (details later below). Also, compilation and execution work fully on an old Win PC with the Visual Studio 2013 environment. ‎

Our attempts to compile the same source code and execute on newer hardware and environment with Win 10 and Visual Studio 2019 have partly failed. The compilation works, and most of the execution works, except for some rendering of XNA processes destined for the GPU processor.

More details: The user interface successfully renders bitmaps through the Texture2D class (Microsoft.Xna.Framework.Graphics) initialized with the grayscale data from previous number crunching operations in our code.
In another part of the interface, where we think and say above may rely on the (onboard GPU) processing, using the same Texture2D object, but when the code involves setting parameters of Effect (Microsoft.Xna.Framework.Graphics.Effect) using Texture2D, drawings which use the spriteBatch.draw function is not rendering on the modern PC platform we set up.
We guess the relevant code which fails to do the job is the following. Pls note that it simply fails to render parts of the image which require image processing (filters, thresholding, boundary detection, etc.), AND without any errors/exceptions reported.

            GraphicsDevice device = SosGraphicsDeviceService.Instance;
            SpriteBatch spriteBatch = SosGraphicsDeviceService.ServiceInstance.SpriteBatch;

            string technique = SosRenderModeName.GetTechniqueName(renderMode_, false);

            BlendState blend = device.BlendState;
            DepthStencilState depth = device.DepthStencilState;
            RasterizerState raster = device.RasterizerState;

            Effect.CurrentTechnique = Effect.Techniques[technique];

            Effect.Parameters[“useModelBuilderTextureInclude”].SetValue(includeTexture != null);


            spriteBatch.Begin(SpriteSortMode.Immediate, BlendState.Additive, SamplerState.PointWrap,DepthStencilState.Default, RasterizerState.CullNone, effect_);

            foreach (EffectPass pass in Effect.CurrentTechnique.Passes)

                spriteBatch.Draw(texture, new Rectangle(0, 0, 512, 512), Color.White);


The following are some of the functions we use in our effect file if that helps to identify the Shader Model Version.

•   float4 PixelShaderFunction(VertexShaderOutput input) : COLOR0

       return float4(1, 0, 0, 1);
•   technique Technique1
       pass Pass1
        VertexShader = compile vs_2_0 VertexShaderFunction();
        PixelShader  = compile ps_2_0 PixelShaderFunction();

To try to see which settings or aspects of the environment are causing the problem, we tried to recompile the same code in a variety of configurations and execute on both the old and new machines which having different hardware, drivers, libraries, and different installation configurations.

For example, we tried: • Changed Compatibility mode to match Win7 • Reduced color mode to 8bit • Changed Screen Resolution • Ran in administrator mode • Changed Game profile to Reach

The modern PC platform just would not render with the interface that utilizes Effect.

To recap, below is a summary comparison of the two setups, the one that works on the left, and the one that does not on the right, in terms of hardware, system, and environment setup. We tabulate here the hardware and system environment of each case. If needed, I can upload the whole System information file.

Desktop_Old (Works) Desktop_New (does not work)
System OS Microsoft Windows 7 Enterprise Microsoft Windows 7 Professional
OS version 6.1.7601 Service Pack 1 Build 7601 6.1.7601 Service Pack 1 Build 7601
System Type X64-based PC X64-based PC
Total Physical Memory 7.88GB 15.9GB
Display NVIDIA Quadro 1000M Intel HD graphics 4600
Resolution 1920 X 1200 X 59 hertz 1280 X 1024 X 60 hertz
I/O port Just one three
Driver nvlddmkm.sys Igdkmd64.sys
Installed DirectX DirectX11 DirectX11
IDE Visual Studio 2013 Visual Studio 2019
Game Profile HiDef HiDef
Unsafe Code Allowed Allowed

Also, this is the previous post for the same problem and thanks for responding.

  • 2
    \$\begingroup\$ XNA is very very outdated, have you tried using Monogame? It is actively supported and should not require a lot of code changes - even the namespaces stay as Microsoft.Xna.Framework. Is there a specific reason you must stick to Microsoft's XNA specifically? \$\endgroup\$ Commented Dec 23, 2020 at 0:15
  • \$\begingroup\$ Have you tried the latest Intel graphics driver from Intel? \$\endgroup\$ Commented Jan 4, 2021 at 22:06

1 Answer 1


While I have spent years working with XNA across Xbox 360, Windows Phone 7 and PC, this kind of a problem is typical and requires lots of tedious configuration of the target system. While I was once successful in past, it took more effort than to simply update graphics API (say, DX8 to DX11).

Every new version of VS links against different libraries. Given how long ago was XNA abandoned, you have no business in attempting to compile it there.

For my personal projects in XNA, I still use VS2010 even though I have three other newer versions of VS on PC (different languages and APIs). It's just not worth the effort.

I would, however, very strongly recommend mirroring the Dev HW as you are one unexpected catastrophe away from being unable to deploy critical bug fixes to the production HW.

Oh, and I didn't see anything about trying the Quadro inside the Intel HD box. Seems like a very simple and quick exercise (just to rule out the Intel drivers).


You must log in to answer this question.