GraphicsDevice.New crash on Windows 8.1 and Windows 10 build 9860

[guygodin]

This isn't a high priority but with an application that was built on Windows 8 with the SharpDX Toolkit, I get a NullReferenceException when running it on the latest Windows 10 (build 9860) calling GraphicsDevice.New(GraphicsAdapter). More precisely in DataBuffer.Clear().

If I run the same code through the debugger in Visual Studio on the Windows 10 machine the problem disappears, odd.

[xoofx]

Do you have the stacktrace?

[guygodin]

System.NullReferenceException: Object reference not set to an instance of an object. at SharpDX.DataBuffer.Clear(Byte value) at SharpDX.Toolkit.Graphics.EffectConstantBuffer..ctor(GraphicsDevice device, ConstantBuffer description) at SharpDX.Toolkit.Graphics.Effect.GetOrCreateConstantBuffer(GraphicsDevice context, ConstantBuffer bufferRaw) at SharpDX.Toolkit.Graphics.EffectPass.InitStageBlock(StageBlock stageBlock, Logger logger) at SharpDX.Toolkit.Graphics.EffectPass.Initialize(Logger logger) at SharpDX.Toolkit.Graphics.Effect.InitializeFrom(Effect effectDataArg, Effect cloneFromEffect) at SharpDX.Toolkit.Graphics.Effect.CreateInstanceFrom(GraphicsDevice device, EffectData effectData, EffectPool effectPool) at SharpDX.Toolkit.Graphics.PrimitiveQuad..ctor(GraphicsDevice graphicsDevice) at SharpDX.Toolkit.Graphics.GraphicsDevice..ctor(Device existingDevice, GraphicsAdapter adapter) at SharpDX.Toolkit.Graphics.GraphicsDevice.New(GraphicsAdapter adapter, DeviceCreationFlags flags, FeatureLevel[] featureLevels)

[xoofx]

Hm... weird. Could you try to use the function SharpDX.Utilities.AllocateMemory(16) for example and check that there is effectively a non-zero IntPtr returned?

[guygodin]

AllocateMemory(16) placed just before GraphicsDevice.New() returns a valid IntPtr. It worked fine on the previous Windows 10 build which is puzzling..

[guygodin]

Just edited the initial bug: the problem disappears when running with a debugger attached in Windows 10.

[baSSiLL]

Have exactly the same issue on one machine: Windows 8.1 (build 9600), dual NVIDIA GeForce GTX 760. Do not have such problems on many other machines. Possibly related to video configuration.

[guygodin]

I've noticed that the crash only occurs with the application compiled for 64-bit.

[baSSiLL]

Additional info Compiled to Any CPU, running in 64 bits. Connected 1x (2560x1080) + 2x (1920x1080) displays. Fails on creating GraphicsDevice for default adapter.

[QuantumDeveloper]

I think @xoofx will close this issue as it is related to Toolkit which is deprecated for now and you can expect no fix to it unfortunately.

[baSSiLL]

It may be the first issue in the new Toolkit repository https://github.com/sharpdx/Toolkit :)

[QuantumDeveloper]

@baSSiLL Ok, who will fix it?

[baSSiLL]

Someone who is the most interested in. Maybe even me, if I don't find workaround and have some time free from more urgent tasks :) (And, of course, if I have enough skill for that) Closing the issue will not fix the bug either.

[guygodin]

Ok started having the same crash on Windows 8.1 today (64-bit only when no debugger attached). I tried re-installing my video card drivers, installing an older version, etc. without success. I'm beginning to think this is an issue that was introduced in a recent Windows update...

[guygodin]

I downloaded SharpDX's source code and investigated the crash. Here's what's interesting about it; the allocated buffer is never 0: it seems to be an optimization/inlining bug with IntPtr. If I create the IntPtr and use it for a Console.WriteLine before calling ClearMemory, everything works fine. If I bypass the conversion to IntPtr it also works. See sample code below:

    // DataBuffer.cs
    public unsafe void Clear(byte value = 0)
    {
        // Orignal: Throws NullReferenceException
        Utilities.ClearMemory((IntPtr)_buffer, value, Size);

        // This works
        Interop.memset((void*)_buffer, value, Size);

        // Also Works
        Utilities.ClearMemory(_buffer, value, Size);
    }

    // Utilities.cs
    public static void ClearMemory(IntPtr dest, byte value, int sizeInBytesToClear)
    {
        unsafe
        {
            Interop.memset((void*)dest, value, sizeInBytesToClear);
        }
    }

    // I've added this overload for test pruposes
    public unsafe static void ClearMemory(void* dest, byte value, int sizeInBytesToClear)
    {
        Interop.memset(dest, value, sizeInBytesToClear);
    }

[xoofx]

Thanks for taking the time to dig into this. I will try to check a bit further and report a bug to the CLR team unless we are doing something wrong on the SharpDX IL side.

[guygodin]

Any updates on this? Anyone who has VS2015 installed on their Windows 8 machine will get this crash.. I have to tell my users to install the 32-bit version instead. Has a bug been submitted to MS about it?

[xoofx]

Sorry, I haven't taken the time to review this bug. As I don't have VS2015 installed on my dev machine, I can't reproduce it, but could you create a very small cs project that reproduce this problem and submit to https://connect.microsoft.com/VisualStudio ? I will make sure that someone from .NET CLR team can have a look at this. Thanks!

[guygodin]

Thanks Alex, just submitted the issue: https://connect.microsoft.com/VisualStudio/feedback/details/1093127/an-inlining-optimization-with-the-most-recent-x64-jit-compiler-causes-sharpdx-to-crash