20

I have come across this odd behaviour: when my projects settings are set to Any CPU and Prefer 32-bit on a 64bit Windows 7 OS the .Net 4.5program below works as expected. If however I turn off Prefer 32-bit then when stepping through the program, I can see that the code never steps into the interface implementation - but also does not throw any errors.

I have distilled it down to its simplest form in the following console application:

namespace BugCheck
{
    interface IBroken
    {
        bool Broken<TValue> (TValue gen, Large large);
    }
    class Broke : IBroken
    {
        public bool Broken<TValue> (TValue gen, Large large )
        { return true; }
    }
    struct Large
    {
        int a, b, c;
    }
    class Program
    {
        static void Main (string[] args)
        {
            //32bit can step in. 64bit can't
            ((IBroken)new Broke()).Broken(1, new Large());
        }
    }
}

As expected, when toggling Prefer 32-bit the program will alternate between the .net 32bit assemblies and the 64bit assemblies - where it works as expected with the 32bit assemblies and "breaks silently" with the 64bit assemblies.

As suggested by @Athari it appears to be related to the size of the Large struct.

What am I doing wrong that is causing this behaviour?

Stephen Bailey
  • 1,931
  • 13
  • 20
  • 10
    Looks like a 4.0 debugger bug to me, the 2.0 debugger has no trouble with it. Nothing anybody here can fix for you, report this at connect.microsoft.com – Hans Passant Aug 10 '14 at 20:43
  • @HansPassant thanks, will follow that route -- just want to make sure I am not falling into the trap of assuming it a bug, if the bug is just my ignorance :) I Seemed to have trouble logging via the browser, so fell back on integrated feedback in VS ( so probably logged in incorrect location ) https://connect.microsoft.com/VisualStudio/Feedback/details/943122 – Stephen Bailey Aug 10 '14 at 21:33

1 Answers1

1

For those that come across this question looking for a solution, to quote Tom from the Microsoft team:

This looks like it is related to a bug that is fixed in .NET Framework 4.5.2. We can verify that that the issue is related by disabling the Managed Return Value feature. I have posted instructions for doing this to the 'Workarounds' section.

This issue is caused by the code which gathers return values. It is possible to work around the issue by disabling Managed return values.

  1. Go to the System properties (Win8: WinKey+X, select ‘System’, Win7: Open ‘Properties’ from my computer)
  2. Advanced System Settings
  3. Environment Variables…
  4. Click ‘New’ and add
    • Name: VSDebug_DisableManagedReturnValue
    • Value: 1

If disabling Managed Return Values works around the issue, the fix for this issue is in .NET Framework 4.5.2. This can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=42642. Installing 4.5.2 is all that is needed to fix the issue.

Stephen Bailey
  • 1,931
  • 13
  • 20
cost
  • 4,420
  • 8
  • 48
  • 80